Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[CLA]

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.

[GavJ]

This is great for mods, but much more of a PITA for an average user to go actually do just to change a setting or two in init. (having to make a new file and copy paste over, etc.)

I support for raws, but not for init.txt.

[CLA]

This is great for mods, but much more of a PITA for an average user to go actually do just to change a setting or two in init. (having to make a new file and copy paste over, etc.)

I support for raws, but not for init.txt.

With what I suggest, the old behavior would still be possible.
In case there's a separate user file, in a fresh install the user init would of course come with all default settings in it, not empty.

In the other case (defaults just hardcoded in DF), d_init.txt becomes the user init file. DF just wouldn't crash if an entry is missing or faulty.

[GavJ]

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.

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.

[CLA]

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.

[lethosor]

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.

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.

[CLA]

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

Code: [Select]

[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.

[GavJ]

I have to admit I still don't understand the logic of why that is desirable...

I got the original suggestion of having other supplemental files get read first. I think it's unnecessary for init and maybe confusing, sure, but it made sense still. But having hardcoded backup defaults in case the init file doesn't exist or something... why?

It is fairly widely agreed in the coding world that crashing is a superior outcome to mysterious and unexpected behavior. Crashing makes you go find the answer and download a new init file and have the game work. Hardcoded defaults drive you crazy and maybe kill your fort when you weren't expecting things constantly, etc. And possibly ALSO crash the game halfway through when some old, forgotten preset Toady used way back when is now invalid.

There are better options than either, though. The best would probably be a big prominent error message that fills up the screen when a corrupt or missing init is found, with a helpful permalink to the download page and a description of what went wrong and that you need a new init file. Or maybe even if tells you what couple of lines were in error.

[CLA]

It is fairly widely agreed in the coding world that crashing is a superior outcome to mysterious and unexpected behavior. Crashing makes you go find the answer and download a new init file and have the game work. Hardcoded defaults drive you crazy and maybe kill your fort when you weren't expecting things constantly, etc. And possibly ALSO crash the game halfway through when some old, forgotten preset Toady used way back when is now invalid.

Very good point and I'm having a hard time finding a reason to disagree with you here.

I have to admit I still don't understand the logic of why that is desirable...

Really, at first, it was just a thought to make version migration (seemingly) easier for, well, me as a graphic set maintainer.
Then I thought about how some other programs handle user settings (global config files in program directory and user settings in OS specific user directories), and just went from there.

There are better options than either, though. The best would probably be a big prominent error message that fills up the screen when a corrupt or missing init is found, with a helpful permalink to the download page and a description of what went wrong and that you need a new init file. Or maybe even if tells you what couple of lines were in error.

Yeah, more verbose error messages would of course be welcome.

[Antsan]

I support this.
Mainly because every time I have to download a new version and install all kinds of stuff (like tilesets) I have to redo my personal options.
The Duerer tileset for instance overwrites the tree tile values and doesn't touch anything else. Having those changes in its own file would be quite nice.