At the current moment, if a mod has a "config" setting, it is stored as LUA within the mod itself (either a standalone config.lua file, or part of control.lua), which users can open and edit themselves. However, if a user does this, their mod file is different to the "normal" file. If another player wants to join their server, they need to have the exact same version of the mod, down to these adjustments, or the Mod will have a different signature to the other version, and be rejected. Or if it isnt rejected, it will cause a desync the first moment the unmodified mod does something different to the modified mod.
I wish to suggest the idea of a unified "Setting" interface be implemented for Mod use. Its use would be storing settings that could be considered "install-wide" as opposed to "map-wide" (though it could be expanded). You could also handily provide users an easier interface for modifying their config without needing to extract the file, edit it, recompress it, and reload the game.
You already have the perfect file and GUI location for all this - the "Mods" button on the main menu, and mod-list.json file already used for mods.
Some things I could see happening with this:
- A mod like Foreman mod could "read" commonly used blueprint strings from a user's install, saving time when starting a new world, and export those same strings on command.
- EvoGUI could have a "default" settings string for their users, so they can pre-configure what is turned on/off when they start a new world
- A tweak mod could do multiple things, and have them all disabled by default, so users opt-in to their tweaks
- a mod could provide multiple interface-only adjustments that don't require the server to know/care (for example the Red Alerts mod)
Details
Imagine if in info.json a mod could define a list of "settings" with a default value. Something like this
Code: Select all
{
"name": "crazylagmaker",
"version": "0.1.0",
"title": "Crazy Lagmaker",
"author": "DaCyclops",
"homepage": "",
"contact": "dacyclops@dacyclops.com",
"description": "Adds something that polls to much, and causes lag...",
"dependencies": ["base >= 0.12.11"],
"settings": [{"poll_rate": 180, "poll_rate_2": 60 }]
}Code: Select all
{
"mods": [
{
"name": "base",
"enabled": "true"
},
{
"name": "crazylagmaker",
"enabled": "true"
"settings": [
{
"poll_rate": "180",
"poll_rate_2": "60"
}
]
}
]
}
(No example Pic, dont have time to Photoshop an example)
These settings, defined in mod-list.json, would be retained install-wide, and then could be "called" as part of the initialization of the mod's control.lua - Mods usually can only call their own "settings". And there could be a function for writing as well (useful in the EvoGUI and Foreman examples above). This would only be doable in the code that is called when the map itself is loaded (control.lua, not data.lua and its cousins, and the prototypes and such.)
For example, in its control.lua on_init section a mod could call something like
Code: Select all
PollRate = data.mod_config.readConfig("poll_rate")
Poll_Rate2 = data.mod_config.readConfig("poll_rate_2")If the implementation was like this, users could have a single downloaded version of "crazylagmaker", but each have their own settings for how often it makes its lag. If they wanted more lag, they just goto the main menu, click on Mods, choose "crazylagmaker" and change the "PollRate" to 120. And features like Automatic Updating of mods would be possible, as the settings are not stored in the mod file itself. And servers would not need to distribute their own copy of the mod if they want "crazylagmaker" to make crazy lag less often..
The bonus to an implementation like this, is the potential to pass a pre-defined list of "settings" from a server when connected. since these settings would potentially only effect connections to that exact server. And again, all the server would need would to stream its own mod-list.json and let the local user read the required files. Then when connecting to the server, instead of reading its local "settings" it reads the server's "Settings" and init's the control.lua the way the server would expect. I am aware that some of this could be replicated by clever use of Globals inside the control.LUA, but that wouldnt help with ease-of-modifying. It also requires the Mod to implement the clever use, not the Engine.
Of course there is plenty missing from my examples, especially as my knowledge of LUA/JSON is very... limited. But I think an interface as such might make the process of going forward much more straightforward for modders and users alike.
