"send_desired_settings" client option
It is late now, but I'll try to describe in my next post an use case that is currently hard to achieve with the current behavior of the client, and I hope this new ticket can help.
I rewrite my example (I'm using v3.0.6 and qt-client):
1) Imagine I install freeciv for the first time (clean user settings). I install a ruleset, I play an auto-game with the default settings (Default+Ruleset), and a certain seed, and I find a bug.
2) After that, I play another ruleset, and I manually change some settings. I use the client GUI to save the server settings of that game (to freeciv-client-rc file).
3) Next day I want to recreate the bug of the first day, with exactly the same settings used in (1), in order to get the same bug with the same seed. From my tests, it is no longer possible to achieve this just using the current client GUI.
Once a different set of server settings have been saved, it is not possible to restore a clean state of the file freeciv-client-rc (as a clean install of freeciv).
If you use "reset" button, then apply and save, a group of server settings appear in freeciv-client-rc. They have default values, but once there, if you load the ruleset from (1) the resultant mix of Ruleset+Default is not the same, because the default options stored in freeciv-client-rc now have preference over the ruleset settings.
Opened also #47680 about "per ruleset settings on client side", relevant for some of your points.
In my opinion, the decision to store (in freeciv-client-rc ) only the settings that have been manually changed by the user is a mistake, and it has kind of unpredictable results.
As a user, if I change the setting1 and I keep the setting2 at default value, it doesn't mean that I don't care about the value of setting2, it just mean that my desired value happens to be the default one. When I save these settings I expect both to be treated the same way. I'd never expect what seems to be the current behavior of the client:
- setting1 is stored (in freeciv-client-rc), and from now on, it will be prefered over the value of the ruleset.
- setting2 is not stored (in freeciv-client-rc), and from now on, the value of the ruleset will be prefered.
In order to get the same treatment for the 2 settings, it seems I have to change the value of setting2 to something I don't like, save it, and then change setting2 to my desired default value, and this way it does appear in freeciv-client-rc with the same status as setting1.
If this is how it works (I'm still not sure), I think it is an unpredictable way of handling the user preferences. It is much more reliable the command /write that seem to save all the settings exactly as they are.
Well, I think that at least we agree about the feature in this ticket - that it should be possible to disable the current client behavior.
I think "my desired value happens to be the default one" reveals that you've missed the distinction between "default value" and "value identical to default". This was originally implemented on the server side for migrating games saved by an older freeciv version. If a scenario (or other savegame) has a setting set to value identical to the default of the old freeciv version, should we change it to the default in current freeciv version? Since freeciv-2.5 (IIIRC), freeciv savegames store whether a setting is supposed to be "default" or "specific value". Granted, no client GUI provide means for the user to specify it (I hope to get that done in not too distant future), but client does know whether user wants "specific value" or "default value" (where default depends on the ruleset).
I don't completely agree with "if I change the setting1 and I keep the setting2 at default value, it doesn't mean that I don't care about the value of setting2" - or rather; I don't think one who WANTS setting2 to match whatever ruleset they are currently using is not caring about it. "aifill" could be one example again; if I set "aifill" (as setting1), it should not force me to use my own settings for everything else too. Most rulesets fully well support also many styles of maps, so user should be able to change things like "landmass", "generator" etc, and still get the ruleset specified settings for other things.
Reply To cazfi
Since freeciv-2.5 (IIIRC)
My memory failed me. The feature came in freeciv-2.6. ( https://www.freeciv.org/wiki/NEWS-2.6.0 )
Reply To cazfi
Well, I think that at least we agree about the feature in this ticket - that it should be possible to disable the current client behavior.
I admit I'm still not sure what would be the result of enabling this option: user client settings are ignored and the ruleset settings are automatically applied in the server? Or client and ruleset settings are ignored, and they are used the settings defined directly in the server via write/read?
The problem I see with the proliferation of these settings is that they may cause more confusion for a user that do not know what will be the result of enabling/disabling them, like me.
I must say here that my complains about server settings did not start because I liked the previous buggy behaviour. With the previous version, the first time I made tests to use the client to change and save my desired server settings, the result was unreliable for me, because they were automatically changed by the rulesets without my consent, and I did not feel as a user in control to avoid it: "save" (server settings) button worked as broken to me.
That is why I stopped changing the server settings in the client and I started to change them in the ruleset itself: every ruleset I used, I edited game.ruleset to choose my desired settings for each rules and they have been working in a reliable way until now.
Since your latest fixes (bugs that I do not consider features), my way of using the ruleset to set the server settings is no longer reliable either: the resultant settings depend of the state of the file freeciv-client-rc of the client and it is hard to predict the result of a certain ruleset being loaded in a different client from different players. And as I have said, I find it hard to be sure which settings are really being used when I debug or try to recreate bugs.
With v3.0.6, I'm currently using the write/read server commands because the client is not longer reliable/predictable for me. This ticket sounds like something that would help, but I'm still not sure. (I plan to continue my comments in #47680 but wanted to understand this ticket first).
Reply To bard
With v3.0.6, I'm currently using the write/read server commands because the client is not longer reliable/predictable for me. This ticket sounds like something that would help, but I'm still not sure.
That should be the case. With this new setting you could just disable the client side "override" of settings set on the server side.
In fact, that's exactly what I want to do myself (you see, personally I want to use the same setup as you, but am just arguing for the sake of what other users have strongly expressed to be their preference)
You shouldn't even need to use the "read" command as such, if you get your preferences (.serv) to be detected as a separate "ruleset" in the client drop-down menu.
Patch attached. Status "Accepted" as in "Accepted to review" - not as something that has already passed the review.
Idea from the #47649 discussion: Add client option to control if desired settings are sent to the server or not.