-
Notifications
You must be signed in to change notification settings - Fork 13
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
Config menu for OWML #147
Config menu for OWML #147
Conversation
* removed mod data from config menus * introduced default config for owml
@@ -17,15 +15,5 @@ public ModData(IModManifest manifest, IModConfig config, IModConfig defaultConfi | |||
DefaultConfig = defaultConfig; | |||
} | |||
|
|||
public void ResetConfig() |
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.
Removing this is a breaking change but I think no mods used it. Did any of you?
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.
I actually don't have to remove this any more, after introducing the base class... kinda wanna do it still 🤷
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.
I suppose resetting to defaults is handled by ModConfig
now?
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.
Yeah, which do you think should do it - ModData or ModConfigMenu?
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.
I think it depends whether or not you want to implement "Reset all mods to defaults" feature
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.
If you think there's value in keeping the reset method in mod data, I'll revert it. I don't have a strong opinion on this. Give the word :)
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.
Only value I can see is making implementing "Reset All to Defaults" easier. And only reason I can see why user might want to reset all is if there are problems with outdated config and there is either multiple of them or user can't find which one is misbehaving
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.
BTW, I suggest you to think about picking up type changes from default config (i.e. number to slider or to enum)
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.
And warning on (seemingly) incompatible types
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.
That sounds hard. Personally I don't think it would be worth it. But either way I'd argue it's outside the scope of this PR :)
#153 first |
* menu title constants
Other than what I mentioned things look ok to me |
@@ -7,6 +7,7 @@ copy "OWML.Patcher\bin\Debug\OWML.Patcher.dll" "Release\OWML.Patcher.dll" | |||
copy "OWML.ModLoader\bin\Debug\OWML.ModLoader.dll" "Release\OWML.ModLoader.dll" | |||
copy "OWML.Launcher\bin\Debug\OWML.Launcher.exe" "Release\OWML.Launcher.exe" | |||
copy "OWML.Launcher\bin\Debug\OWML.Config.json" "Release\OWML.Config.json" | |||
copy "OWML.Launcher\bin\Debug\OWML.DefaultConfig.json" "Release\OWML.DefaultConfig.json" |
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.
Now that we have a default OWML config, we shouldn't include OWML.Config.json in the releases, right? One of the main advantages of having a separate default config file is that new releases don't replace configs of previous releases (which can be very annoying if you need a custom game path). OMLW.Config.json should only be generated from the default, after OWML starts. So only OWML.DefaultConfig.json should be here.
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.
Yeah, totally 👍
If we do this: before starting OWML the first time, how will you show/edit the config in MM?
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.
Same as for mods. If mod manager sees only default, copy default to user config. Otherwise edit user config.
Need to make sure we copy each property and not only the whole file (in case we add new properties to config). Don't remember if mods already do this.
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.
@Raicuparta removed config file, and creating it from default if it's missing.
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.
Just copying the file, as there's no (reason to have a) list of generic settings.
@@ -13,32 +13,44 @@ public class Program | |||
{ | |||
static void Main(string[] args) | |||
{ | |||
var owmlConfig = GetOwmlConfig(); | |||
var owmlConfig = GetOwmlConfig() ?? CreateOwmlConfig(); |
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.
Won't this cause problems if you add new entries to the config? As in, if a user has a OWML.Config.json file, and then in a new update OWML adds a new configurable setting. The config exists, but is missing a property, so you're not getting that property from the default config.
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.
I tried deleting a line from the config, to simulate your situation. It worked fine :-)
The config defaulted to the default of the data type (false for bool in this case) - it showed fine in the menu and saved properly after changing it.
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.
Hm but what if default was supposed to be true? 😅
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.
Hmmm... 🤔
I don't know how to code what you're suggesting without making a manually maintained mess. Any ideas?
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.
I guess iterating over properties using reflection. Sounds hard :P
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.
I guess too many things would have to change. What makes most sense for me is not to copy properties selectively, but to do in the moment of getting the property. So when you're trying to get OwmlConfig.GamePath, the getter checks if the property exists in OWML.Config.json, and if not, gets it from OWML.DefaultConfig.json.
Ideally, you wouldn't even need to create the OWML.Config.json file until the user changes a setting. And when they do, the user config would only needs to include the settings that differ from the default.
But I understand that this can be to big of a change, and might not be easy to do with the way the JSON serialization is done (I think it always writes the whole file from the properties).
In any case, it's at the very least something to keep in mind if we add new settings ;)
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.
eh
No description provided.