New setting structure - Revision history

Cadillac at 21:38, 23 August 2021

2021-08-23T21:38:04Z

← Older revision		Revision as of 17:38, 23 August 2021
Line 60:		Line 60:
	====Backwards compatibility====		====Backwards compatibility====
	===Settings that trigger an action===		===Settings that trigger an action===

			[[Category:Development]]

Epsy: /* Detailled Concept */ Made the title structures

2008-09-27T21:12:25Z

Detailled Concept: Made the title structures

← Older revision		Revision as of 17:12, 27 September 2008
Line 47:		Line 47:
	====Why using <code>render.enabled</code> and not <code>render</code> then?====		====Why using <code>render.enabled</code> and not <code>render</code> then?====
	Because first part can only be a group name, for keeping the main groups clear.		Because first part can only be a group name, for keeping the main groups clear.

			===Accessing a setting===
			====Ghost settings====
			===Setting the value of a setting===
			===Resetting a setting===
			===Special setting structures===
			====Lists====
			====A set of pairs====
			====Setting groups====
			===Saving settings===
			===Transmitting settings to the client===
			====Backwards compatibility====
			===Settings that trigger an action===

Epsy: /* Goals */ + Setting groups

2008-09-26T17:20:55Z

Goals: + Setting groups

← Older revision		Revision as of 13:20, 26 September 2008
Line 9:		Line 9:
	* nSettingItem backward compatibility		* nSettingItem backward compatibility
	* Attempt making cheating harder (but break compatibility :<)		* Attempt making cheating harder (but break compatibility :<)
			* Setting groups (think about the LADDERLOG_WRITE_ ones)

	==General concept overview==		==General concept overview==

Epsy: /* User stats */ forgot to put that link

2008-09-26T17:18:02Z

User stats: forgot to put that link

← Older revision		Revision as of 13:18, 26 September 2008
Line 21:		Line 21:
	====What are these, then?====		====What are these, then?====
	=====User stats=====		=====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.		There is already something for this, it was referred to as [[Statistical Collections Database]] "stat files" on the rest of the wiki, but doesn't seem to have a wiki article.

	=====Stuff that depends on a specific player=====		=====Stuff that depends on a specific player=====
	There is indeed nothing for this, but it's coming, I promise! :)		There is indeed nothing for this, but it's coming, I promise! :)

Epsy: /* Detailed Concept */ Give it a start!

2008-09-26T17:11:34Z

Detailed Concept: Give it a start!

@@ Line 1: / Line 1: @@
 {{Blueprint|settings}}
-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.
+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==
@@ Line 14: / Line 14: @@
 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>.

Epsy: /* General concept overview */ wrote down some little bits

2008-09-23T12:07:06Z

General concept overview: wrote down some little bits

← Older revision		Revision as of 08:07, 23 September 2008
Line 11:		Line 11:

	==General concept overview==		==General concept overview==
	~~TODO~~		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>.

Epsy: /* Goals */ + anticheat

2008-09-23T12:02:10Z

Goals: + anticheat

← Older revision		Revision as of 08:02, 23 September 2008
Line 8:		Line 8:
	* Ghost settings (allowing a setting to be set BEFORE it gets declared)		* Ghost settings (allowing a setting to be set BEFORE it gets declared)
	* nSettingItem backward compatibility		* nSettingItem backward compatibility
			* Attempt making cheating harder (but break compatibility :<)

	==General concept overview==		==General concept overview==
	TODO		TODO

Epsy: add blueprint link

2008-09-21T19:08:44Z

add blueprint link

← Older revision		Revision as of 15:08, 21 September 2008
Line 1:		Line 1:
			{{Blueprint\|settings}}

	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.		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.

Epsy: Got to make a stub about this, but at least i finally started

2008-09-18T11:43:31Z

Got to make a stub about this, but at least i finally started

New page

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

==General concept overview==
TODO