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 Freecivemail@example.com https://mail.gna.org/listinfo/freeciv-dev