For example, let's say you are running a mod called MyCoolModv1, and you want to upgrade to MyCoolModv2.
Before the upgrade, your .ini files might look like this:
• Server-side settings: stored on servers as MyCoolMod_ServerSide.ini under a section called [MyCoolModv1.CoolStuff].
• Client-side settings: stored on clients as MyCoolMod_ClientSide.ini under a section called [MyCoolModv1.CoolStuff].
After you upgrade, however, the mod now looks for settings in the .inis, but under [MyCoolModv2.CoolStuff]. Since those settings don't exist, it uses the default values. Server-side, this isn't a problem because the admin can just copy/paste the settings under the new heading. But clients don't have the knowledge to do this.
I'm aware of one potential solution where you can use a second separate mod just for storing settings, whose name should not change when you update the main mod. For example, the mod "BTPlusPlusv009" uses a separate package called "BTPPUser" to store settings under "[BTPPUser.ClientData]" -- and this works, up until you want to extend the number of settings available in the mod, or change the names of some of those settings, in which case you find yourself needing to update (and therefore rename) BTPPUser to BTPPUser_v2 and face the same problem all over again.
So how have others solved this problem?
Is there a design pattern or a method where you can actually specify arbitrary .ini, package and class names to store and retrieve settings data?
I'm imagining some code like
Code: Select all
MaxPlayers = SettingsManager.GetSetting("MyCoolMod.ini", "MyCoolMod.CoolStuff", "MaxPlayers");