user data (settings) should be outside of mod.json

[CptMoore]

Since the mod.json is managed by the mod author, if a new mod version comes out, one has to overwrite the mod.json with what the mod author provided in the update.

That leads to either losing the settings or painfully having to copy-paste settings around.

By having the settings outside the mod.json, one can avoid this issue altogether, so one can just copy paste updates in the mod folder and be done with it.

[mpstark]

I agree that this is a problem. I'm unsure how to handle it, however. Perhaps a configuration.json or settings.json or something could be generated by ModTek on load with the defaults pulled from the mod.json?

[CptMoore]

Further issues:

Before upgrading, the existing mod dir should be removed to avoid old full or partial jsons sticking around. -> settings should not be in same directory as the mod.

If we want mod authors to change defaults and allow those updated defaults to be used, settings should only contain settings overridden by the user. Like a partial json to the mods default one. -> settings should not contain default values if autogenerated Dont like it that much, as i like the settings overview, but dont know of another way of distinguishing what the user has overridden and what came in as default. (Otherwise theoretically a mod author would need to create a v2 or v3 of a settings field whose default was changed by the mod, and ignore v1, but thats still ugly)

There is a special user setting, called "Enabled", that should be placed outside modjson too. -> i would move this to the settings This would be the only candidate right now for being in a user autogenerated settings.

TLDR so far

• Settings outside of mod.json and mod dir altogether
• Settings file generated without defaults but not empty

Further ideas: An alternative would be to have 2 settings files, one always autogenerated and always filled with all defaults and never read! And another with only enabled inside that the user can expand. At least a user could quickly copy paste stuff.

So final proposal: Autogenerate $ModnameSettings.json in Mods or Mods\Settings and only put Enabled inside. Autogenerate $ModnameDefaults.json alongside with all settings the mods provide.

[janxious]

I feel like any system that doesn't include a way for "nice" mod authors to do in-place upgrades of settings by version is probably going to have the same problems as the current system, except in more places. If an author decides the names of all their settings were wrong in the past, these things don't seem to me to solve the re-configured configuration/update, though I think the auto-generated defaults + secondary user settings thing would be a great step toward that.

Another thing to consider is having a named file control mod enabled-ness. Just a file named disable/disable.txt/disable.json/etc. seems like it would be easier to deal with than popping open a mod.json file and hoping smart quotes don't ruin your day.

[CptMoore]

Factorio has a good model, there settings are displayed ingame and separate of the mods dir. So the gui is the default listing while the user specified stuff then is saved in that extra settings file outside the mod dir. Factorio also bundles mods not in dirs but in zips.

[janxious]

Yup, factorio has a really nice setup.

[gponick]

Associated Example PR: https://github.com/Mpstark/ModTek/pull/69

What made you do this?

I bumped against this when I was looking at how to preserve user's mod settings after an update of a mod from source. I took a stab at a proof of concept here for solving this issue, based on the feedback above and my brain.

Why are you doing it?

1. Move user settings outside the mod directory (allow for updates to replace all files in mod directory)
2. Separate mod info (mod.json) from mod settings (settings.json)
3. Enable a standard "mod info", "mod settings", "user overrides" structure to make updates/etc using BMI (http://github.com/gponick/bmi) tool easier.

How are you doing it?

1. Add a new file, modtek.overrides.json in \Mods\ that contains settings that override anything found in \<ModName>\
2. Add a new file, \<ModName>\settings.json, which overrides any settings found in \<ModName>\mod.json (to maintain backwards compatibility)

What else did you consider?

1. A <modname>.overrides.json in \Mods (one override file per mod) instead of one override file total (I find this less clean)
2. Upon installing a mod, create an entry in the master overrides file (I think this is a job for a tool outside Modtek, tbh)

Besides the obvious, what else do we get?

1. A single-point-of-entry for a Mod Launcher / Settings Editor
2. A finalized, "merged" settings dictionary can be output in the .modtek directory which we can use for debugging
3. Not sure if it's doable without, but with this setup - a ModTek "mod" that allows json settings to be reloaded on command would be much more easily created (as ModTek can just have an interface you implement that has the associated command - since the mod settings are now formalized and live in specific places) and have the settings reflected in live (for .dll mods, obviously, with their own settings, not JSON mods).

Ultimately, my plans for BMI include a "bmi troubleshoot" which will grab all mod versions, ModTek Version, BTML version, BT version, and associated log files, and make a zip for the user to upload to us. I also plan on having BMI not just have a CLI but a frontend (think CKAN) and integrating (if possible) with Nexus Mod Manager and Nexus Mods.

NOTE: This is a proof of concept, if we throw any of the work away :shrug: it was easier to understand/explain what I wanted to say by doing, rather than barfing paragraphs at people.

[Sheep-y]

I am wondering about this too recently. Separating mod info from mod setting is a much needed first step. Maybe we don't need ModTek support to implemnet that in our mods, but having a standard way to do it will be very welcomed.

[IceRaptor]

FWIW I do this with several of my mods. I manually store settings I want to persist across Mod versions in BattleTech/ModSaves//. Data can be stored associated with the current active simGame (via saveId).

You can see examples in https://github.com/BattletechModders/LowVisibility/blob/master/LowVisibility/LowVisibility/Patch/SerializationPatches.cs and https://github.com/BattletechModders/LowVisibility/blob/master/LowVisibility/LowVisibility/Utils/State.cs

Similar functionality exposed through a common API would be extremely useful!

[CptMoore]

MechEngineer successfully uses two extra settings files, one containing the default settings that is always regenerated after starting the game, and another one where only the changes the user wants are put.

I'd prefer to have somewhere under the Mods directly.. so I can have an RTMods or MyMods directory which contains the actual mods and the settings (and the saves when using the save game features from MechEngineer). That way I can switch between mods just by renaming the whole folder and always have all stats together.

Of course making the default save path for settings configurable would allow for flexibility here.

[CptMoore]

Many mods already use their own settings folder/files. So we need a new standard. But we also have different logging per mod and different ways of even patching battletech. So not sure if ModTek can fix that this late into the game.