configHandler, r7047

[Tobi]

Replying to commit ML here cause the other ML is down.

* fix unitsync not to crash with new configHandler (the old one was better)

Why?

IMO the new one is better because:

• The old one caused hard to diagnose crashes when used before main was entered (as it was in GML) because it used non-POD objects as global variables (e.g. std::string),
• The old one was weird mix of singleton and monostate pattern with the effect that:
• From the outside, config source appeared to be settable after GetInstance was used but GetInstance had as side effect that SetConfigSource didn't work anymore (for example, when GetInstance() would be used accidentally before commandline arguments were parsed the commandline argument for config source would be silently ignored, as was the case in GML builds. There was no code in place at all to prevent such easy to make bugs. In the new one a segfault occurs immediately if you misuse configHandler in such a way, which makes it much safer to use )

Excuse me for not modifying unitsync tho to use the new one correctly

[Auswaschbar]

* fix unitsync not to crash with new configHandler (the old one was better)

Why?

IMO the new one is better because:

• The old one caused hard to diagnose crashes when used before main was entered (as it was in GML) because it used non-POD objects as global variables (e.g. std::string),

That is wrong because ...?

I liked it better because it didn't crash . And I have a personal dislike against too much global variables.
PS.: you forgot

* fix crash in dedicated server and new ConfigHandler

While speaking about configHandler, I was planning to port the linux configfile-handler to windows. Question now is where the file should be placed. Best solution would be if it will use the VFS to find it, and it should not be named springrc, maybe springsettings? I would also prefer to move the linux config files from ~/.springrc to ~/.spring/springsettings.

[AF]

Are you saying spring settings and VFS file paths will now both go in the same file?

[Auswaschbar]

Are you saying spring settings and VFS file paths will now both go in the same file?

No, I'm not saying this (beside that this is already the case). I am proprosing that spring will store its settings in a file inside the first writable VFS path instead of some hardcoded path (currently its ~/.springrc on linux).

[AF]

That sounds like a logical loop, since to get the first writable path listed you need to open the file, and to know where the file si you need to look at the first writtable path, and to get the first writtable path you need to open the file, etc etc

lol Ive probably misunderstood anyway

[Auswaschbar]

Truth, didn't thought about this. So lets keep .springrc on linux then and use settings.cfg (what about this name?) in:

• My Documents/Games
• My Documents/Games/Spring
• My Documents/Spring

Keep in mind that the path is controllable via a commandline parameter.

[AF]

I do not think it would be wise to put it in my documents, as that would violate microsoft guidelines, as well as piss off a lot of the people on these forums.

Instead we need to use something in the shared user folder, not shared documents though. There are windows API calls to retrieve the path to this. We can then place a shortcut to the default location that users are supposed to put stuff in in the start menu to prevent confusion over where the content is stored, and those who currently use program files can continue to do so.

[Tobi]

The old one caused hard to diagnose crashes when used before main was entered (as it was in GML) because it used non-POD objects as global variables (e.g. std::string),

That is wrong because ...?

To take configHandler as example, if some code called GetInstance() before main was entered (in some global constructor / initialization code), then it would depend on link order whether the std::string (or any non-POD object) was initialized.

If this file that called GetInstance() was first on the link commandline the call would crash / be undefined (accessing an object that basically doesn't exist yet, because it's constructor hasn't been run), and if it was last on the link commandline it would work, because then the std::string would have had it's constructor run already.

I liked it better because it didn't crash . And I have a personal dislike against too much global variables.

Yes same here, but wrapping them in singletons (which are just global variables that need more typing in this case) isn't a better solution.

The naming pattern for global classes is clear enough IMHO: if I see blahHandler then I know immediately it's the global handler for blah. Don't need a singleton for that...

I do not think it would be wise to put it in my documents, as that would violate microsoft guidelines, as well as piss off a lot of the people on these forums.

Link?

[AF]

http://weseetips.com/2008/05/01/how-to- ... n-windows/

http://msdn.microsoft.com/en-us/library ... S.85).aspx

IIRC this has been posted multiple times before in discussions like this though.

In this case: CSIDL_COMMON_APPDATA would seem most appropriate.

[Tobi]

I ment link to the guidelines, the technical implementation is peanuts, we have that already somewhere in Spring.

Second link is dead btw.

[Auswaschbar]

CSIDL_LOCAL_APPDATA

C:\Users\user name\AppData\Local

User-specific game files that are read and modified and are of use only within the game context.

Game cache files. Player configurations.

[AF]

grah url tags, I would look inside the Vista file hierarchy specifications. A big effort was made that user data should go in user folders, and only program files should go in program files. The Program files is read only to anyone but super administrators (UAC prompt required)

http://crispybit.spaces.live.com/blog/c ... !134.entry

Writes to these forbidden folders are redirected into folders inside appdata in your personal user folder (not the documents subfolder), for compatibility purposes. The above link makes the point that this feature will be removed in the future breaking compatibility for those programs that do not fix themselves.

In the meantime finding anything on msdn is proving a nightmare


(ooo someone posted while I was googling )

[AF]

CSIDL_LOCAL_APPDATA

C:\Users\user name\AppData\Local

User-specific game files that are read and modified and are of use only within the game context.

Game cache files. Player configurations.

This would result in a PC with 5 spring players having 5 copies of every map and mod. Instead CSIDL_COMMON_APPDATA should be used.

[Auswaschbar]

CSIDL_LOCAL_APPDATA

C:\Users\user name\AppData\Local

User-specific game files that are read and modified and are of use only within the game context.

Game cache files. Player configurations.

This would result in a PC with 5 spring players having 5 copies of every map and mod. Instead CSIDL_COMMON_APPDATA should be used.

We are talking about the settings file here

[AF]

I also think this should be in shared docs, otherwise we would have to regenerate it for every user, or if a new user is added.

[Tobi]

Users should be able to have different settings tho. So unless configHandler will support reading stuff from multiple files and merging together I think every user should have his/her own settings file.

[AF]

Then perhaps using both and merging the results with the own users file taking precedence?

[Tobi]

That's what the unless...merging together part in my post was about

[AF]

yay clarification!!!

[Pressure Line]

Truth, didn't thought about this. So lets keep .springrc on linux then and use settings.cfg (what about this name?) in:

• My Documents/Games
• My Documents/Games/Spring
• My Documents/Spring

Keep in mind that the path is controllable via a commandline parameter.

would possibly be more consistent to use:

C:\Documents and Settings\user_name\Spring

??