Store certain local variables in a dictionary (detailed notes)

[ithinkandicode]

PR #145 puts various settings into ModLoader.ml_options. I've put a bit more thought into that than what I've covered in the PR, so I'll cover it here.

TL;DR: Dictionary = JSON, user configs, standardised code 🤗

Dictionary

We can use the dictionary to keep track of data that's currently loose variables. This would help differentiate data that can be user-controlled vs. internal data that's only changed programmatically. Eg:

• os_mods_path_override      -> ml_options.path_to_mods
• os_configs_path_override -> ml_options.path_to_configs

JSON

Doing this also lets us work towards letting these settings be overridden via JSON too. And having settings that can be controlled via JSON would allow a game or mod to provide a GUI to do that (though ofc only a couple of settings would benefit from being exposed like this, namely log_level and enable_mods).

This can also be related to #109, as we can store all the user options (including the active mods from #109) in a single JSON file, eg called mods-options.json, as keeping all the settings in one single file would reduce the number of file IO operations.

ML Options

And taking #109 further, we could also add support to disable certain mods during mod development via ML Options, by building off of #145 (though I haven't mentally planned out the implementation of this yet).

CLI Args

We may also want to revisit the CLI args we currently have. If our CLI args affect the options dictionary, we could standardise them to follow a certain format, like --setcustom-*. For example, using the variables defined in the ML Options PR (#145), the refactored CLI args might be:

• --setcustom-path_to_mods = --mods-path
• --setcustom-path_to_configs = --configs-path
• --setcustom-enable_mods = --enable-mods
• --setcustom-log_level=1 = --v
• --setcustom-log_level=2 = --vv
• --setcustom-log_level=3 = --vvv

Related

• Add option to disable certain mods via JSON #109
• feat: ✨ ML Options: Add the groundwork for loading custom options #145

[Qubus0]

Copy from the options pr #145
Neat and definitely more user friendly than all the flags. We might want to integrate the flags with the options system though - parse them in the ModLoader _init and only use them later. Flags should override the options though.

I don't think we need all of those examples, the options are pretty self-explanatory, especially if we use export hints like this for dictionaries export(String, DIR) var path_to_mods (see: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_exports.html)

[ithinkandicode]

• Closed by feat: ✨ ModLoaderStore: New singleton to store data #172