@Abadrausar: Good point, there's Taffer 20x and Gemset 24x, but other than that the sets are not high def friendly. It looks like Spacefox will be converted to 24x, and maybe Phoebus too. The question is, if it's necessary at all to package both 16x and 24x versions, or not. Opinions?
As for Bisasam: this repo so far only contains "graphics sets" - by that I mean they all contain some customization besides a tileset image, like a color scheme, init modifications, creature gfx, etc. For some sets these modifications are minor, like grim fortress, so it could be argued that they are "tilesets" and not "graphics sets". There's a separate tileset collection folder in the starter packs for these. I guess those also deserve a place here, but before I do that some brainstorming is in order on how to make them easier to install/configure with Pylnp. Paging PeridexisErrant.
@Quiet-Sun: Nice. I read your post in Spacefox, please post this and the app too - if there are no copyright problems with posting some proprietary Matlab software. It expensive...
TODO:
...
Add appropriate license to all packs
The short answer is that I consider the license to be CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), and you can use it as you like as long as you give me credit for the tileset.Source (https://github.com/nc-z/taffer/issues/1).
@Quiet-Sun: Nice. I read your post in Spacefox, please post this and the app too - if there are no copyright problems with posting some proprietary Matlab software. It expensive...
I think both algorithms produce nice results, the texture details are better with weifu, but hqx is better when the tile is uniform and contains straight lines. Best results would be to photoshop a mix-and-match. I am not going to ask you to do that. :)
Instead of a subfolder a new branch would be better. I can do it if you want me to, but you know, the secret purpose of this thread is to find people who can send me pull request I can review at my leisure. :D
re: Matlab - the runtime is expensive/proprietary, but the code can still be Free/open-source. GNU Octave supplies a mostly-drop in replacement for the runtime too. Plus with source I can probably translate to Numpy, and then we can bundle it into PyLNP...
A word of caution, upscaling a graphics set takes quite a bit of time (we are talking about several hours), because the best results are obtained when you upscale each tile separately. I wonder if perhaps is better to pre-generate and pack the 16x16 and 24x24 sets with PyLNP. Since DF doesn't change that often, perhaps it's also better to keep the upscaling application separate from PyLNP (of course translating it to Python is still totally worth it!). This way people are very much aware of what they are getting into when they launch it :P
@Clatch: Excellent idea, though it would be something like:
brew install dwarf-fortress - - with-gfx phoebus
Do you want to work on it? I need to study brew formulas before I can manage that.
What's the objection to including pre-cooked versions of the up-sized graphics sets in the packs? Is it just a matter of file size/avoiding duplicates?
For graphic sets, maybe we could agree on a common organization (i.e. where which creatures are on the graphic sets and how they're separated). That would make it easier to spot errors, maintain, and update all graphics of the community with minimal effort.
I assume the easiest would be to follow the organization and order from the raws (I'm probably the only one who doesn't already separate the creature graphic sets by their raw files, but I'm not sure if the order within is the same for everyone).
Ideally we would have a template and a script that generates that template from the raws. so when new creatures are added, it's easier to update.
What's the objection to including pre-cooked versions of the up-sized graphics sets in the packs? Is it just a matter of file size/avoiding duplicates?
What's the objection to including pre-cooked versions of the up-sized graphics sets in the packs? Is it just a matter of file size/avoiding duplicates?
The multiple art assets can be present in the art directory, but the original init file can be managed by the scripts calling the git repo. It might be nice to include some standardized notation of art sizes so that they are easily handled without duplicating code: ei, <art_name>_15x15.png, <art_name>_18x18.png, etc.
I was under the impression that only square brackets work. The parentheses and exclamation marks might be fancy ways to comment out lines, i.e. make them non-functional.
Best idea would be to test if these entries actually work in game.
Square brackets are the only way for them to be read as graphics, if you just comment out
!CREATURE_GRAPHICS:CAT]
[DEFAULT:PHOEBUS_ANIMALS:0:0:AS_IS:DEFAULT]
you will make the next graphic below that messed up. Had that problem with alpacas in spacefox. Though for whatever reason it won't mess up the one below the one it messes up.
They are both skelton/zombie/evil class monsters in your examples, the second example is how it is normally done, I've no idea who did the first one or if it'd work but it might. The comments are that way so they are easy to mass reverse, you wouldn't see the same comment on both sides afterall as that would be counter productive. Skeleton is no longer used I believe just the animated but it was left in, in the case that it gets reused.
Note that the Tokens GHOST and ANIMATED go in the profession spot, not the texture token as you would expect - this means that you can't have separate graphics for miner zombies, axedwarf zombies, speardwarf zombies, etc.
Quote from: http://dwarffortresswiki.org/index.php/DF2014:Graphic_set#List_of_Professions.2C_Creatures_and_StatesNote that the Tokens GHOST and ANIMATED go in the profession spot, not the texture token as you would expect - this means that you can't have separate graphics for miner zombies, axedwarf zombies, speardwarf zombies, etc.
@Quiet-Sun This may answer a lot of your questions. (http://dwarffortresswiki.org/index.php/DF2014:Graphic_set#Text_File_Syntax)
Note that some animals are missing in some of the sets (so those tiles are left blank), but now there is a uniquely defined tile for all sets.
What I'm proposing (based on CLA's idea) is that we create a standard set of text files pointing to standard tiles that are exactly the same regardless of the graphics set. Then, using a more sophisticated version of my script, we populate the png files for each set. The advantage is that it becomes very easy to mix and match sets and we can very easily update the whole thing if DF adds or removes creatures.
does it know NOT to define a creature's tile if it's left blank?*Good point. Any better options than commenting out that creature definition?
How is this standard definition file being created? I didn't see any in the download.
Is this standard definition file going to be automated somehow?
If the standard definition file is automated, does it know NOT to define a creature's tile if it's left blank?*
How are the professions pulled for the standard races and animal people?
Speaking of CLA - how do we deal with several creature definitions pointing at the same tile? I use that sometimes (Giant creatures whose base creature uses a capital letter like Lion share the same graphic), and as it stands right now, with the new standard, I would have the same graphic multiple times in several files. Is there a smart way around that without compromising the standard? In the end it's not that much of a maintenance problem, but I figured I'd mention it.
If this is the case, we just run the artist's work though the scriptOh yeah, of course. Didn't think of that.
We would provide matrix templates with (names crossing textures/professions with the respective animals/races) in case artists just want to fill them up and not to bother with making the text files.
I didn't see anything in your script regarding a standard definition file. It reads as if it goes through the existing image(s) and existing definition file(s) and creates png(s) as far as I can tell. But, maybe I don't understand your script and I'm just missing the part that creates the definition file. But, based on your answers, I think this is really about our terminology. Let me start over to avoid confusion.
How is this standard definition TEXT file being created? I didn't see any in the download.
Is this standard definition TEXT file going to be automated somehow?
If the standard definition TEXT file is automated, does it know NOT to define a creature's tile if it's left blank?
If it's not automated, how are you going to mix and match sets?
How are the professions pulled for the standard races and animal people for the TEXT file?
Sorry if I wasn't clear before. I do understand what you have done. I wanted to know how you are going to tackle the standard definition text file. Based on this comment . . .We would provide matrix templates with (names crossing textures/professions with the respective animals/races) in case artists just want to fill them up and not to bother with making the text files.
. . . you would just "provide matrix templates."
How?
- If no animated, turn standard B&W and flip it along the left-right directionI was about to ask whether we could drop that and just leave it as it is, but the more I think about it, the more I actually like it for CLA.
Ok, here is what I mean by a matrix template. The files you are going to look have all been generated by the automatic script (text and all). I have now filled all rows if there is at least a standard tile like this:
How do we deal with AS_IS vs ADD_COLOR?I totally forgot about the AS_IS versus ADD_COLOR. Thanks.
The files you are going to look have all been generated by the automatic script (text and all).&
The idea is that with each tile uniquely defined, artists can fill the gaps without worrying about the text files.
Anyway, you get the idea.
I don't know how many creatures can become trained.P.S. Here is a list. (http://dwarffortresswiki.org/index.php/DF2014:Animal_trainer#Train_a_hunting_animal) I hope that helps.
Obviously this is a work in progress, so the details are not finalized, but one thing I notice is that it's not entirely obvious where the tile boundaries are located just based on the grid lines on the edge. On the first column, the first tile includes both the "left" and the "right" line of black pixels; on subsequent ones it's only the right line that's included.
Would it perhaps make sense to include space for the grid lines, perhaps, and actually extend them into the "tile" area for the sake of overview? That would also make it easier to identify an undefined cell: it's one where every pixel is transparent, rather than one where certain edges are black and everything else s transparent.
Another thing though: How do we deal with AS_IS vs ADD_COLOR? tell the script which to use? I figure you could let the script check whether the tile only contains white/greyscale or other colors too, but there's always the possibility that someone wants ADD_COLOR even with other colors or AS_IS with no colors (for example those animated tiles, or maybe a polar bear). Replacing all instances of AS_IS with ADD_COLOR is easy enough, but if you have mixed sets, it's gonna get annoying.
Pulling the color out of the raws and coloring the png automatically is problematic too, since it depends on the color scheme.
In the end, I think the most sensible thing to do is to just keep it as ADD_COLOR as default, and have people replace it with AS_IS where they need it. It's the less used alternative anyway.
(It would also theoretically make it possible to specify special cases, e.g. ADD_COLOR/AS_IS, by using specific RGB values for specific pixels in the border... but that's a more advanced concept anyway, so don't worry too much about that for now)
I don't know how many creatures can become trained.P.S. Here is a list. (http://P.S. http://dwarffortresswiki.org/index.php/DF2014:Animal_trainer#Train_a_hunting_animal) I hope that helps.
Standard image organization is great for the repo, but the current problem that exists in the repo are with the definition text files. Organizing the images in each set to match a standard means nothing without updated working definitions. The challenge is the definition text file that syncs with the images you are creating.Anyway, you get the idea.
I do get the idea and I'd love to see you or someone pull this off, but all of my questions still remain unanswered.
QUICK QUESTION: Can the ADD_COLOR and AS_IS entries have anything after them besides DEFAULT?
As for the border thing, I assume that's only for the example files or - if we follow pidgeots suggestion to use it for colorization indication - temporary, because those would be visible in game.
The idea is that if you have, say, a 16x16 set of tiles, the generated image from all of this uses a grid of 17x17* - 1 pixel in each dimension is used for the border, and then the remaining 16 pixels are the actual tile graphics.
If the 16x16 tile graphics are completely blank - i.e., all pixels transparent - then we ignore that tile, because it's not specified, otherwise we cut out that 16x16 tile, assemble them all into whatever image layout the game wants.
The border is useful because it makes the separation between each tile more clear - and it also just happens that we can exploit the fact that it's there anyway to carry hidden information. For example, we wouldn't necessarily need to store the tile size explicitly - the top left (or bottom right, etc.) pixel of the image could be colored as RGB(x_size, y_size, whatever) and we could just check that when building the raws to know what we were working with. The final component could be used to mark a file format version, or you could go to RGBA to specify how *many* tiles were in each direction, etc. It's really just a way you might capture the additional metadata that needs to be applied to the raws (of course, you need to figure out *what* that metadata might be, and document how that gets mapped between the images and the raws, but the basic idea is that if you just add a single image, you can just copy the border of a cell that works similarly - or make your graphical change, update the raws after applying it, and then regenerate the grid format.
*The reason for 17x17 instead of 18x18 is that you otherwise get the appearance of a 2 pixel border between cells, but only a single pixel border on the edges. It makes things seem a bit more ordered if the borders appear uniform.
I guess the flaw that I see in your current script is that it relies on preexisting definition text files. So if a HIPPO is defined twice or something is misspelled or GIANT_LION is defined as LION_GIANT or the myriad of other possibilities - how does that even work? Also, what's the point if you need a preexisting error free definition text file for the script to work in the first place, you know?
When you say it shouldn't be too difficult I feel as if you're not considering things like professions that exist in game that you can define tiles for that are not in the raws . . . how are you going to pull that off?
No pressure Quiet-Sun. ;]
I guess the flaw that I see in your current script is that it relies on preexisting definition text files. So if a HIPPO is defined twice or something is misspelled or GIANT_LION is defined as LION_GIANT or the myriad of other possibilities - how does that even work? Also, what's the point if you need a preexisting error free definition text file for the script to work in the first place, you know?
The idea is that if you have, say, a 16x16 set of tiles, the generated image from all of this uses a grid of 17x17* - 1 pixel in each dimension is used for the border, and then the remaining 16 pixels are the actual tile graphics.More clear for whom? It's trivial for a computer to just count the 16 pixels, it doesn't need to 'see'. And eventually the whole process from start to finish would be automated, so nobody else would need to distinguish the tiles either.
If the 16x16 tile graphics are completely blank - i.e., all pixels transparent - then we ignore that tile, because it's not specified, otherwise we cut out that 16x16 tile, assemble them all into whatever image layout the game wants.
The border is useful because it makes the separation between each tile more clear -
metadata embeddingI don't see the reasoning with that. Essentially, it seems that between the first input and the final output, you suggest to store all the information in the image - I'm wondering why not store all the information in a plain text database instead? That seems easier, more compatible and more transparent.
I was thinking that it would be best to keep the tile size the same. The reason is that we have the walls and other items that need to be continuous. We could take the outer pixels from the creature tile, but I have the impression that some artists use the entire tile. What I was thinking as an alternative is to use only the corners of the tile. 4corners*4channels(RGBA)*255 gives us plenty of room to encode information. What do you think?
The idea is that if you have, say, a 16x16 set of tiles, the generated image from all of this uses a grid of 17x17* - 1 pixel in each dimension is used for the border, and then the remaining 16 pixels are the actual tile graphics.More clear for whom? It's trivial for a computer to just count the 16 pixels, it doesn't need to 'see'. And eventually the whole process from start to finish would be automated, so nobody else would need to distinguish the tiles either.
If the 16x16 tile graphics are completely blank - i.e., all pixels transparent - then we ignore that tile, because it's not specified, otherwise we cut out that 16x16 tile, assemble them all into whatever image layout the game wants.
The border is useful because it makes the separation between each tile more clear -
Quotemetadata embeddingI don't see the reasoning with that. Essentially, it seems that between the first input and the final output, you suggest to store all the information in the image - I'm wondering why not store all the information in a plain text database instead? That seems easier, more compatible and more transparent.
Taking the existing tilesets, separating them, adding a border with embedded data, then taking that and removing it again to use in DF seems a bit roundabout. Why not transfer the metadata directly in the final definition file?
EDIT: Just realized, the "datasets" I'm talking about, are the creature definition files.
I guess the flaw that I see in your current script is that it relies on preexisting definition text files. So if a HIPPO is defined twice or something is misspelled or GIANT_LION is defined as LION_GIANT or the myriad of other possibilities - how does that even work? Also, what's the point if you need a preexisting error free definition text file for the script to work in the first place, you know?
When you say it shouldn't be too difficult I feel as if you're not considering things like professions that exist in game that you can define tiles for that are not in the raws . . . how are you going to pull that off?
No pressure Quiet-Sun. ;]
I should correct myself. It shouldn't be too difficult to do it for creatures. Humanoids are a different beast, but I'm not going to worry about them now or I won't make any progress. As you have said before this is not an easy task, but one that I consider tractable. I know I'm not going to be able to pull it off in the first try, but that's not a big deal for me.
One thing that you should keep in mind is that we are both defining a standard AND standardizing existing disparaging sets. At some point or other, something will have to be fixed by a human, but I am convinced that we can do most of the work automatically.
What I need right now is proactive help and not sarcasm. Identifying problems is useful and necessary, but your input would be immensely more valuable if you also try to help us find solutions. Your help (and by you I mean everyone that understands how DF works) is critical for my success.
HERE ARE SOME THINGS THAT I NEED:
- Does anyone know where in DF's /objects/*.txt files are all the professions (or other variables that may affect tile appearance)? I want my standardizing scripts for humanoids to be solely based on the files found in DF so that we can update things easily as the game evolve.
- I see that some races have tons of professions (dwarves), but some seem to have a handful (worm-men). Where in DF's /objects/*.txt can I find such a difference defined? Is it just those that are creatures? How many professions am I dealing with?
On the other end, the script would take the raws and - based on hardcoded rules - generate another dataset from it (number of creatures and their names, number of texture tokens/professions and their names, resulting dimensions of image files).
You would get a set of creatures with a known coordinate (creature X sits at 2:5, creature Y at 0:0, etc)
Finally, it would create standard creature definition text files and the new, reordered image files.
Oh I see now what you mean.More clear for whom? It's trivial for a computer to just count the 16 pixels, it doesn't need to 'see'. And eventually the whole process from start to finish would be automated, so nobody else would need to distinguish the tiles either.For a person who is using the grid to figure out what they need to create.
So instead of a preexisting definition text you would have to set up the tiles in an image to match the predefined defintion text?Yes. For existing graphics, this would happen automatically based on the old definition text. For entirely new graphics, you'd have to learn the coordinates from the standard definition file.
I have a complete list I can send you, but it has everything in it - meaning, not just currently used professions, but outdated professions (in case they are implemented again), professions that are mere guesses, and professions I have not been been able to successfully verify, but they are referenced on the wiki and other definition files consistently.
For reference, this is the ideal workflow I hope to see for graphic set authors once we have a working setup:Spoiler (click to show/hide)
Do we have to hardcode professions?
What do we do with empty tiles? When the script can differentiate between an empty tile and a non-empty tile, it should be trivial to comment out that line. That seems to be the easiest solution.
We could instead fill the empty tiles with their default letter of the default tileset.
This would reduce the difference in the definition files, but as every graphic set needs its own definition file anyway (AS_IS vs ADD_COLOR), it would just complicate things, I think.
Do we have to hardcode professions?
What do we do with empty tiles? When the script can differentiate between an empty tile and a non-empty tile, it should be trivial to comment out that line. That seems to be the easiest solution.
This would reduce the difference in the definition files, but as every graphic set needs its own definition file anyway (AS_IS vs ADD_COLOR), it would just complicate things, I think.
Actually I think I have the solution fro the AS_IS vs ADD_COLOR. Looking at CLA's set I noticed that all his tiles are pure white. We can use ADD_COLOR if the tile has only white, or AS_IS if not (we can make the rule more complicated if necessary, for example using histograms of the tiles).See my earlier comment:
Another thing though: How do we deal with AS_IS vs ADD_COLOR? tell the script which to use? I figure you could let the script check whether the tile only contains white/greyscale or other colors too, but there's always the possibility that someone wants ADD_COLOR even with other colors or AS_IS with no colors (for example those animated tiles, or maybe a polar bear). Replacing all instances of AS_IS with ADD_COLOR is easy enough, but if you have mixed sets, it's gonna get annoying.*note that I meant "keep AS_IS as default", of course.
Pulling the color out of the raws and coloring the png automatically is problematic too, since it depends on the color scheme.
In the end, I think the most sensible thing to do is to just keep it as ADD_COLOR as default, and have people replace it with AS_IS where they need it. It's the less used alternative anyway.
Could you please look at these sets to see if there are obvious problems to you?
Thank you Burned! this would be very helpful. Can you please send me one without outdated professions? We can assume your list is complete and improve it if need be.
Based on the structure and text files I can tell you what I see offhand.
1. The definition text file is named creature_whatever_graphics.txt, but it's defined as creature_whatever.
2. The old definition files are present which means if you correct 1. you will then have everything from Adder to Yak defined twice, each calling different image files since both old and new images are present.
3. If you get rid of the old definition files and old images, you have defined everything that is not in the set as a red tile (This includes the wagon since it's techinically a creature).
Thank you Burned! I found the problem! Graphics deffinition txts need to start with the string "graphics_" so instead of "creature_suberranean_graphics.txt", I had to use "graphics_creature_subterranean.txt" ::)
You see some of the old files, but that is because I need to keep beastmen and major races. I made absolutely sure there were no duplicate entries.
Now I have a bug where dogs look like cows, but that is much easier to fix. I'll upload the correct files later today, but I'm stoked to see it work! I think we will have the standard ready very soon!
Actually I think I have the solution fro the AS_IS vs ADD_COLOR. Looking at CLA's set I noticed that all his tiles are pure white. We can use ADD_COLOR if the tile has only white, or AS_IS if not (we can make the rule more complicated if necessary, for example using histograms of the tiles).A lot of ADD_COLOR graphics are grayscale rather than pure white. I know that my Rally Ho tileset uses grayscale ADD_COLOR for the DEFAULT tile, but the rest of the the tiles are colored AS_IS
STANDARD <<< similar to default. I forget which one takes precedence or why there are two defaults.STANDARD is used when a creature has no profession. These are the peasants, haulers, etc.
A lot of ADD_COLOR graphics are grayscale rather than pure white. I know that my Rally Ho tileset uses grayscale ADD_COLOR for the DEFAULT tile, but the rest of the the tiles are colored AS_IS
Horizontally mirroring tiles may have unintended effect for ASCII tilesets - turning b into d, p into q, etc. This will probably be something that just needs those tiles changed by the artist, but it's something to be aware of during testing so you don't mistake it for the game grabbing the wrong tile.
Something else to note is that a lot of tile definitions have changed rather recently and some older tilesets will use old methods which, ideally, your script will catch and correct.
For example:
[DEFAULT:MyCreature:0:0:AS_IS:ANIMATED] should now be [ANIMATED:MyCreature:0:0:AS_IS:DEFAULT]
[CREATURE:TIGER_MAN] should be [CREATURE:TIGERMAN]
I'm pretty sure Phoebus still defines zombies the old way, and any tile set that hasn't updated in the last month will use the wrong name for tiger men. For a more complete list for the latter, I'd need to diff the raws for each version
STANDARD is used when a creature has no profession. These are the peasants, haulers, etc.Oh FINALLY, I understand the difference between standard and default. Thank you so much. Added to the graphic set page.
DEFAULT is used when a creature's profession doesn't have a graphic defined.
[...]
For a more complete list for the latter, I'd need to diff the raws for each version
Thanks so much Rydel! I could never figure that out.STANDARD <<< similar to default. I forget which one takes precedence or why there are two defaults.STANDARD is used when a creature has no profession. These are the peasants, haulers, etc.
DEFAULT is used when a creature's profession doesn't have a graphic defined.
Something else to note is that a lot of tile definitions have changed rather recently and some older tilesets will use old methods which, ideally, your script will catch and correct.
[DEFAULT:MyCreature:0:0:AS_IS:ANIMATED] should now be [ANIMATED:MyCreature:0:0:AS_IS:DEFAULT]
Since I have three artists reading this thread, I figured I would start with theirs (I used the 42.05 versions).
<snip>
- Burned (https://dl.dropboxusercontent.com/u/408446/DF/Standard%202.0/42.05-Burnedfx%20-%20Standard.zip)
I'm already using an exception file to identify discrepancies between the raws and the graphic set names. I cross checked the raws with the Graphics Wiki (http://dwarffortresswiki.org/index.php/DF2014:Graphic_set#Creatures), and created an exception file that you can download here:
NAME_EXEPTIONS.txt (https://dl.dropboxusercontent.com/u/408446/DF/Standard%202.0/NAME_EXEPTIONS.txt)
@Rydel and @burned, you may be interested in knowing that you seem to be misspelling the giant cats (lion, tiger, etc). At least my script seemed to isolate this. Check the exeptions in my file and test them in the arena just in case.
Oh FINALLY, I understand the difference between standard and default. Thank you so much. Added to the graphic set page.
(note that red tiles are supposed to be there to indicate missing tiles)
My understanding is that it's always been [ANIMATED:MyCreature:0:0:AS_IS:DEFAULT]
Previously it was [SKELETON:MyCreature:0:0:AS_IS:DEFAULT] and [ZOMBIE:MyCreature:0:0:AS_IS:DEFAULT] and you could have all the wepon skills specificed (e.g. SWORDSMAN:MyCreature:0:0:AS_IS:SKELETON, etc) When the switch was made, I too thought ANIMATED should go at the end - but are you saying it did at one point? What version does that actually work in and do you have any insight as to why it changed?
Something else to note is that a lot of tile definitions have changed rather recently and some older tilesets will use old methods which, ideally, your script will catch and correct.
Yes and I would argue that's what inspired this thread to exist. Heh.
Currently, I'm not sure how the script will catch a name change between versions since it would just think there is no tile created for it so to speak. I still see that aspect as a manual process. I'd love to be wrong.
If you created the exception file based on the wiki list, the reverse is true. The discussion makes note of this (http://dwarffortresswiki.org/index.php/DF2014_Talk:Graphic_set), but these are the name changes Rydel mentioned. You're script is not catching them in CLA or Spacefox, because they haven't been updated as of this post, whereas Rydel and myself have updated our definitions.
Also, I noticed that there was a blank column in creature_amphibians in the graphics posted earlier. Either the script is doing something odd, or a creature is missing. I can check which in about an hour and post it.
Everything looks good, though the Ghost and Animated tags might be less confusing if they were listed as professions instead of texture tokens, (or at least included in the profession list with a footnote) since that's where you put them.Yeah, I thought about doing that just now when I added the info about default and standard. I'll just go ahead and do it.
Don't worry about it for the moment, it's caused by me assuming the wiki was up-todate and your files were not, while in reality it is the other way.On that note, the wiki wasn't updated yet because I haven't found time to fix my vim substitute command I used to generate the creature table in the first place. If you're willing and think that it requires only little more work than you're doing for the standardization, I would appreciate having a script that takes the raws and generates a table for the graphic set page. The syntax looks like this (variables in '<>', comments in '####'):
So let me make sure I understand something. The ultimate source of creature tags are the raws, every creature in the game can be found there, and their names are the correct ones. Right?
Regarding creatures that change from one version to the next, for now let's do this manually.
So let me make sure I understand something. The ultimate source of creature tags are the raws, every creature in the game can be found there, and their names are the correct ones. Right?
Correct.Regarding creatures that change from one version to the next, for now let's do this manually.
I agree with what CLA stated previously, standardization in the repo is a good step. Unfortunately, the reason I was even made aware of this was because of the trail of bread crumbs that pointed to the repo not being manually updated in the first place - they were just being "updated" without the definitions being touched for I don't know how many versions back.
I don't expect you to solve this problem (I definitely have hope and I am willing to help where I can!), but in order to address the current problem in the repo - assigining volunteers to specific sets to manually update them would be prudent until a better system exists. I am mainly speaking of the Frankenstein sets. Obviously the single author sets (like CLA) should be aware that they need to update.
Can beastmen have all the professions available to dwarves and elves? or do they operate under a reduced set of professions?
- Can beastmen have all the professions available to dwarves and elves? or do they operate under a reduced set of professions?
. . . the subterranean animal people professions are restricted like the kobolds in the entity_default.txt
Does that change if they are citizens of your fort?
I can't say for sure, but I know that elven woodcutters are possible if they use your civ's ethics, so presumably all jobs available to the civ they're attached to are available.
[/quote]- Can beastmen have all the professions available to dwarves and elves? or do they operate under a reduced set of professions?
This is the best answer I've read in regards to what you are asking . . .. . . the subterranean animal people professions are restricted like the kobolds in the entity_default.txt
Does that change if they are citizens of your fort?
I can't say for sure, but I know that elven woodcutters are possible if they use your civ's ethics, so presumably all jobs available to the civ they're attached to are available.
Then for the moment I will use CLA and Rally-Ho to define the standards since I know they are completely up to dateTo clarify:
Can beastmen have all the professions available to dwarves and elves? or do they operate under a reduced set of professions?
Beastfolk and gorlaks can have any profession available to the civilization(s) they latch on to - which can be any civilization. Technically, so can elves, dwarves, humans, goblins, etc.
Plump Helmet Men can have any profession which doesn't require talking. (Not sure if worldgen respects this.)
Then for the moment I will use CLA and Rally-Ho to define the standards since I know they are completely up to dateTo clarify:
CLA creature graphics, as they are in the CLA graphic set thread, on Mediafire/dffd and presumably in fricy's repo are NOT up to date. They neither have definitions for the new creatures nor the corrected creature names for some old ones and there are consequently several creature graphics missing (new giant and men variants, Tigermen, etc).
The whole reason I didn't update them yet and the whole reason I am enthusiastic about this script is because I don't have time to do it manually and I have no way to automate it.
Can beastmen have all the professions available to dwarves and elves? or do they operate under a reduced set of professions?
Beastfolk and gorlaks can have any profession available to the civilization(s) they latch on to - which can be any civilization. Technically, so can elves, dwarves, humans, goblins, etc.
Plump Helmet Men can have any profession which doesn't require talking. (Not sure if worldgen respects this.)
So in Summary, any Dwarf, Elf, Human, Goblin, Kobold, Animal Person, and Gorlak can theoretically have any profession, and consequently a graphic assigned to it correct?
Can beastmen have all the professions available to dwarves and elves? or do they operate under a reduced set of professions?
Beastfolk and gorlaks can have any profession available to the civilization(s) they latch on to - which can be any civilization. Technically, so can elves, dwarves, humans, goblins, etc.
Plump Helmet Men can have any profession which doesn't require talking. (Not sure if worldgen respects this.)
So in Summary, any Dwarf, Elf, Human, Goblin, Kobold, Animal Person, and Gorlak can theoretically have any profession, and consequently a graphic assigned to it correct?
In regards to testing, maybe a modded DF with elves, humans, goblins and kobolds removed would increase the chances of animal person visitors.That's a good idea and probably worth a shot.
Similarly, wasn't there a way you could give a creature a natural talent/predisposition for a skill in the raws? Would that automatically make them display a profession graphic?
Since I'm so new to DF, I'm only familiarizing myself with the different sections so that's why I greatly appreciate your feedback.
Can beastmen have all the professions available to dwarves and elves? or do they operate under a reduced set of professions?
Beastfolk and gorlaks can have any profession available to the civilization(s) they latch on to - which can be any civilization. Technically, so can elves, dwarves, humans, goblins, etc.
Plump Helmet Men can have any profession which doesn't require talking. (Not sure if worldgen respects this.)
So in Summary, any Dwarf, Elf, Human, Goblin, Kobold, Animal Person, and Gorlak can theoretically have any profession, and consequently a graphic assigned to it correct?
From CLA, Rydel, to my own definitions - we all organized them in a way that made sense to us. They are the same definitions, so they all work (aside from the ones CLA mentioned so you have a test case for your script). Your organization is also based on a way that made sense to you.
When I said DEFAULT, I really meant a DEFAULT-VISUAL-QUEUE that has nothing to do with the inner workings of DF. The goal of my grouping is to optimize the information that the player can grasp from the UI, but do so using only tokens that exist in DF. . . .&
The only difference is that I'm picking one profession from each group to work as DEFAULT-VISUAL-QUEUE and title of the group (instead of a comment that DF doesn't read). I'm simply formalizing what Rydel, Burned, and Telltale, (and all humans I would argue) naturally do.
When looking at these groups remember that if a tile exists for any of the professions in the list it will be used (if not, ONLY ITS APPEARANCE will be defaulted to the one at the top of the list).
. . . KING, KING_CONSORT, QUEEN_CONSORT don't exist as far as I know. They are covered by MONARCH and MONARCH_CONSORT. Again, I don't recall why I left QUEEN in there, because the elf QUEEN is the LEADER profession much like the PRINCESS position is actually defined by GENERAL for elves and I don't even see LEADER on your list. Nor do I see WARLORD or WARRIOR."
"I would have preferred to use NOBLE or LEADER (as Burned, and Telltale do) instead of DUKE, but neither NOBLE nor LEADER are true professions"
. . .the elf QUEEN is the LEADER profession . . .
Now all this speculation would be over if Toady would simply include a complete list in the raws. That would make our lives so much easier! Is anyone here his friend? can we make a request for this information for future versions of DF?
I think at this point we do too much designing and too much optimizing too early. We should factor out problems and roadblocks for now and just get a working, simple script soon.
<task list>
Instead of grinding our teeth on making a wholesome script from the beginning, and burning out everyones energy and interest. I think this gives us more time (and maybe more people) to research positions and professions, and Quiet-Sun has a more reasonable sequence to get familiar with DF and the whole process without being weighted down by unsolved problems. Furthermore, this would open up the whole idea to more people earlier and give us a broader test-case environment.
Worst case, we have a script for creatures only that might or might not get expanded in the future. Best case, we have a solid base to slowly expand.
Right now, the worst case is endless development hell as we stumble upon problem after problem and never get anything finished.
@Quiet-Sun I still have no idea what's going on with the red tiles or if a script for the graphic set page is possible or whether that new "default" even makes sense. However, I'm not going to comb through another list of yours to see if it's correct. The entire point, I thought, was to automate the process which in turn would solve the existing problems in the repo as it is right now instead of manually updating each set.
I sincerely appreciate the effort you are putting into this, but I feel it's a tangent overlooking the current problems of the repo and possibly just adding new ones. I would suggest using CLA's task list as a starting point and ignore everything else, because I'd love to see what you can come up with in the end.
The graphics_example.txt is incomplete.
The limit was first noted in the 40d discussion (http://dwarffortresswiki.org/index.php/40d_Talk:Graphics_set_repository) (under limitations), whenever it comes up (http://www.bay12forums.com/smf/index.php?topic=154711.msg6717092#msg6717092), and it's been on the current notes of the wiki page (http://dwarffortresswiki.org/index.php/DF2014:Graphic_set#Notes) ever since CLA started this thread (http://www.bay12forums.com/smf/index.php?topic=144246.0).
Maybe there is an exception I missed, but I don't think any animal person has the [INTELLIGENT] tag. Offhand, pixies and fairies are [INTELLIGENT], but do not have professions.
As mentioned earlier, Gorlaks and Plump Helmet Men are an odd exception; they don't have ANIMAL_PERSON, but they do have [CAN_LEARN] (and theoretically can have professions), but blind cave ogres, maneras, dark gnomes, mountain gnomes and many other things have [CAN_LEARN] and they definitely do NOT have professions.
Thank you so much @burned and @Rydel
So, if I base my script solely on the raws. Would you agree with the following definition statement?
creatures that need profession tile art are those containing the text: ":ANIMAL_PERSON]", " [INTELLIGENT]" , &/or "[CAN_LEARN]"
Maybe there is an exception I missed, but I don't think any animal person has the [INTELLIGENT] tag. Offhand, pixies and fairies are [INTELLIGENT], but do not have professions.
As mentioned earlier, Gorlaks and Plump Helmet Men are an odd exception; they don't have ANIMAL_PERSON, but they do have [CAN_LEARN] (and theoretically can have professions), but blind cave ogres, maneras, dark gnomes, mountain gnomes and many other things have [CAN_LEARN] and they definitely do NOT have professions.
All animal people are [INTELLIGENT], or at least [CAN_LEARN][CAN_SPEAK]. It's in their creature variation.
The ones that need profession tiles are the ones with:
- Their own entity;
- LOCAL_POPS_PRODUCE_HEROES; or
- LOCAL_POPS_CONTROLLABLE.
Though I'm not sure if there are any CONTROLLABLE that don't PRODUCE_HEROES or have their own entity.
The animal person templates contain both HEROES and CONTROLLABLE, so any critter with either of those templates meets the requirements.
All animal people are [INTELLIGENT], or at least [CAN_LEARN][CAN_SPEAK]. It's in their creature variation.
Ah Button, thank you! this is very helpful! What do you mean by "having their own entity"?
[ENTITY:MOUNTAIN]
[CREATURE:DWARF]
...
...
...
All animal people are [INTELLIGENT], or at least [CAN_LEARN][CAN_SPEAK]. It's in their creature variation.
I definitely see [CAN_LEARN] and [CAN_SPEAK] in the creature variation, yes. But, I only see [INTELLIGENT] in the standard races, pixies and fairies. I suppose it doesn't matter, since it doesn't narrow down the scan for animal people.
Also, isn't scanning for ANIMAL_PERSON and/or ANIMAL_PERSON_LEGLESS tags better than scanning for the LOCAL_POPS tags?
Maybe I'm wrong, but my understanding of Quiet-Sun's script is that he'll get zero CREATURES tagged with either LOCAL_POPS tags, because he's scanning the raws as is not how they are defined in game.
Hi All!
I just wanted to update the upload after cleaning the output files a little. Burned was of great help and it seems to be working as inteded now.
This is the updater. It's a tool for finding and correcting simple but easy-to-miss name changes (a space with an underscore, changing the order of words). It will also give you a comprehensive list of all the differences between your set and the raws. This way you can fix manually whatever is wrong and add whatever is needed. A copy of spacefox is included for testing.
https://dl.dropboxusercontent.com/u/408446/DF/Applications/QS_GraphicsSet_Updater_1.03.zip
Now to finish up the standardizer!
Can I suggest starting a new thread for this, since it's not only relevant to the df-graphics organisation?
(It would also be good to host code on Github or similar, or at least binaries on DFFD)
I'm Das24680 from YouTube and you had kindly linked my tutorial series into your Starter Pack.
I'm in the middle of quite an epic series at the moment on YouTube and have tweaked a few elements within DF. I post the links online to my personalised files but I still get questions from people on why my version looks different to theirs. Recently I've revised the Spacefox text to make it 12x16 which makes portions of the game much more legible (trading etc) so was wondering if you wanted to include it in your pack along with some of the other files I use? No problem if you prefer to not include the files. :)
Link to the Spacefox 12x16 Text is http://www.mediafire.com/view/ym7n9bn6x6z160n/Das_Spacefox_Text.png
By the way, did fricy mention to anyone that he was going to be away? He hasn't logged onto the forum or github in 2 weeks. I'm getting a little worried.
Ok, ok, I'll get on it. It will be needed anyways, since I won't have much time on my hand between April-August. I'll make a thread for the repo, and create an organization on Github with all the individual packs, so others can keep the flame going when I'm not around.
Excerpted from a recent PM I received - an additional 12x16 Spacefox tileset.I'm Das24680 from YouTube and you had kindly linked my tutorial series into your Starter Pack.
I'm in the middle of quite an epic series at the moment on YouTube and have tweaked a few elements within DF. I post the links online to my personalised files but I still get questions from people on why my version looks different to theirs. Recently I've revised the Spacefox text to make it 12x16 which makes portions of the game much more legible (trading etc) so was wondering if you wanted to include it in your pack along with some of the other files I use? No problem if you prefer to not include the files. :)
Link to the Spacefox 12x16 Text is http://www.mediafire.com/view/ym7n9bn6x6z160n/Das_Spacefox_Text.png (http://www.mediafire.com/view/ym7n9bn6x6z160n/Das_Spacefox_Text.png)
Wait, Fricy vanished?
Damn...
FricyFricyHeIsOurManIfHeCantOhWaitCrapNearly spat out my drink.
DFGraphics2 would be my suggestion. Something obvious.
Agreed on DFGraphics2. Ideally Fricy would be back at some point and we could merge/link/whatever the two as DFGraphics again.I considered this, but I think it's more likely to cause confusion - people will leave off the "2", and then links are wrong, and so on. A distinct name would be better, and no impediment to merging if that ever happens.
I've been sending semiregular emails to gmail, and PMs here and on Reddit for about a month with no response.Wait, Fricy vanished? Damn...He hasn't even answered my "Hey, are you OK?" PM/presumably email. :-\
I heard that this project was made to add TWBT support to everything. Is this still a goal of this project?Yes, but not super-high-priority unless an artist volunteers. We've added generic items to everything thanks to Meph, and some packs (eg Doren's Phoebus) have more overrides. Reducing support for non-TwbT installs is unlikely - while I'd like to undo the raws mess that is "tile magic", too many sets rely on it and the tradeoffs aren't worth it.
Concerning the purpose of this group, Peridexis told me, "The aim is to make maintaining a pack as easy as possible." Does everyone agree with this?If there's a volunteer to make it harder, they can have my job :P
What determines which packs are included in this repository? It looks like maybe it's any pack whose author choses to host it here, in addition to all the packs that are no longer being maintained by their original authors?Exactly. Some, which have been picked up by maintainers who don't want to use GitHub (eg Ironhand by GoldenShadow), should probably be suspended or something but I haven't looked at this lately.
What determines which version of Dwarf Fortress we make these packs compatible with? Do we just always update them for compatibility with the latest version of Dwarf Fortress? To clarify this question a bit, Dwarf Fortress v0.42.06 is the latest version supported by DFHack; Dwarf Fortress v0.43.02 is the latest version supported by Dwarf Therapist; and Dwarf Fortress v0.43.03 is the latest version.The latest graphics pack should match the latest version of DF. Older versions are/should be supported via releases -- on Github you can 'tag' a given state for anyone to download later.
...Dwarf Fortress v0.42.06 is the latest version supported by DFHack; Dwarf Fortress v0.43.02 is the latest version supported by Dwarf Therapist; and Dwarf Fortress v0.43.03 is the latest version.
...Exactly. Some, which have been picked up by maintainers who don't want to use GitHub (eg Ironhand by GoldenShadow), should probably be suspended or something but I haven't looked at this lately.Maybe send a friendly reminder about their GitHub repository?
Concerning the purpose of this group, Peridexis told me, "The aim is to make maintaining a pack as easy as possible." Does everyone agree with this?I agree, moving to github makes it easier to maintain. Having a standard distribution format helps too. Though I would argue that a big part is "to make getting an up to date pack as easy and fast as possible for the end user". It does make it easier for maintainers too, but not more simple. It makes it easier by adding another layer of complexity (standard distribution format, github organization).
Several of the packs in this GitHub collection are lagging behind. Several of these like Ironhand, Mayday, Taffer, and Tergel have only been updated to 0.42.05 and are months old. This, despite the fact that some have used and uploaded (DFFD) packages for later DF versions (42.06, 43.02, 43.03...), without updating the GitHub repositories.
What this means is that, while DFHack and certain utilities that many players swear are essential for them to play are (currently) limited to 42.06, while finding graphics packs for that version is becoming difficult since GitHub is still stuck at .05 and a lot of people seem to be jumping on the 0.43 bandwagon.
Imagine, say, months from now where someone regales an amazing story about an amazing fort or adventure they had in a world generated with a mod based on 42.06. And he shares his save or worldgen settings, with others wanting to look at it or play the same world/site. Except, DFFD doesn't have their favorite graphics pack for 42.06 any more because it got updated-over or deleted and the GitHub for their favorite pack either stopped dead at 42.05 or skipped over 42.06 from .05 to some later version.
Edit:...Exactly. Some, which have been picked up by maintainers who don't want to use GitHub (eg Ironhand by GoldenShadow), should probably be suspended or something but I haven't looked at this lately.Maybe send a friendly reminder about their GitHub repository?
Wait... They said that they don't want to use GitHub? Or does it just seem that way?
Concerning the purpose of this group, Peridexis told me, "The aim is to make maintaining a pack as easy as possible." Does everyone agree with this?I agree, moving to github makes it easier to maintain. Having a standard distribution format helps too. Though I would argue that a big part is "to make getting an up to date pack as easy and fast as possible for the end user". It does make it easier for maintainers too, but not more simple. It makes it easier by adding another layer of complexity (standard distribution format, github organization).
What determines which packs are included in this repository? It looks like maybe it's any pack whose author choses to host it here, in addition to all the packs that are no longer being maintained by their original authors?Exactly. Some, which have been picked up by maintainers who don't want to use GitHub (eg Ironhand by GoldenShadow), should probably be suspended or something but I haven't looked at this lately.
These packs' authors don't don't use GitHub. And they also don't edit any objects files:
- Taffer (http://www.bay12forums.com/smf/index.php?topic=107924.0)
Minimal update to 0.43.01, including the keybindings. Life is happening. All current projects put on hold--not abandoned--for the next while (ie, rewritten creature descriptions (https://github.com/nc-z/df-raws), updates to my tilesets, updating my DFgraphics (https://github.com/DFgraphics/Taffer) repository).
I'll still keep things updated for new releases, but I don't even have DF installed at the moment. I still welcome contributions to the rewritten creature descriptions.
These packs' authors don't don't use GitHub. And they also don't edit any objects files:
- Taffer (http://www.bay12forums.com/smf/index.php?topic=107924.0)
Github (https://github.com/nc-z/taffer). It's been the primary download for my pack ever since DFFD switched hosts. I've also updated to new releases on Github pretty consistently, often the same day the release hits. Evidently I need to start doing so in the DFGraphics repo as well.
While I'm here, what subset of my tilesets should I include? I have almost no usage data whatsoever on what parts of my pack get used, and no interest in cluttering up the Newbie Pack with all 32 current tilesets. I've been maintaining a sans-serif font for years now at the request of one user (who didn't post after), but I haven't ever seen it used to my recollection, nor have I had any comments on it. By what little usage metrics I have, I'd be better off including my "dwarves are letters" version, because I have at least 2 users of those sets. I've seen screenshots of all four wall variants, so I'll keep those in.
Sorry, I was looking at the commits to each pack on the DFGraphics repo to try to determine who used GitHub. Maybe we can make the one on the DFGraphics automatically sync itself with your repo. Or maybe we can replace the copy on the DFGraphics group with a link to your repo. I'm not really sure what the options all are. It seems silly for you to have to update two, though.
I don't think it's necessary to include all 32. I think you only need to include the 16 "dwarf letters" versions. With graphics turned on, a user will get the smiley faces; with graphics turned off, a user will get the dwarf letters. I don't have a problem with having more tilesets as options, but that seems like extra work for you to maintain.
the DFGraphics format isn't great for manual installations without the aid of a programHow so?
the DFGraphics format isn't great for manual installations without the aid of a programHow so?
[...]
These packs are being maintained by people who don't/no longer use GitHub:
...
- Rally-Ho (http://www.bay12forums.com/smf/index.php?topic=149172.0)
I agree, but that's not the case with the dfgraphics repo. At least not with mine, maybe I'm doing something wrong. The init file that comes with the download already contains the references to the CLA tileset and has GRAPHICS set to YES. You only need to download the "source code" and drop it into a fresh DF install.
I agree, but that's not the case with the dfgraphics repo. At least not with mine, maybe I'm doing something wrong. The init file that comes with the download already contains the references to the CLA tileset and has GRAPHICS set to YES. You only need to download the "source code" and drop it into a fresh DF install.
You're not doing anything wrong: I just have a lot of tileset options, which need to be set in init.txt (if you use the DFGraphics repository)
You can install just by drag-and-drop, and then change the init if you don't like the default tiles.
|
|
|
|
Don't multi-racial forts imply that all races need all jobs in their graphics definitions, or am I missing something?
This is how I've been distributing my own sets for some time. I'm re-basing my graphics text files on Rally-Ho's (https://github.com/DFgraphics/Rally-Ho) graphics text files because they're clean and nicely formatted, but the goblins, for example, are missing almost every non-military job. Many graphics sets have this same problem from what I've seen, although I haven't looked at all of them. I have nice goblin and kobold monarch graphics, for example, but they'd never show according to these RAW files.
Help would please be greatly appreciated cleaning my files up, if anybody's willing. In the past I just copied and pasted all of the dwarf definitions to the elves, humans, goblins, and kobold files. Ideally, I'd just like to sync my own graphics files (apart from filenames and TILE_PAGE names, of course) with Rally-Ho or something, but these files don't appear complete to me. (Or I have graphics that can't ever be used by the game, like my goblin/kobold monarch tiles).
When goblins end up ruling a dwarven civilization in the current version, do they just revert to a "g" with most graphics packs? Do they revert to using the default definition ([DEFAULT:RALLYHO_GOBLIN:0:0:AS_IS:DEFAULT])?
I'm willing to help with stuff. Are you making a bunch of creature graphics for your tileset?
I'm pretty sure that if there's not a match, it falls back to the default graphic.
Races like Goblins don't have a full sheet yet since I'm working on another, unrelated project at the moment. Once that's finished, I plan to expand them to a full sheet.
Maybe use 4 corpse tiles for a non-TWBT version. There's a few unused tiles in GemSet.I think just a single Jolly Roger would suffice, though a special one for dwarves with a beard might be nice. This probably isn't the thread to discuss it, though.
From left-to-right: dead dwarf, dead other humanoid, dead other creature, dead titan/forgotten beast.Spoiler: corpses (click to show/hide)
Maybe that's too many tiles to spend on corpses, though.
Please continue using TWBT as much as possible, even if things lag behind. I'm happy to keep my DFGraphics repository in line with the current version that DFHack supports, rather than the current version.PeridexisErrant said it would be better to update for the current version of Dwarf Fortress and use releases to support older versions. By keeping the graphics packs up with the latest version, it should getting a version that supports TWBT faster once it gets updated for the latest Dwarf Fortress. Do you remove old profession tokens from your pack? I don't think there's a problem with leaving them all in if you want your pack to work with every version of Dwarf Fortress.
I know that increased community reliance on DFHack and TWBT is an odd request coming from somebody who never uses them, but there's just far too many problems with the default graphics engine and by his own admittance Toady has no interest in fixing them, nor does he know how. (Also, almost every graphics bug that I've seen in the bug tracker is flagged "Minor", and barely considered worth fixing).Yeah, I get the feeling that he's not too fond of graphics packs.
This approach will turn every creature into a corpse whenever they're out of sight (yet still onscreen) in Adventure mode and also whenever they're engraved anywhere. Probably other places that I'm forgetting. It's not going to be fun playing adventure mode and never being certain what anything is, because everything looks like a corpse until you get close to it. This is besides all of the art DragonDePlatino added that requires TWBT.Thanks for the explanation. I had heard about this bug before. Someone said he heard that the bug with creatures turning into their letters when out-of-sight might have been the inspiration for the design of CLA's graphics pack – by drawing the creatures as letters, they still look about the same when they transform into letters. (I was googling trying to find that thread, but couldn't come up with anything.) That's clever how DragonDePlatino dealt with the issue of corpses turning into letter. It seems like CLA's solution was designed to work without TWBT, though, making it great for adventurers who wish to run the latest version.
TWBT is the best thing that's happened to the graphics packs in a long time, and I would truly hate to see things regress to not using it. Any feature or bug fix added by a version newer than DFHack supports isn't worth the ugliness and problems introduced by removing TWBT (for the sets that rely on it). I know you're not planning on removing the TWBT version, only adding a non-TWBT variant, but in my opinion you're taking away too much to make the branch worth it.I don't think a non-TWBT GemSet would have to look ugly. I think it'd be best to start with gemset_text.png for the main tilesheet and use CLA, Grim Fortress, Tergel, and the tileset wiki page (http://dwarffortresswiki.org/Tilesets) as guides on where graphics should be placed. I think Tergel does a good job of drawing things that look like they could represent more than one thing. CLA and Grim Fortress both place graphics in the main tilesheet conservatively, and they all make few to no edits to the objects files.
In my personal opinion, the only graphics sets that don't need to rely on TWBT are the almost-ASCII variants like mine, where turning off the graphics doesn't affect the aesthetic and creature graphics aren't used much. (And perhaps CLA, who specifically drew creature graphics knowing these limitations, but that's up to CLA).I think it's just fine to have lots of creature graphics without using TWBT. Most players (maybe about 61%) don't use TWBT. Of those players, about 45% use a graphics pack that contains lots of creature graphics. Most graphics packs work well enough without TWBT; it looks like DungeonSet and GemSet are the only ones that really require it at the moment.
I'm happy to keep my DFGraphics repository in line with the current version that DFHack supports, rather than the current version.
I think it's best if new players start playing without DFHack...
...there's just far too many problems with the default graphics engine and by his own admittance Toady has no interest in fixing them, nor does he know how. (Also, almost every graphics bug that I've seen in the bug tracker is flagged "Minor", and barely considered worth fixing).
PeridexisErrant said it would be better to update for the current version of Dwarf Fortress and use releases to support older versions. By keeping the graphics packs up with the latest version, it should getting a version that supports TWBT faster once it gets updated for the latest Dwarf Fortress.
Please continue using TWBT as much as possible, even if things lag behind.
I think it's just fine to have lots of creature graphics without using TWBT. Most players (maybe about 61%) don't use TWBT. Of those players, about 45% use a graphics pack that contains lots of creature graphics.
...And by not starting out new players out on DFHack and TWBT, they won't become reliant on them from the start and will make a future transition into vanilla easier for them, if they ever decide they'd like to try it.
...but ASCII can be intimidating for many users. Even for someone coming from Dungeon Crawl Stone Soup, the large variety of ASCII in Dwarf Fortress is kind of overwhelming at first.
Why suggest that newbies try to get into DF without DFHack? As long as the installation is hassle-free, it can just sit in the background, right? It comes with Stonesense and I think that, alone, can be a big help getting into DF.
I think some players do not appreciate how much certain Utilities and Mods rely on either DFHack or the memory offsets that team finds, or at least underestimate how many players use DFHack in some way. For instance, some players can't imagine playing DF without Dwarf Therapist.
Anyway, all the Starter Packs still come with DFHack. Those are still recommended to newbies, aren't they?
That makes sense, as long as maintainers try not to skip over an older version that DFHack is currently still limited to (or erase/overwrite their older versions).
I've been away from DF for a while and I only recently heard about TWBT. So I haven't tried it, yet. And, actually, while it looks and sounds great, I'm a bit hesitant...
It's nice to be able to see more than one Z-level at once, but it can make it kind of confusing to determine which level the cursor is on.
I remind that for some tilesets, fog colour/density and shadow colours may need to be adjusted. I only use Spacefox tileset and the default parameters are tweaked for it. Other tilesets are usually darker and indeed with the default parameters it's hard to distinguish between z-levels.
I remind that for some tilesets, fog colour/density and shadow colours may need to be adjusted. I only use Spacefox tileset and the default parameters are tweaked for it. Other tilesets are usually darker and indeed with the default parameters it's hard to distinguish between z-levels.
Thanks for the help. More fog sounds like what I need until I get more used to it. I remember seeing an old screenshot and wishing it could still look like that.Spoiler: old TwbT example (click to show/hide)
But maybe a change to the fog color would also make it much more obvious to me.
. . . I kind of thought [Duerer] would already be on the repo . . .
. . . Maybe Duerer was removed at some point?
. . . Maybe I'm just overlooking it?
Spoiler: list of settings that graphics packs probably shouldn't be changing (click to show/hide)Do you think graphics packs should be allowed to modify any of those? Currently the Lazy Newb Pack doesn't allow graphics packs to modify any of those three. Should a graphics pack artist have any control over any of those?
- engravings start obscured
- varied ground tiles
- show flow amounts
I don't believe I modify any of that (let me know if I do) and I agree that graphics packs shouldn't modify the settings you specified. Almost all of them are clearly personal preferences and have nothing at all to do with the graphics: with a few exceptions, which I shall detail below.
I think it's important to exempt the following:
• intro,
• engravings start obscured, and
• varied ground tiles.
In my opinion, all of the above look pretty lousy with the default settings for any graphics pack or tileset that isn't an ASCII lookalike (most of them). In addition, several sets are drawn with the assumption that varied ground tiles are turned off, so reverting that breaks visual consistency. It would be a mistake in my opinion to revert any of these settings for graphics sets that weren't meant for them.
You didn't mention it and it's not obvious, but I find that zooming looks much better for my set with texture_param set to nearest, so I do think that setting is also acceptable to modify.
Is suspect that most packs that change these (not sure if mine does) come from the author basing it off their own init file, forgetting that they'd made modifications to it.
Does Rally Ho! change any of those?
In response to the init field question: on the PyLNP end, I've opened this issue (https://bitbucket.org/Pidgeot/python-lnp/issues/119/) to have the launcher handle more - I think this is now the full list of graphics-related init fields.
PyLNP's requirement that all graphics packs include both a "mouse.png" and "font.ttf".
There was an issue with a library on OSX/Linux if I understood that correctly:
http://www.bay12games.com/dwarves/mantisbt/view.php?id=2688
That would break the desirable property that copying graphics over a DF install correctly installs the graphics - we want them to be very simple to do manually or automatically.
An alternative approach (which I prefer) would be to add "twbt_data" and "raw/twbt_objects" folders, and copy them over the non-twbt pack if TwbT is enabled. Regardless, any further discussion should happen in the DFgraphics thread, as it's not really about the Starter Pack.
The trick would be to only retain twbt_X files that are different to the standard ones - I think that would cut the file size down some more.
I'd tend to ship all the tilesets, and stick with the original sizes by default (for better small-screen and creature tile compatibility). However we should probably take any references to tilesize out of the pack names, and maybe think about improving PyLNP support for variable-tilesize packs and a target tilesize.
I noticed Rally Ho getting some support for Fortress Defense (one of the most popular mods). Is it okay to start adding mod support to some of other graphics packs (i.e. Afro, GemSet, Ironhand, Mayday, Obsidian, Phoebus, and Spacefox)?
Eventually it would be nice for the mods to be able to include their own graphics. Currently there are some downsides to doing this, though:
<snip>
For now, the simplest way to add graphics support for mods is to include them in the graphics packs themselves.
Initially, I was wanting to add graphics for [three] mods that include their own graphics. This would add about 0.75 MB to each graphics pack, which would be an extra 5MB total for a LNP that includes 7 graphics packs.
I am sympathetic, but this would be too large already and likely to grow.
My ruling: no mod support in vanilla graphics packs.
To balance this: once someone designs a format for graphics to be included in mods, I'll give feedback and once happy implement it in PyLNP.
If my graphics pack already includes support for some mods, would I need to remove them? My graphics pack currently includes sprites for all the Fortress Defense races and Succubus sprites for Succubus Fortress.
Mod graphics addons should probably be able to do these three things at minimum:Bonus Points: Stonesense support
- Add PNGs to the <DF>/data/art/ folder
- Concatenate text to the bottom of the <DF>/data/init/overrides.txt file (if one exists)
- Add PNGs, TXT files, and folders to the <DF>/raw/graphics/ folder
- Add folders to the <DF>/Stonesense directory (if it exists). These folders would be able to contain XML files, PNGs, TXTs, and more folders.
- Concatenate text to the bottom of the <DF>/index.txt file
== Graphics Addon format suggestions ==
Remember that changing the art style of a mod should only affect the .png file(s). The text-based stuff is shared across all of them, so that should only exist once.
That gives me an idea. Mods add the PNG files, but the graphics packs add the text files.This still has the issue of spreading the art assets over multiple unrelated folders, making maintenance more difficult that it needs to be.
Also, I think it would cause blank sprites if one graphics set has hunting/war sprites for an animal but another does not.It would crash at worldgen. If a graphics file directs to an image that does not exist, the game crashes to desktop.
Sorry I wasn't clear... I meant the sprite sheet that deals with a particular mod. The sprite sheet that comes packaged with The Earth Strikes Back! looks like thisRemember that changing the art style of a mod should only affect the .png file(s). The text-based stuff is shared across all of them, so that should only exist once.
If a graphics pack doesn't have a one-to-one relationship on creatures (i.e. some very similar creatures sharing graphics), this wouldn't work. Also, I think it would cause blank sprites if one graphics set has hunting/war sprites for an animal but another does not.
Having additional copies of the Graphics text files isn't going to use a lot of space - Fortress Defence's Graphics Text files are a combined 50 KB in Rally Ho!.That gives me an idea. Mods add the PNG files, but the graphics packs add the text files.This still has the issue of spreading the art assets over multiple unrelated folders, making maintenance more difficult that it needs to be.
Or is PE not going to include mods in his?
I think PE might want to keep it really simple for now. I'm wondering if filename switching is more complicated than what he wants to implement at this time. If PyLNP would install the graphics from the mods, then install the graphics pack, then install the mods' raws and stuff, I think think that would work just fine for initial support.Pro: I can support this standard with my current distro, meaning zero marginal effort on my part. Artists can support modded stuff at their own pace with no compatibility-breaking jumps in the graphics pack format. And, did I mention zero marginal effort for me? :)
This would allow mods to have their own default graphics. It would allow graphics packs to override a mod's graphics with their own (or with nothing for ASCII-ish packs). And it would allow the mods' raw objects files to override the graphics pack's raw objects files.
@Rydel: items can in fact be referenced by name (https://github.com/mifki/df-twbt#overrides), so we can avoid the problem of numeric IDs changing. Perhaps we (or Mifki) should detect use of numbers and issue a deprecation warning?
Are you talking about making this a new folder in the /LNP/ folder? Like a /LNP/GfxExt/ folder or something? (There's probably a better name for it than that, though.)
- It must be possible to make a Graphics extension compatible with an arbitrary graphics pack, without the cooperation of the graphics maintainer. I understand that most of the people in this thread fill both roles, but the format we choose should work for more casual creators too - or we'll never see much takeup! (ie: mods mst be entirely self-contained)
Instead of trying to use existing lines in the manifest, it might be better to have new lines just for this instead of trying to use regular expressions on existing lines. Make special manifest lines just for mod graphics so that there's no need to change them except to adjust what graphics extensions get used with a graphics pack or mod. Then the manifests of the graphics extension packs could have two lists, one to list the graphics packs it should be used with and another to list the mods it should be used with. Whenever a user installs a graphics pack or a mod, PyLNP would also install every graphics extension pack that had at least one hit in both lists.
- Support multiple graphics extensions in a single mod. Easy to store in a subfolder; but how would you flexibly decide which to install? Possible: categories like MIME types, regular expressions, something else. (Must support a default for drag-and-drop install)
I thought I tested to see if this would work like a month ago and PyLNP v0.11 wouldn't install any PNG files from mods.
- To support graphics, mods just include graphics raws and images. As long as they don't have the same name as a file in the graphics pack, this already works! (I just checked the code - apparently I thought of this two years ago :) )
He talked about people being able to make graphics extensions without needing to collaborate with mod authors or graphics packs authors, so I thought graphics pack extensions might be getting their own spot.I was envisioning an arbitrary list in the mod's JSON file, not tagging the graphics packs themselves.
Would I still be able to specify graphics packs by name instead of by category? I'd like to have the ability to specify different sets of graphics for Spacefox and GemSet.
Would each graphics pack need to tag it's manifest with categories to describe itself? Maybe use tags like "cartoon" "ASCII-shaped" "monochrome".
Maybe there could be a way to categorize by size too, so you could provide different-sized versions of graphics in the same category.
@Rydel: items can in fact be referenced by name (https://github.com/mifki/df-twbt#overrides), so we can avoid the problem of numeric IDs changing. Perhaps we (or Mifki) should detect use of numbers and issue a deprecation warning?
That link shows names for Ids and Types, but last I heard, subtypes are still numerical. This would be a problem for mod support since subtypes for existing entries can change when you install a mod.
Graphics modules won't support overrides until multiple overrides.txt sheets can be used alongside each other.Why? Can't you merge the override file just like you merge the raws?
[TILESET:tileset:tileset.png:_any_name_you_want], modders could just use unique names for each set, like "_MEPHS_STUFF_VERSION_1_2".
Suggested starting point:
- (recap:) A mod in PyLNP format is simply a DF install with the vanilla files removed. We then merge the raw/ and data/speech/ files.
- To support graphics, mods just include graphics raws and images. As long as they don't have the same name as a file in the graphics pack, this already works! (I just checked the code - apparently I thought of this two years ago :) )
- Support for data/art and data/init/<overrides files> will be added once Mifki supports multiple overrides files.
- (for discussion) How should non-default graphics extensions be stored? How should PyLNP choose which to install? Does this work with multiple mods?
Running PyLNP 0.12 (OS: win, Compiled: True)
WARNING: JSONConfiguration: File PyLNP.user does not exist
ERROR: In "TESB": : file "graphics\graphics_TESB_creatures.txt": : Writing to .\LNP\Baselines\temp\raw\graphics\graphics_TESB_creatures.txt failedAdding that capability would simplify installation.If multiple mods try to add overrides, all but one overrides file would get overwritten.How do you want to install mods in that case? I was under the impression that the PyLNP merges the raw files. If it would just replace files, you can barely install any two mods at the same time. Anything that changes vanilla DF files would be impossible.
As for TWBT overrides, the easiest solution (for everyone except mifki) would be to use named subtypes. With numeric subtypes, it's possible that more than one mod could add subtypes to the same type. One solution would be to keep a running map of each mod's subtypes to a global list of subtypes (they should each be written as if they were modifying vanilla entries or adding directly to the end of vanilla). Though conceptually simple, it just feels error-prone and thus would need the option for verbose logging.
Vanilla ARMOR:1 -> ARMOR:1
Vanilla ARMOR:2 -> ARMOR:2
...
Vanilla ARMOR:11 -> ARMOR:11
SuperMod ARMOR:12 -> ARMOR:12
SuperMod ARMOR:13 -> ARMOR:13
UltraMod ARMOR:12 -> ARMOR:14
UltraMod ARMOR:13 -> ARMOR:15
UltraMod ARMOR:14 -> ARMOR:16
XenoMod ARMOR:7 -> ARMOR:7 // Redefining a vanilla object.
Slip the mapped values into the tempfiles, then concatenate them into a single overrides.txt file.
You can circumvent that by using TWBT overrides for the plant. Regardless of how the tilesets look you use, the mod graphics for the plant would always look the same.Plant overriding in TWBT requires a lot of raw edits. TWBT on its own can't tell the difference between shrubs, fruit, leaves, dead plants, etc, so all of those need to be overrided in the raws.
I don't know what a subtype is. Can I make a TwbT override without using a subtype? (Do "main types" or "super types" exist or something?) If the subtypes can never be known, are overrides completely useless?Subtypes are how the game identified items in the same category.
As for TWBT overrides, the easiest solution (for everyone except mifki) would be to use named subtypes.I agree, but I think I've asked about that feature before and it wasn't possible. I think DFHack doesn't know the names the raws used, it just has the number pulled from the program itself. For things like Id and Type, those won't change, so they are known at compile time and can be given specific names.
Correct, mods cannot pick the subtype numbers, but they are assigned in a deterministic order based on the known order in which raws are parsed. The thing to prevent is someone jumping in front of the vanilla stuff.For preventing files from jumping in front of vanilla stuff, the easiest way I can think of it to prepend all the mod files with "zz_", forcing them to be last alphabetically.
but you don't need the graphics pack to help you or even know graphics extensions exist - so they'll be backwards-compatible :)The dictionary map would be a sort of spreadsheet in the mod's manifest that tells PyLNP which graphics extension goes with which graphics packs, right? Can it do a partial match on the graphics pack, in case a user has renamed two copies of Phoebus to things like "Phoebus v0.43.03" and "Phoebus v0.43.05", for example?
[...]
How does PyLNP decide which graphics extension to install?
The manifest for a mod will have a new attribute "graphics-extensions", which is a dictionary mapping graphics packs to subdirectory names (see above).
Technically, the extension is just another mod to merge (so object files can be changed)That's good to hear. That's something that's currently not possible with mod support added to graphics packs.
PyLNP will install the default mod (which includes graphics), then if the installed graphics pack matches a subdirectory (per the mapping) will install the relevant extension. Mod authors may therefore wish to provide nothing as the default extension (ie leave /raw/graphics and twbt files nonexistent), to avoid installation clashes.That sounds good.
Maybe mods writing to raw/graphics is banned by code elsewhere?Sorry, I just tried it again (in PyLNP v0.11) and it worked. I was probably looking in the wrong Dwarf Fortress folder when checking to see if it installed. I think I did that at one point and couldn't figure out why nothing would install.
PyLNP [...] merges .txt (eg raws)It's not working like that for me. From what I can tell, if a user tries to install more than one mod (like Spellcrafts, Haberdasher, and The Earth Strikes Back, for example) that all want to edit to the same file (such as entity_default.txt), only highest-listed of those mods in the "Merged" list of the "Mods" tab will have a green background color (and will installed normally). The lower-listed mods trying to edit that file will have white backgrounds (and will silently not be installed).
Can it do a partial match on the graphics pack, in case a user has renamed two copies of Phoebus to things like "Phoebus v0.43.03" and "Phoebus v0.43.05", for example?PyLNP [...] merges .txt (eg raws)It's not working like that for me. From what I can tell, if a user tries to install more than one mod (like Spellcrafts, Haberdasher, and The Earth Strikes Back, for example) that all want to edit to the same file (such as entity_default.txt), only highest-listed of those mods in the "Merged" list of the "Mods" tab will have a green background color (and will installed normally). The lower-listed mods trying to edit that file will have white backgrounds (and will silently not be installed).
I kind of thought the files it really could mess with (other than its own) were init.txt and d_init.txt.
QuoteAlso, I think it would cause blank sprites if one graphics set has hunting/war sprites for an animal but another does not.It would crash at worldgen. If a graphics file directs to an image that does not exist, the game crashes to desktop.
This is fine. Graphics yes, creature no = no problem.QuoteAlso, I think it would cause blank sprites if one graphics set has hunting/war sprites for an animal but another does not.It would crash at worldgen. If a graphics file directs to an image that does not exist, the game crashes to desktop.
I think it might not crash if the graphics are for creatures that do not exist in the game.
| New flat compressed graphics: | 2.3 MB (1.3 MB zipped) |
| Old uncompressed graphics: | 5.9 MB (4.6 MB zipped) |
add a source/README.md file that explains how to convert the source to output version.
Spoiler: quote jecows (click to show/hide)
That would break the desirable property that copying graphics over a DF install correctly installs the graphics - we want them to be very simple to do manually or automatically.
An alternative approach (which I prefer) would be to add "twbt_data" and "raw/twbt_objects" folders, and copy them over the non-twbt pack if TwbT is enabled. Regardless, any further discussion should happen in the DFgraphics thread, as it's not really about the Starter Pack.
In addition to that, most tileset authors can save about 50% size on all creature graphics by removing the war/hunting versions. Most sets I've seen just brute-force that, make a war/hunting version for every creature... but only 22 creatures out of 767 are actually trainable.
| 1. | DOG | creature_domestic.txt |
| 2. | BEAR_GRIZZLY | creature_large_temperate.txt |
| 3. | PANDA, GIGANTIC | creature_large_temperate.txt |
| 4. | ELEPHANT | creature_large_tropical.txt |
| 5. | LION | creature_large_tropical.txt |
| 6. | LEOPARD | creature_large_tropical.txt |
| 7. | JAGUAR | creature_large_tropical.txt |
| 8. | TIGER | creature_large_tropical.txt |
| 9. | CHEETAH | creature_large_tropical.txt |
| 10. | MANDRILL | creature_large_tropical.txt |
| 11. | GORILLA | creature_large_tropical.txt |
| 12. | BEAR_POLAR | creature_large_tundra.txt |
| 13. | JABBERER | creature_next_underground.txt |
| 14. | CAVE_DRAGON | creature_next_underground.txt |
| 15. | DRAGON | creature_standard.txt |
| 16. | BIRD_ROC | creature_standard.txt |
| 17. | BOBCAT | creature_temperate_new.txt |
| 18. | OCELOT | creature_tropical_new.txt |
| 19. | LYNX | creature_tundra_taiga_new.txt |
| 20. | BAT_GIANT | creature_subterranean.txt |
| 21. | BIRD_SWALLOW_CAVE_GIANT | creature_subterranean.txt |
| 22. | RHINOCEROS | creature_large_tropical.txt |
[OVERRIDE:old-tile:B:TRAP:Trap:1:new-tileset:new-tile] pressure plate
[OVERRIDE:old-tile:B:TRAP:Trap:2:new-tileset:new-tile] cage
[OVERRIDE:old-tile:B:TRAP:Trap:3:new-tileset:new-tile] stonefall
[OVERRIDE:old-tile:B:TRAP:Trap:4:new-tileset:new-tile] weaponI don't understand the question about LNP-like Utilities? Are there alternatives to PyLNP?I thought so. Isn't there one for Mac, one for Linux, the original LNP, etc? I'm probably wrong though, I never used these packs.
Those packs are in non-TWBT form until the TWBT parts of those packs are moved into the main parts.So users will still have to move the other 4 folder contents, even if onLoad.init is placed by the maintainer?
Is there any point in keeping the “ASCII” versions of these graphics packs updated ice they are converted to the new graphics format? I can go back and make a branch or something from an old commit at a later point if it turns out they’re needed, right?