Submitted by stedevil
We need a way to force clean default game setting at startup.

Currently, if we have an incompatible setting in ~/.freedroidRPG the game just wont start. Pretty stupid to have to nuke your settings just to be able to test an older game version (eg for debugging purposes).

Eg having latest SVN but trying to start a much older version give the following error.
----------------------------------------------------------------------
Freedroid has encountered a problem:
In Function: input_set_keybind.
FreedroidRPG package and version number: freedroidrpg 0.11svn.
Unable to set keybinding 'cut', that command doesn't exist.

Posted by ahuillet
What behavior do you advocate ?

Posted by stedevil
./freedroidRPG --force 
or 
./freedroidRPG --ignore-errors
or whatever

should turn all fatal errors into report to console warnings only.

Posted by stedevil
Umm, in my head Im confusing this FR a bit with another request "Command line option to turn of fatal errors"

Consider previous answer to be more targeted to that.

This one would be about simply ignoring the presence of a ~/.freedroidRPG directory, and create a new config file "in memory only" with default settings.

Sorry about the confusion.

Posted by barbatrixx
Sounds viable, 
I'm in favour of such a switch, too.
When doing repeated compilings/testing, you may have to adapt the screen settings and sound every time, though. So, perhaps, the configs could be saved in an alternative or temp file with an appropriate switch: -a or -t...
 

Posted by ahuillet
It is more complicated than that - the purpose of this feature should not be solely of helping developers (and I don't really see how a commandline switch is easier than a rm -rf, for that matter).
The problem is that when we make a new release - and this is especially true of the upcoming 0.13, users trying it with their old config file will see unexplained breakage. We have to have an automated way of detecting that the configuration file is old, and ignoring it in that case.
On the other hand I'd like to avoid using a version tag, because it means that e.g. the chosen screen resolution would be ignored even when it works.

I don't have a good idea of how to do this but in my opinion this is the last blocker for 0.13.
Increasing priority to reflect that.

Posted by stedevil
Since neither settings nor savegames tend to be compatible over version bumps, why don't we simply save everything for the 0.13 version in

~/.freedroidRPG/0.13/

The day that we for some strange reason reach the level of savegame compability between 0.x releases, a copy of the savegames from ~/.freedroidRPG/0.x-1 to ~/.freedroidRPG/0.x/ is simple enough to do, especially since savegames are now a lot smaller than they used to be.

To cater also for developers we could then have ~/.freedroidRPG/SVN/ enabling a dev to keep a working copy (including savegames) of eg 0.13, 0.12 as well as SVN without consistently having to nuke all gameplay data (some of us wants to actually play the game from time to time... if nothing else for playtesting).

Posted by ahuillet
I fixed loading a configfile from 0.12 with latest SVN.

Moving back priority to the original value.

The solution I see is that if for some reason, loading of the game configuration fails, we should reset to sane default values. I need to think about that a bit more. Killing the config from one revision to another is probably the simplest thing to do. As long as the version string remains the same, we'll try to load the config, otherwise we simply drop it.

Easy and efficient...

Posted by stedevil
Easy and efficient works for end user without funky bugs. :) Minimum for 0.13 I would say.

Though it is still a bit tedious for a dev trying to jump between different versions, where multiple saved config copies could be preferred since the configfile is saved in ~/.freedroidRPG instead of eg ~/.freedroidRPG/Desktop/SVN/FDRPG where the binary is manually run from.

Posted by ahuillet
Although I haven't implemented it, I have described the solution below, so this only has to be picked up and done.

Ahuillet's proposition implemented, via the use of a lua-based config file +
some minor bug fixes.