Add config system and the ability to disable mods #3
Conversation
There was a problem hiding this comment.
How are you planning to add additional mod data? More importantly, how would it be accessed from the mods themselves? This would require some sort of API exposed by the HAT itself, which requires some small planning and refactor to prevent unwanted access to structures we don't want mods to see.
| private void DisableMods() | ||
| { | ||
| foreach (Mod mod in Mods) | ||
| { | ||
| ModConfig config = ConfigHelper.GetModConfig(mod.Info.Name, mod.Info.Version); | ||
| if (config.Disabled.HasValue && config.Disabled.Value == true) | ||
| mod.IsEnabled = false; | ||
| } | ||
| } |
There was a problem hiding this comment.
Not only the name of the method is not clear to what function it has, but I think this behaviour (handling configuration) should be done by the Mod class.
There was a problem hiding this comment.
Sure, sounds reasonable to me. I wasn't quite sure the best place to put this
| } | ||
| } | ||
|
|
||
| private void DisableDuplicates() |
There was a problem hiding this comment.
We have to consider how having multiple versions of the same mod in the game's directory will affect the mod loader, and how it should be communicated properly to the end user. Something like a slide field for version for mods with multiple versions might be appreciated. It could still use the "enabled/disabled" system but it's best not to clutter the mod menu.
There was a problem hiding this comment.
I thought about having the version act as a slider as well, and you can choose which version of the mod is active (or choose none of them, disabling the mod). This solution seemed easier to implement which is why I did it this way for now
There was a problem hiding this comment.
Sure thing. Also, I revert my previous statement and I think that actually having something like SelectedVersion as an optional parameter would be a nice alternative to storing a separate record for each installed version of the mod - this way it can default to the newest one when the option is not present or it points to non-existing version of the mod.
|
Indeed I want there to be some sort of minimal API exposed by HAT which mods can make use of. Since mods aren't currently aware of HAT, there wouldn't be an easy way to add things to a global config or create easy in-game menus. Something like the hollow knight modding api would be ideal but I don't think we need to make it as complex as that for an MVP. I think exposing a config and easy menu system would be a good starting point. I don't know much about how the HK api (or any other modding api) works, and it raises some questions for me about versioning: I'm happy to take a stab at working on this but I'm realizing that if I try and make it by myself it will probably suck cuz I don't know what I'm doing LUL, my way usually involves writing prototypes and throwing code at the project and seeing what sticks but I'm happy to take a step back and trying to plan things out more thoroughly |
|
HAT already supports minimum version requirement for a mod loader through dependency metadata. We'll probably have to ensure API is backwards-compatible, so it's best to get it mostly right from the very beginning to minimize the amount of needed changes without dropping the compatibility. In terms of configs, there's a suggestion: I think it would be nice to have a "global" HAT config, which contains basic information, like the list of disabled mods, list of prioritized mods etc, and everything mod-specific should be contained within isolated directory ( |
This adds the ability to enable/disable mods through the Mods menu, as well as a basic xml-based configuration system for HAT. I plan on expanding this to add the ability for mods to create custom config menus and/or store configuration data inside the HatConfig file (potentially removing the need for files like
FezugBinds).Feel free to pick apart and destroy my code here lmao, I'm not confident about some things and definitely felt like some stuff I did were hacks