Freeciv

Jacob Nevins wrote:

• client_start_server() still propagates topology from tileset to server. I don't think this makes sense now that our settings are per-topo. (Perhaps what led to the decision above)

We have both use-cases where the tileset is the authoritative source of topo+tileset, and use-cases where server topology is the authoritative source of topo+tileset. Especially, when user chooses specific tileset from the commandline (--tileset) that one should be used and topology of the spawned server set accordingly. Also, since client does not save topology (as you mentioned), the preferred tileset does indirectly keep that information and for that to work topology needs to be set from the tileset.

use-cases where the tileset is the authoritative source of topo+tileset [...] Especially, when user chooses specific tileset from the commandline (--tileset) that one should be used and topology of the spawned server set accordingly

However, --tiles is currently doing double-duty as a "allow topo and tileset to differ" escape hatch (cf feature #653727); if we want to keep that, I'd argue that --tiles shouldn't influence the starting topo.

since client does not save topology

I'd prefer to reverse that change, if we can. If the user prefers hex tiles for their local game, I think the "topology" setting is a more natural place to express that than a tileset setting. (And they'll naturally get a matched set if tileset follows topology as usual.)

Jacob Nevins wrote:

If the user prefers hex tiles for their local game, I think the "topology" setting is a more natural place to express that than a tileset setting.

Remember all the bug reports that motivated these changes to tileset <-> topology interactions. It seems most users expect game to behave like a hex game when they choose tileset that appears hex, and no separate setting needed.

But we no longer have a UI which makes that a sensible expectation (discounting --tiles for a moment). In 2.6, the user is presented with a block of four settings:

Tileset (Overhead)      [ trident   ]
Tileset (Isometric)     [ amplio2   ]
Tileset (Hex)           [ hex2t     ]
Tileset (Isometric Hex) [ hexemplio ]

I don't see how a reasonable user can conclude that any setting of this UI will give them a hex game.

...I take your point that the evidence suggests users think more in terms of "tileset" than "topology", but the UI already sets them on the right path; I think it just takes a bit more hinting (tooltips on the tileset UI) to lead them to the "topology" setting in the local-game UI.

Jacob Nevins wrote:

However, --tiles is currently doing double-duty as a "allow topo and tileset to differ" escape hatch (cf feature #653727); if we want to keep that, I'd argue that --tiles shouldn't influence the starting topo.

Hmm... you could still explicitly set BOTH tileset and topology to get incompatible ones even if setting either one alone would always trigger the other one to be compatible.

That said, we do need to do something for handling non-hex iso vs non-hex overhead topology/tileset interaction better. There should be no hard incompatibility between those topologies.

Jacob Nevins wrote:

• This hidden setting seems to change to different values in some circumstances, but I'm not sure when.

I haven't checked how/if it works, but I think it should save CURRENT tileset as the value when saving settings from a running game. Same as with View menu items, cities dialog settings etc.

Another use-case to consider if we add separate topology setting:
1) User has hex topology saved as preferred topology (default in S3_0 and later)
2) User loads ancients modpack that has non-hex preferred_tileset. Ancients has a hard dependency on that tileset (ruleset doesn't work with standard tilesets)

We still have a hidden client setting "default_tileset_name" that is saved in the rc-file, and affects behaviour, but is not exposed in the UI (as far as I can tell).

That's what I have been using until now, and I think it could be useful if exposed in the UI someway. For example:

Tileset (Overhead)      [ trident   ]
Tileset (Isometric)     [ amplio2   ]
Tileset (Hex)           [ hex2t     ]
Tileset (Isometric Hex) [ hexemplio ]

[X] Force Tileset       [ any       ] -> saved as default_tileset_name in rc-file

That said, we do need to do something for handling non-hex iso vs non-hex overhead topology/tileset interaction better. There should be no hard incompatibility between those topologies.

I agree. I vote you disable the warnings for iso vs non-iso compatibility, even if you keep the warnings for hex vs non-hex.

I know this ticket is about redefining what the correct behavior is, but I tested that following works correctly as it should with current definition of correct:
1) Using --tiles results spawned server to get compatible topology
2) Using --tiles and explicitly changing topology to a incompatible one lets you in game with incompatible tileset/topology (tested with the non-hard incompatibility of iso vs overhead)
3) Starting client without --tiles and explicitly changing topology results in a compatible tileset in game
4) Start client with --tiles different from old tileset and topology setting, "Save Settings Now", and restarting client without --tiles (with the values found from settings) results in a game with same tileset (-> and topology) as were in use at the moment of saving settings

Just to note for others that experience this bug and find this issue via web search: If you're trying to launch a local game with an expanded ruleset (e.g. ancients) that demands it's own tileset, a workaround is to launch the server separately (e.g. "./fcser -r data/ancients.serv") and then join it via the client later, after setting the default tileset per topology correctly in the client and ensuring that the server is running the correct topology for the tileset/ruleset combination ("set topology ISO|HEX|WRAPX" or whatever) before you join it.

There is an issue with scenarios: Freeciv 2.5 allowed to play them with amplio2 (iso), but Freeciv 2.6 automatically loads trident.
The only way I've found, thanks to Nate Martin's comment, is to start the server separately:
$ /usr/local/freeciv2.6/bin/freeciv-server -r /usr/local/freeciv2.6/share/freeciv/scenarios/british-isles-85x80-v2.80.sav.gz
This is the server for Freeciv version 2.6.0-RC1 ...

And then start the client and "connect to network game".
I think it would be better if scenarios are started with amplio2 by default.

Sorry, it didn't work:
$ /usr/local/freeciv2.6/bin/freeciv-server -r /usr/local/freeciv2.6/share/freeciv/scenarios/british-isles-85x80-v2.80.sav.gz
This is the server for Freeciv version 2.6.0-RC1
You can learn a lot about Freeciv at http://www.freeciv.org/
2: Loading rulesets.
2: AI*1 has been added as Easy level AI-controlled player (classic).
2: AI*2 has been added as Easy level AI-controlled player (classic).
2: AI*3 has been added as Easy level AI-controlled player (classic).
2: AI*4 has been added as Easy level AI-controlled player (classic).
2: AI*5 has been added as Easy level AI-controlled player (classic).
2: Loading script file '/usr/local/freeciv2.6/share/freeciv/scenarios/british-isles-85x80-v2.80.sav.gz.serv'.
Cannot read command line scriptfile '/usr/local/freeciv2.6/share/freeciv/scenarios/british-isles-85x80-v2.80.sav.gz.serv'.
2: Now accepting new client connections on port 5556.
(and now a new game is started)

Pierre R wrote:

Sorry, it didn't work:
$ /usr/local/freeciv2.6/bin/freeciv-server -r /usr/local/freeciv2.6/share/freeciv/scenarios/british-isles-85x80-v2.80.sav.gz
This is the server for Freeciv version 2.6.0-RC1
You can learn a lot about Freeciv at http://www.freeciv.org/
2: Loading rulesets.
2: AI*1 has been added as Easy level AI-controlled player (classic).
2: AI*2 has been added as Easy level AI-controlled player (classic).
2: AI*3 has been added as Easy level AI-controlled player (classic).
2: AI*4 has been added as Easy level AI-controlled player (classic).
2: AI*5 has been added as Easy level AI-controlled player (classic).
2: Loading script file '/usr/local/freeciv2.6/share/freeciv/scenarios/british-isles-85x80-v2.80.sav.gz.serv'.
Cannot read command line scriptfile '/usr/local/freeciv2.6/share/freeciv/scenarios/british-isles-85x80-v2.80.sav.gz.serv'.
2: Now accepting new client connections on port 5556.
(and now a new game is started)

That's because you're using the wrong option in the command line to load the file. -r is for rulesets, not savegames. Check this wiki page for command line options: http://freeciv.wikia.com/wiki/Server_command-line_options. Use -f instead of -r and it should work for you.

Note that I have not tried this workaround for savegames, just my custom ruleset.