Bay 12 Games Forum

Some updates on the tileset soon (I'll just wait for the next DF version).

Made the down ramps smaller and give them the same background as lower elevation tiles.
Considering that there technically aren't any down ramps in the game, only up ramps viewed from the level above, I think this is a good change.



Additionally, I simplified the door, log, and bed tiles a tad bit.
I'm also working on new leaves. Still not happy with them though.

I just renamed my init.txt, and DF starts up without problems. Interestingly enough, some of its internal defaults don't match the defaults in init.txt - for example, FULLSCREEN defaults to PROMPT.

Well, I'll be damned. Just tried an init.txt with nothing but
[SOUND:NO]
[INTRO:NO]
[FONT:CLA.png]
[FULLFONT:CLA.png]
[GRAPHICS:YES]
[GRAPHICS_FONT:CLA.png]
[GRAPHICS_FULLFONT:CLA.png]
[PRINT_MODE:2D]
Mode examples:
PRINT_MODE:2D
PRINT_MODE:TEXT
PRINT_MODE:FRAME_BUFFER
PRINT_MODE:PARTIAL:0
[SINGLE_BUFFER:NO]
[TRUETYPE:YES]
[FPS:YES]
And it worked exactly as I expected.
Same for d_init.txt. Apparently the issue was only with the recently newly introduced values.
Seems like my suggestion was unnecessary after all.

Whatever happened to these composite footprint images?

I assume they got scrapped because it would have been too much work to research and integrate footprints for every creature, but is that still planned to be added in the far future?
I'd say that's great opportunity for the community to collect some data and transform it in a meaningful format.

Right I get that, but since almost nobody ever would want to use custom init settings WITHOUT having already tweaked their own, the concept of multiple init file layers is confusing and odd, and would probably cause more unexpected behavior than anything helpful.

Yes, yes. I agree. I'm saying there is only one init file (and one d_init, you get what I mean). The only difference is that DF won't shit itself when something's missing, and you could potentially have an empty init.txt, or have one with only one setting.
Most likely the average user wouldn't even notice the difference. Except in the rare cases where some new line gets added and he would fuck up DF when he tries to transfer settings by overwriting.
And graphic set creators would have to worry about less.

Whereas, by contrast, a ton of people may want to download raw-adjusting mods without ever having touched the raws. Or if they are touching the raws, they probably know more what they're doing than just somebody who wants to change some simple init settings, and so they're more likely to do it correctly with their own separate file that won't cause overlap issues.

Regarding raws, I'm mostly worrying about mod/graphic set maintenance again. Although being able to freely assign tiles to any object some time in the future would make that obsolete anyway.

I propose to separate the default init values (init.txt, d_init.txt, maybe even announcements.txt) and default raws from user changes
Either by hardcoding fallback values and accepting missing entries in init/d_init.txt and raws, or by having a separate file called user_init.txt and a folder user_raws or whatever.

If a user only wants to change the popcap to 50, he shouldn't deal with the entire init file, but instead create a new, empty text file and add the line [POPCAP:50].
If someone made a mode that only changes the color of puddingstone in the raws, he would only distribute an inorganic_stone_mineral.txt file containing nothing but the entry for puddingstone.
Just deleting the file would revert it back to default.

Depending on the above variants DF would check on startup for user_<d_>init.txt entries or missing values in <d_>init.txt, and fall back to known defaults.
Ideally, you would get a message on startup if something's wrong (file 'mytileset.txt' in data/init/user_init.txt|[FULLFONT] not found: using default; missing ']' in data/init/user_init.txt|line 23: using default)
Same for raws.


In practice, this would have several advantages:

• It's easier to maintain for modders and graphic set creators
• It's easier to keep an overview for average users, and impossible to fuck up
• It's a lot easier for users and modders to migrate settings and small mods to new versions of DF (the introduction of new values won't generate any issues - as it happened recently with the strict popcap and something else I forgot)

As an seasoned vanilla user for example, you would just keep a tiny init.txt that just contains [INTRO:NO] and nothing else. You could just copy it over to a new DF version without any problems.
On the other hand, a graphic set creator might distribute a init.txt that just contains his tileset path, and [GRAPHIC:YES] without having to worry about newly added values. Changing tiles in the raws would make it less of a maintainance nightmare with raw changes.
It would also be easier to keep an overview over changes to d_init.txt (trunks, tracks, etc) without having to check filechanges every new version. Especially for additions Toady forgot to mention.


Of course the possible values/raws should still be documented somewhere, even if you deleted/changed the files. Not sure what the best way for that would be.

As per http://dwarffortresswiki.org/index.php/40d_Talk:Graphics_set_repository#graphics_sets_vs_object_tilesets

[...] objects are not currently graphically supported yet, and only consist of living entities, it should rather be called 'creature tilesets'. I would wait until Toady adds "Core50, TILESET SUPPORT, (Future): Allow graphical tiles to be used for all game objects" before changing the name to anything. After that, there could be a multitude of tilesets such as 'object tilesets','creature tilesets','terrain tilesets' ect. [...]

and the above comments from Vherid and Taffer, my current plan for creature graphics would look like this:

• creature graphics have their own section on the 'Graphics' page (as it is now in the user talk page)
• new page: 'graphic set' analogous to the 'tileset' page
• intro explains that graphic set is any tileset/sprite sheet/bitmap (which term should I use? I'm leaning towards tileset) that uses [GRAPHICS:YES]; that currently only creatures support this but it's eventually planned for all objects (with link to dev page or the 40d talk page)
• the only main section is creature graphics with detailed explanation of the syntax (I'll adhere to http://dwarffortresswiki.org/index.php/40d_Talk:Graphics_set_repository#Questions:_making_your_own_set as guideline) and so on
• note/small section at the bottom about TWBT and DFhack with link to http://dwarffortresswiki.org/index.php/DF2014:Utilities#Twbt (doesn't exist yet).

@Taffer, Vherid;
Thanks for the input.
I think for now I'll try to stick with "Tileset" and "creature graphics" to avoid confusion. So the section "create your own tileset" will include advice about raw/init changes and creature graphics will be treated in a separate section.
Updated the User Talk page.