Stuck implementing more commnad line arugments
Posted: 28 Apr 2012, 08:16Hello all,
I'm trying to extend the set of command line arguments to also support changing settings.
What seemed to be an easy task, turned out to be quite hard.
The problem
This is the current flow of the program.
Now we can't add for example -w, --windowed since that needs to change the settings object which isn't created yet.
I thought of creating it first, but then the changed settings would be overridden by the load settings step.
A simple solution would be to move the Load settings step up, before the argument parsing.
But in order to find the settings file the paths need to be configured, thus:
Possible solutions
A possible solution would be to create a Settings instance, change the configured values and upon loading from the config file only change the settings not set/not changed.
I don't think this is a good idea, just for the sake of the settings class. Parse file should parse the file and configure everything IMHO.
Another solution would be to move the path configuring and setting loading before argument parsing.
Don't let the configurePaths method quit the program but check the paths after argument parsing.
One problem left is that the configurePaths method creates directory which might not be desired in case of manually defining the data/user path.
What also could work is split the parsing in paths and other.
The paths parsing doesn't return the help/usage message or other output (except for errors).
Any suggestions?
I'm trying to extend the set of command line arguments to also support changing settings.
What seemed to be an easy task, turned out to be quite hard.
The problem
This is the current flow of the program.
- - Parse arguments (possibly setting data/user paths).
- Configure paths, if some set in previous step it won't configure those.
- Load settings
- Init, gameloop, etc...
Now we can't add for example -w, --windowed since that needs to change the settings object which isn't created yet.
I thought of creating it first, but then the changed settings would be overridden by the load settings step.
A simple solution would be to move the Load settings step up, before the argument parsing.
But in order to find the settings file the paths need to be configured, thus:
- - Configure paths, none can be set (if the auto data path detection fails the game will exit).
- Load settings
- Parse arguments (setting data/user path doesn't do anything)
- Init, gameloop, etc...
Possible solutions
A possible solution would be to create a Settings instance, change the configured values and upon loading from the config file only change the settings not set/not changed.
I don't think this is a good idea, just for the sake of the settings class. Parse file should parse the file and configure everything IMHO.
Another solution would be to move the path configuring and setting loading before argument parsing.
Don't let the configurePaths method quit the program but check the paths after argument parsing.
One problem left is that the configurePaths method creates directory which might not be desired in case of manually defining the data/user path.
What also could work is split the parsing in paths and other.
The paths parsing doesn't return the help/usage message or other output (except for errors).
Any suggestions?