Keep Server Options When Changing Ruleset

What would you like to see in Freeciv? Do you have a good idea what should be improved or how?
Viktyr Gehrig
Posts: 2
Joined: Fri Mar 15, 2013 6:13 pm

Keep Server Options When Changing Ruleset

Postby Viktyr Gehrig » Fri Mar 15, 2013 6:26 pm

Couple of things that would make my Freeciv experience a lot better:

Have the client remember which ruleset you used last and use it as a default, so that if your last game was Experimental, it assumes your current game is Experimental as well.

Failing that, changing it so that it does not reset all of your game variables to default values when you switch rulesets.

nef
Hardened
Posts: 166
Joined: Mon Jun 25, 2018 5:01 pm

Re: Keep Server Options When Changing Ruleset

Postby nef » Mon Nov 26, 2018 2:41 pm

See my comment #28

nef
Hardened
Posts: 166
Joined: Mon Jun 25, 2018 5:01 pm

Re: Keep Server Options When Changing Ruleset

Postby nef » Mon Dec 10, 2018 1:29 pm

Further developments.

The slow startup time with civ2civ3 has let me look into this in more detail.

The case appears to be that ruleset startup processing is quite distinct for initial ('default') and subsequent rulesets:

a. for the initial startup the ruleset name is hardcoded (I presume in the client and passed as an argument when starting the server). When finished the server notifies the client (presumably through the packet interface.) The ruleset "Set" values are not displayed in this case. The client then performs an internal version of "Apply" (as seen in the "More Options" dialoque). This means that saved server options are sent to the server as commands and are honoured in this case. Note that the saved server options stay current in the dialogue and (therefore) also stay as the "Refresh" values.

b. for subsequent changes to the ruleset selection either directly ("/rulesetdir ...") or indirectly (through menu) the client first notifies the server with the rulesetdir command. When it is told that the server has loaded the ruleset and is ready, the client THEN performs internal versions of "Reset" and "Apply" (in that order).

Note that "Apply" not only sends commands to the server but also changes the stored "Refresh" options to what's displayed in the dialogue. So after a "Reset" it is "Apply" that actually destroys the saved options (i.e. those that would be reinstated with "Refresh".)

There is a chance that a one line patch could fix this, i.e. remove the implicit call to "Reset". Potentially an exemplar of 'just remove the bad code'.