The current handling of "Defaults" (as in, the contents of LNP/Defaults) is a legacy of the original LNP, where there was no known baseline and settings were only changed by overwriting a file.
The popup still notes that the user needs to reinstall graphics packs, a legacy from all-or-nothing file replacement. Why don't we just re-apply the graphics-related settings after applying defaults?
We can also provide genuinely vanilla settings, by using the inits stored in LNP/Baselines. This could remove the need for a defaults dir and special files at all. However, that would remove the capability to use a customised default settings pack.
I propose a solution similar to color schemes or graphics:
Have a special-case "Baseline DF settings", which are vanilla settings drawn from the baselines.
Other defaults are stored in subdirs of defaults (LNP/Defaults/MyCustom/init.txt and LNP/Defaults/MyCustom/d_init.txt)
The above example would be displayed in the defaults listbox as MyCustom
These could use a content manifest (see pull request #43) for name and tooltip; probably overkill but why not allow metadata and tooltips?
We'd need to support a single set directly in LNP/Defaults/*init.txt for backwards compatibility - and log a deprecation warning.
This could start people distributing various settins aggregates; for example defaults for particular mods, new players, hard-mode, FPS limited games, and so on.
[Issue created by PeridexisErrant: 2015-04-26]
[Last updated on bitbucket: 2016-08-28]
[Comment created by PeridexisErrant: 2016-04-08]
Yep, pretty much what I was thinking. File is something like settings.json, and it should be a simple key:value map between settings (eg aquifers_enabled, graphics_pack, embarks) and primitiveish data (bool, string, list[str] respectively).
I don't want to be overly gracious with non-replicable settings, so probably just reporting problems. Will revisit when a prototype exists though.
I anticipate most of the time will go on careful design for compatibility, as this will be most useful if it's backwards and forwards compatible over possible changes. The module to interpret and dispatch / read and dump settings won't be tricky.
[Comment created by Pidgeot: 2016-04-08]
There aren't really a whole lot of non-init settings in PyLNP, and I can't think of anything that would require a lot of new code. Keybinds, color scheme and embark profiles are just copying over another text file; aquifers is just asking core.settings to use a specific value, and graphics packs is calling the right method in core.graphics (same for mods if you want that).
Only real issue might be if a graphics pack (or mod) is missing; if you want to be more gracious when handling that, you'd have to essentially store a complete, pre-merged version.
That leaves the file format for the "extra" file (which I'm guessing will end up being JSON) and UI (which won't necessarily need any changes to the layout; you could reuse the "Select DF" layout for the selection as a modal dialog box, and just provide it with different data).
[Comment created by PeridexisErrant: 2016-04-08]
Having thought some more about the design, I think this is two proposals:
Deprecate LNP/Defaults/ in favor of LNP/Baselines/<df>/data/init/ and remove later. (easy)
New functionality under LNP/Settings/, with installable 'settings packs' in dirs. Each of these would include manifest.json, init.txt, d_init.txt, and hopefully a final file describing some PyLNP settings (eg aquifers, which graphics pack, etc).
Its that last bit that will take longest, I think, but I'll hold off on implementation until I've got an idea of it.
[Comment created by jecowa: 2016-08-28]
Having options for users to switch between "Vanilla default settings" and "LNP recommended settings" is something I'd like to have. I guess users might also be able to save their own custom settings into some kind settings pack, and then the importer tool could transfer their custom settings to the newest version of Dwarf Fortress.
The current handling of "Defaults" (as in, the contents of LNP/Defaults) is a legacy of the original LNP, where there was no known baseline and settings were only changed by overwriting a file.
The popup still notes that the user needs to reinstall graphics packs, a legacy from all-or-nothing file replacement. Why don't we just re-apply the graphics-related settings after applying defaults?
We can also provide genuinely vanilla settings, by using the inits stored in LNP/Baselines. This could remove the need for a defaults dir and special files at all. However, that would remove the capability to use a customised default settings pack.
I propose a solution similar to color schemes or graphics:
LNP/Defaults/MyCustom/init.txtandLNP/Defaults/MyCustom/d_init.txt)LNP/Defaults/*init.txtfor backwards compatibility - and log a deprecation warning.This could start people distributing various settins aggregates; for example defaults for particular mods, new players, hard-mode, FPS limited games, and so on.
[Issue created by PeridexisErrant: 2015-04-26] [Last updated on bitbucket: 2016-08-28]
[Comment created by PeridexisErrant: 2016-04-08] Yep, pretty much what I was thinking. File is something like
settings.json, and it should be a simple key:value map between settings (egaquifers_enabled,graphics_pack,embarks) and primitiveish data (bool, string, list[str] respectively).I don't want to be overly gracious with non-replicable settings, so probably just reporting problems. Will revisit when a prototype exists though.
I anticipate most of the time will go on careful design for compatibility, as this will be most useful if it's backwards and forwards compatible over possible changes. The module to interpret and dispatch / read and dump settings won't be tricky.
[Comment created by Pidgeot: 2016-04-08] There aren't really a whole lot of non-init settings in PyLNP, and I can't think of anything that would require a lot of new code. Keybinds, color scheme and embark profiles are just copying over another text file; aquifers is just asking core.settings to use a specific value, and graphics packs is calling the right method in core.graphics (same for mods if you want that).
Only real issue might be if a graphics pack (or mod) is missing; if you want to be more gracious when handling that, you'd have to essentially store a complete, pre-merged version.
That leaves the file format for the "extra" file (which I'm guessing will end up being JSON) and UI (which won't necessarily need any changes to the layout; you could reuse the "Select DF" layout for the selection as a modal dialog box, and just provide it with different data).
[Comment created by PeridexisErrant: 2016-04-08] Having thought some more about the design, I think this is two proposals:
Deprecate
LNP/Defaults/in favor ofLNP/Baselines/<df>/data/init/and remove later. (easy)New functionality under
LNP/Settings/, with installable 'settings packs' in dirs. Each of these would includemanifest.json,init.txt,d_init.txt, and hopefully a final file describing some PyLNP settings (eg aquifers, which graphics pack, etc).Its that last bit that will take longest, I think, but I'll hold off on implementation until I've got an idea of it.
[Comment created by jecowa: 2016-08-28] Having options for users to switch between "Vanilla default settings" and "LNP recommended settings" is something I'd like to have. I guess users might also be able to save their own custom settings into some kind settings pack, and then the importer tool could transfer their custom settings to the newest version of Dwarf Fortress.