settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Topic: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl (Read 6826 times) previous topic - next topic

settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

July 06, 2009, 04:39:38 pm

This topic is all about to improve the configuration mechanisms in simutrans

My problems with it:
* its very unclear for new developers what is where
* settings.xml is just a mess (its a really big [don't evade curse filter] you to XML)
* Some non-gamplay settings are in simuconf.tab

As I can see their are 3 types of configuration:

1 Non-gameplay settings => day/night settings, visibility of trees etc, window size, ...
2 Gameplay settings that should be saved in the game once started, but don't have a GUI at startup
3 Gameplay settings that should be saved in the game, but /have/ a GUI at startup (timeline, start year, starting money....)

1 is now partly in settings.xml but this format is really bad, another part is still in simuconf.tab
2 is now (partly?) in settings.xml in another tag
3 Is in simuconf.tab

(Please correct me if I'm wrong in one of the above ****umptions)

For configurations of type 1 an XML format is good, but it should be human readable (and the order of tags shouldn't matter neiter the absence of some tags)
it could look something like this

Code: [Select]

<configuration>
<window-width>800</window-width>
<window-height>600</window-height>
<language>en</language>
...etc...
</configuration>

Configurations of type 2 could stay in simuconf.tab, the one of type 3 could be also in simuconf.tab (in the users home directory) but I don't know if this format has a write option in simutrans, so maybe we could use XML here too...
1 should be in a different file than 3, 2 and 3 could maybe be in the same file

disadvantage of really using XML (instead of what we have now: NXUL => Non Extendible Unordered Language) is that we can't use our current XML p****r, and we have to use an external dependency, but this shouldn't really be a problem

Codewise things could look like this:
* A static configuration cl**** (currently umbegung_t) for type 1
* An abstract cl**** (that works with keys instead of a function for each variable) for 2 and 3 which is used in welt (reading/saving from/to savegame) and before startup (reading/saving from/to simuconf.tab and/or xml file)

Any comments on this plan?

[red]Mod note: Don't evade curse filter.
~Igor.[/red]

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Reply #1 – July 06, 2009, 06:12:34 pm

There is also a cl**** einstellungen_t, which is saved in the save game, and realizes some of your points (2,3) above.

The point with using simuconf.tab is, that is allowes different thing configured by the pak-set, by simutrans, and by the user.

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Reply #2 – July 06, 2009, 06:26:00 pm

I know what the point of simuconf.tab is, but still the current source code is not consistent + the xml is flawed

My point is to keep simuconf.tab almost completely (also the split up in 3 parts, user, simutrans, pak), but remove the keys that should be in setttings.xml + design a better way to achieve things (so its clear for new devs what to use)

einstellungen is btw a confusing name => it translates (as far as i know) as configuration but this seems wrong (environment seems a better name - the environment where the current game is living in, but umgebung_t seems to translate to environment, so these names should be better chosen)

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Reply #3 – July 06, 2009, 07:05:36 pm

"einstellungen" translates to "settings" ...

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Reply #4 – July 06, 2009, 08:55:18 pm

These name are historic, first was einstellungen and umgebung came later. Alle settings of einstellungen and umgebung are actually saved in settings.xml (Before it was just settings.sve, but the same content).

And why do you complain about XML syntax: XML is made for computers, not human. Humans should not touch settings XML, as everything confugurable is in simuconf.tab or is considered non configurable and is in the savegames (which can be set to the same XML but then get just extremly bloated). Also is <blabla>7</blabla> not really XML as it is in real life. Last time I remembered the syntax was <H1>text</H1> and not <ImportantHeadline>Text</ImportantHeadline>. Settings.xml is not to by touched by the user. (But saving to registry is not cross plattform compatible.)

Not so long ago I seperated the settings which does not affect game logics (i.e. network safe) to umgebung_t and the rest (that needs to overide the defualt for network games) to einstellungen_t, since only the latter is included with savegames. This is exactly what you describe imho.

However a cl**** with virtual functions (or what do you mean by abstract, maybe our definitions do not match) is a bad idea performancewise for freuqntly accessed stuff. And what do you mean by keys? Why opposing access functions (since the will not generate any extra code but provide extra flexibility, if something really need to be changed)?

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Reply #5 – July 06, 2009, 09:17:09 pm

Quote from: prissi – on July 06, 2009, 08:55:18 pm

These name are historic, first was einstellungen and umgebung came later.(...)

Most of the time users shouldn't modify configuration files, but still the settings.xml is huge abuse of xml... Say their are some hidden options (like window size) that the user can not modify directly in the UI, or settings that are not wiedly used so that are not in the settings dialiog in-game to not clutter it up => users should still be able to open the settings.xml, find the right setting and edit it.
By the way, I don't understand your thing about ImportantHeadline: h1 is clear if you know what it means => header1 so an header of the first level....
Btw I don't see why <i8> and <bool> and so on are used as tag names, it just could be all <a> (or <b > or <whatthehellisthis>) for all types
or better, just don't call it XML and have a file
"value1
value2
value3
..."
(which would be better than the current XML file => it still can't be read by users, but still by computers and it saves bytes...., and is probably a lot easier to p****... (so it would save us LOC))

Most of the system (in my idea) will stay intact but I want to add some imrpovements
Now their is some compat code that loads some settings from simuconf.tab and puts them in umgebung, I want to get rid of this (just load the old settings from simuconf.tab once, saves them in the new xml, and then removes them from the tab file)

My idea of virtual functions will not impact performance:
only the save/load will be virtual all the rest can stay in the base cl****

The idea of keys (so for clarity: settings->get_bool_value("timeline-enabled") instead of settings->get_timeline()) wsa only an idea, its right that one is not more flexible than the other, so we kan indeed keep the current system

mod note: fixed the spilling bold for you :-) ~VS

mod note 2: and you don't need to quote an long post that is right above yours :-D ~Igor

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Reply #6 – July 06, 2009, 09:25:06 pm

Quote from: Nathan Samson – on July 06, 2009, 04:39:38 pm

disadvantage of really using XML (instead of what we have now: NXUL => Non Extendible Unordered Language)...

:-D

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Reply #7 – July 06, 2009, 09:34:43 pm

i8 stands for int8, i16 for int16 and so on, since the XML routines are also used to save the entire game as XML (if activated). However, with these short tags size increases from 4MB to 288MB for savegames, and even zipped it doubles. Longer tags will bloat it even more. Actual using <value1>1</value1> and <value2>2</value2> is not more valid XML syntax than <i8> and also gives no more information.

Furthermore no more information is available during saving of savegames without putting a very big effort in all saving tags and bloating the program quite a lot. If it annoys you, I can revert to SVE-format, and you informations are then save before the user. Editing settings.xml is not wished, since the values there could lead to simutrans crashing upon loading and never be able to start again without deleting it.

"Normal" programs would put this in the registry or in hidden files, which clearly indicates that this is not user editable. Calling this file sve will aslo prevent opening by a normal user. Would this make the intention of "do not meddle with this" more clear?

And why do you want to edit settings.xml? Everything there could achieved by simuconf.tab or even the command line. Simuconf.tab is much better documented too.

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Reply #8 – July 06, 2009, 09:56:52 pm

Quote

Editing settings.xml is not wished, since the values there could lead to simutrans crashing upon loading and never be able to start again without deleting it.

Thats one of my problems => a good xml file should not crash when tags are missing/not the expected type, so if the file format is something like <aconfigsetting> and that tag is missing from the file the file just should load perfectly and the setting for "aconfigsetting" should be the default.

<value2> is not the perfect example (did I use that?) I mean <thenameoftheconfigsetting> like <window-width> or <use-timeline> or ...

Quote

However, with these short tags size increases from 4MB to 288MB for savegames,

I never said (human-readable) XML should be used for savegames only for the configuration settings...

Quote

And why do you want to edit settings.xml? Everything there could achieved by simuconf.tab or even the command line. Simuconf.tab is much better documented too.

I came across this "mess" (I still call it a mess, it is not meant offensive) when trying to add a configuration option (for the ltr-graphs I made)

Mod note: I fixed broken quote marquee
~Igor.

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Reply #9 – July 07, 2009, 06:37:58 am

I think settings.xml should be used only for temporary value such as button state which will be changed in the game.
Other values which are duplicated both in settings.xml and simuconf.tab, and which won't be changed in the game are not need to be stored in settings.xml.
Because we can modify simuconf.tab.

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect ga

Reply #10 – July 07, 2009, 02:21:25 pm

Settings has duplicate values only because it is written by the same routine than the one producing the savegames. THis is called reusing of code to reduce the number of bug.

simuconf.tab will overwrite values in settings.xml, and this is the desired option. But it takes ten letters to change the format of settings.xml to a binary uneditable format that makes it clear "Do not edit", if this is wanted.

And for network games, the full set of settings will be taken from the server, overriding even the settings of simuconf.tab; thus saving of the full set is needed.

Re: settings.xml is very unclear, simuconf.tab has settings that don't affect gamepl

Reply #11 – July 07, 2009, 07:27:28 pm

Maybe you could just change the file extension to "NXUL"? ;-)