Follow-up Comment #2, bug #18328 (project freeciv):
The reason the behaviour when reading game.ruleset is different from that on
the server command line is that the various types of options are mapped onto
the secfile format's native representations of those types. For instance,
secfile likes to represent boolean values as either integers (as you've found
in comment #1), or TRUE/FALSE (case-insensitive, but no quotes). This is
defined in registry.c:entry_from_token(). So you should find
"something", FALSE, FALSE
works.
In contrast, the server command-line parsing for boolean options uses the
string parsing in settings.c:bool_name(), which appears to allow only the
strings "DISABLED"/"ENABLED" (case-insensitively).
This isn't a very good reason, more an explanation of why it has ended up the
way it is.
With regard to your issue in comment #0, I don't see that there would be any
harm in replacing the strcmp()s in secfile_lookup_enum_data() with
fc_strcasecmp()s or similar, which would make the lookup for enum and bitwise
options case-insensitive. (It's only currently used for settings, in rulesets,
savefiles, and client options, I think.)
With regard to your issue in comment #1, in setting_ruleset_one(), for
SSET_BOOL, if the existing secfile_lookup_bool() fails, I think we could fall
back to a secfile_lookup_enum_data() using the name function from the boolean
setting. That would allow you to enter the syntax you wanted, and again I
can't see the harm.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?18328>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
