-
Notifications
You must be signed in to change notification settings - Fork 37
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
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
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 🥇
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
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 beforeModLoader
in 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:
ModLoader
toModLoaderStore
(closes #161).ModLoaderUtils.get_path_to_mods
ModLoaderUtils.get_path_to_configs
ModLoaderSteam.get_path_to_workshop
(renamed fromget_steam_workshop_dir
to match this new convention)override_path_to_*
for consistencyModLoaderStore
check_autoload_position
to a new class calledModLoaderGodot
Notes:
ModLoader
still 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)