Tue 02 Feb 2010 07:51:51 PM UTC, SVN revision 16686:
Added possibility to load settings from the ruleset.
Patch by Matthias Pfafferodt (syntron)
See gna bug #13873
(Browse SVN revision 16686) |
Sun 31 Jan 2010 02:36:41 PM UTC, comment #12:
updated version; changes:
- loop over all entries in the [settings] section in the ruleset file
- for each entry check if it is a valid setting
(file #7854)
|
Sun 31 Jan 2010 11:12:58 AM UTC, comment #11:
I don't like how setting_ruleset() works. Maybe you could convince me the way you choose. For the moment, this is my argumentation.
You iterate all settings, and attempt to take their value in the file. In a such implementation, I think the best would be to use secfile_lookup_str(), secfile_lookup_int() and secfile_lookup_bool() instead of a their _default variant.
Another approach would be to iterate all the entries of the ruleset file and try to match the settings. I guess this could be the best solution because usually, there are not a lot of settings defined in the ruleset. Also, this would allow to warn the user if he misspelled one setting (no match).
|
Mon 25 Jan 2010 05:18:40 PM UTC, comment #10:
I created an rebased version and the patch now uses the new ruleset functions - but it are only a few calls to them.
(file #7790)
|
Sun 24 Jan 2010 09:14:56 AM UTC, comment #9:
This patch could be improved a lot with the new registry interface.
|
Sun 11 Oct 2009 05:32:50 PM UTC, comment #8:
updated patch; changes:
- restore all game settings, if the game is stopped by /end
(file #6969)
|
Sat 10 Oct 2009 10:54:13 PM UTC, comment #7:
updated version; changes:
- loading a savegame will first restore the ruleset (with possible changes to the settings) and after that restore the savegame and the setting values saved within the savegame
(file #6957)
|
Sun 13 Sep 2009 08:45:09 PM UTC, comment #6:
rebased version of the patch:
save game settings in game.ruleset
- rulesetdir will first do a reset and
after that load the new ruleset
- reset will restore settings from the
ruleset
(file #6687)
|
Sun 26 Jul 2009 12:31:54 AM UTC, comment #5:
updated patch for reset command
the points mentioned in the last comments
will be implemented in patch 8-11 (they
can be found in the tracker patches)
(file #6256)
|
Fri 24 Jul 2009 08:00:45 AM UTC, comment #4:
this could be done with an extra line in the
game.ruleset file
[game]
; define the game setting
borders = 2
; lock it (first player is not allowed to change it)
borders.lock = 1
The <setting>.lock defaults to FALSE. If it is
true, the setting can't be changed. This requires
that the 'rulesetdir' command can't be executed by
the first player.
Does warclient/warserver has such an option?
First I have to solve the main problem. My ideas are:
- 'rulesetdir' command loads the ruleset + settings
from the game.ruleset file
- The reset command has to restore all settings to the
default values and load the settings from the
game.ruleset file. An additional hint to changed
settings could be added.
- executing 'rulesetdir' again does check if another
ruleset is requested. If it is not the case, the
current code will do nothing. This must be
changed to a reset (= default settings + changes
from the game.ruleset file). This way one will have
a well defined state after executing the rulesetdir
command.
|
Thu 23 Jul 2009 09:40:03 PM UTC, comment #3:
I just thought of feature which could be built on top of these patches, I assume.
I run public servers with custom rulesets (in addition to default ruleset ones). With these servers I'd sometimes like to further limit what settings changes first player is able to do. Ruleset may have its own special flavor coming from certain settings. It's a waste of these custom ruleset server instances if first player turns them in to more generic Freeciv games (for which there already is plenty of servers).
So ruleset could mark some settings locked, so that they cannot be changed.
|
Sun 12 Jul 2009 08:28:29 PM UTC, comment #2:
> contra
> - two ways to set the values; confusion?
I'm not so sure it would cause much confusion as one way is used primarily by players and the other by modpack authors. Of course you have to be careful in implementing it so that player settings have higher priority than ones from ruleset.
I'm a bit undecided if I like this feature or not. In any case, reset command has higher priority.
|
Fri 10 Jul 2009 10:24:05 PM UTC, comment #1:
loading game settings from the ruleset and the reset
command are exclusive at the moment. For both to work,
an additional variable ([b|i|s]val_ruleset) would be
needed for each setting to restore the corresponding
value.
So I would like a discussion about the pro and cons
of loading game settings from the ruleset file.
pro
- all settings in one file (scenarios!)
contra
- two ways to set the values; confusion?
more arguments?
|
Sun 05 Jul 2009 10:21:38 PM UTC, original submission:
load game settings from ruleset file
- small correction for setting_check()
- further simplification possible?
|