-
Notifications
You must be signed in to change notification settings - Fork 44
feat: ✨ ModLoaderStore: New singleton to store data #172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Qubus0
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice work
KANAjetzt
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor stuff, but if everything is setup correctly it works flawless 👍
Thanks Darkly great work 🥇
Qubus0
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the one
KANAjetzt
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work - tested and approved 👍
The ModLoader self setup script uses util function from ModLoaderUtils in GodotModding#172 ModLoaderStore was introduced into utility functions that where used by the self setup. Because the setup is run before the ModLoaderStore is initialized the setup was stuck in an infinite loop. To fix that `get_modloader_store()` was added and is now used in `_get_verbosity()`, `get_path_to_mods()` and `get_path_to_configs()`. Also updated the the autoload index check in the `_init()` of *mod_loader_setup.gd*. closes GodotModding#200
The ModLoader self setup script uses util function from ModLoaderUtils in #172 ModLoaderStore was introduced into utility functions that where used by the self setup. Because the setup is run before the ModLoaderStore is initialized the setup was stuck in an infinite loop. To fix that `get_modloader_store()` was added and is now used in `_get_verbosity()`, `get_path_to_mods()` and `get_path_to_configs()`. Also updated the the autoload index check in the `_init()` of *mod_loader_setup.gd*. closes #200
Adds a new singleton called
ModLoaderStore, which comes beforeModLoaderin the autoload order. This new singleton is a data store, and lets us reference data that was previously held as local vars in ModLoader, and which therefore may not have been accessible to all methods due to ModLoader not being initialised during its_init()phase.I have implemented the following:
ModLoadertoModLoaderStore(closes #161).ModLoaderUtils.get_path_to_modsModLoaderUtils.get_path_to_configsModLoaderSteam.get_path_to_workshop(renamed fromget_steam_workshop_dirto match this new convention)override_path_to_*for consistencyModLoaderStorecheck_autoload_positionto a new class calledModLoaderGodotNotes:
ModLoaderstill has lots of other local vars that we may want to move toModLoaderStore. We may also want to provide utility funcs to retrieve this data, eg.is_mod_active(mod_id: String), but all this can be handled in subsequent PRs.Closes:
Works towards:
only_once#141Finishes:
Subsequent Work
As raised in the review comments, there are a few things that we can do following this PR:
REQUIRE_CMD_LINE- This could be a configurable option (via)