Difference between revisions of "New setting structure"
(→Goals: + anticheat) |
(→General concept overview: wrote down some little bits) |
||
Line 11: | Line 11: | ||
==General concept overview== | ==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>. |
Revision as of 08:07, 23 September 2008
Currently, settings are put together in a "flat" manner, 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>.