New setting structure
Currently, settings are put together in a "flat" manner(they are referred to as "Console Commands"), ie. related settings are sometimes not grouped together, which causes confusion and eats children. If that was not enough, admin commands are mixed in, too, and it's soon going to be a real mess when scripting/modules/other becomes usable. This is why I think commands should be put away from settings (and that's why I wont be talking about admin commands here) and that settings should be organized in a better way.
Goals
- Structured settings tree (Give the rim(flat!) a break! Hug a tree instead!)
- Put a line between admin command and setting
- Ghost settings (allowing a setting to be set BEFORE it gets declared)
- nSettingItem backward compatibility
- Attempt making cheating harder (but break compatibility :<)
General concept overview
Imagine a big tree. That's the settings tree. You have leafs, containing data, and also, and that's where my metaphor breaks, you have leafs hanging on other leafs(in a directory structure, it would be that folders could be a file AND a folder).
That gets you the idea of it. You can have a setting be a number, a string, <anything you like here>, or a list of <anything you like here>.
Detailled Concept
What is a setting and what is not a setting?
A setting stores a value for further use, and should be something that can be simply stored at shutdown and used as-in on next start, server or client, and it has to have effect on the long-term. For example, don't store something that depends on a specific player connected to the server or user stats, while user access level would fine as settings.
What are these, then?
User stats
There is already something for this, it was referred to as stat files on the rest of the wiki, but doesn't seem to have a wiki article.
Stuff that depends on a specific player
There is indeed nothing for this, but it's coming, I promise! :)
/admin KICK was a console command before, wasn't it? What is it now?
It's an admin command!
Name of a setting
A setting name consists of:
- A main group name: render, game, policy, network, or resource, followed by a dot « . ».
- Sub-groups, each separated by a dot, then a last dot and the setting's name.
Names can be [a-zA-Z], but are case insensitive. Some examples:
render.enabled render.window.width resource.repositories policy.spamProtection policy.spamProtection.repeatTime game.rubber game.rubber.pingRubber network.compatibility.customMax
From user/admin UI, you can shorten each of these main groups to their first letter, except resource for which we'll use res
Huh? how can policy.spamProtection and policy.spamProtection.repeatTime both be settings?
That was explained earlier: A setting can also be parent of other settings. The parent setting should normally toggle enabled state(or set a factor, in this case) of the feature.
Why using render.enabled and not render then?
Because first part can only be a group name, for keeping the main groups clear.
