Commandline options 1/0 <=> true/false on win32

It works perfectly well for me, Tino ( winXP SP3)
I do that all the time (edit the config file, because the game crashes when I change OpenGL or resolution from within the UI)

here is my C:\Dokumente und Einstellungen\Wolf\.widelands\config file.

# Automatically created by Widelands bzr6549[trunk] (Release)

[global]
disable_fx="true"
xres="1900"
yres="1080"
fullscreen="false"
inputgrab="false"
single_watchwin="false"
auto_roadbuild_mode="true"
workareapreview="true"
snap_windows_only_when_overlapping="false"
dock_windows_to_edges="true"
depth="32"
disable_music="true"
language="en"
autosave="0"
maxfps="20"
sound_at_message="true"
nozip="false"
ui_font="serif"
speed_of_new_game="1000"
border_snap_distance="3"
panel_snap_distance="3"
remove_replays="43"
remove_syncstreams="true"
opengl="true"
fx_volume="31"
music_volume="13"
transparent_chat="true"
realname="Astuur"
nickname="Astuur"

I did not mean the values in the config file or editing the file.

I am aiming a the dynamic setting via commandline on widelands invokation,e.g.:

> c:\widelands\widelands.exe --opengl=true

Using true or false does not work.

It is no bug, it is working as intended.
The parameter description and the code shows clearly that 0|1 are the possible values which are checked.
i am not sure why:
- this parameter uses 0|1 whereas all other parameters comparable use true|false
- why it is working on linux (because the code does a string comparison against "0" and "1"

I'll close the bug for now. If desired i could commit a patch which switches this parameter to "true"|"false" but this would result in an required update of the translations.

Wow, you are right - yes/no doesn't work. I could swear I tested this last week....

I am growing old.

Since each change will now only affect 1 line in the translations, I'm all for having something consistent here. At the moment, we have a mix of [0|1] , [yes|no] and [true|false]. I think we should get rid of [yes|no] and then pick if we want to have [0|1] or [true|false]. [true|false] is very common in Linux systems, [0|1] would be language-independent, so they both have something going for them.

+1 for consistency.

While [0|1] is language-independent and that is great plus, are they as understandable as true/false? Or do we consider it clear enough for cli users?

(Btw, if we change to a single scheme for boolean values, any thoughts on how we plan to migrate/update ~/.widelands/config so that new values are set. Or would this simply be covered by feature, I mean bug 980297?)

true/false is errorproof

For me it would be ideal if program could parse both: 0/1 and false/true everywhere :)

+1 for #7.

+1 for #7.

That will also take care of downwards compatibility for the config.

Actually, profile.cc has a list of acceptable true/false values already, so all I had to do was to remove the restriction for opengl to 0/1.

Fixed in r7215.

Fixed in build19-rc1.