Project

General

Profile

Bug #685235

2.6 tileset selection is still a bit incoherent

Added by Jacob Nevins 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Client
Target version:
Start date:
Due date:
% Done:

0%


Description

I don't think we've quite dealt with all the fallout from per-topology tileset preferences yet (gna bug #16668).

I don't have a coherent notion of where we should be yet, but the following current behaviours seem wrong to me:
  • 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).
    • Currently, mine is "hexemplio" (somehow). When I "Start New Game", the client switches to "amplio2" and back to "hexemplio". If I load a new ruleset in the pregame screen, it does the same again. This is slow and causes console message.
    • This hidden setting seems to change to different values in some circumstances, but I'm not sure when.
  • We don't allow the user to save a preferred "topology" for single-player games (since gna bug #25249). This means the user doesn't have control over saved topology or tileset for single-player games.
  • 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)

I suspect that part of this stems from needing to have a tileset loaded before we have a connection to a server and hence a map topology; it's not clear how we should choose that tileset.

I'm not sure what the right behaviour is. I've created a wiki page 26tilesets to work it out. Please join in. Then we can work out how to get there from here.


Related issues

Related to Freeciv - Feature #653727: Possibility to force tileset with different topology (like v2.5) Closed

History

#1 Updated by Jacob Nevins 2 months ago

  • Related to Feature #653727: Possibility to force tileset with different topology (like v2.5) added

#2 Updated by Marko Lindqvist 2 months ago

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.

#3 Updated by Jacob Nevins 2 months ago

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.)

#4 Updated by Marko Lindqvist 2 months ago

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.

#5 Updated by Jacob Nevins 2 months ago

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.

#6 Updated by Jacob Nevins 2 months ago

...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.

#7 Updated by Marko Lindqvist 2 months ago

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.

#8 Updated by Marko Lindqvist 2 months ago

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.

#9 Updated by Marko Lindqvist 2 months ago

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)

#10 Updated by David Fernandez (bard) 2 months ago

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.

#11 Updated by Marko Lindqvist 2 months ago

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

Also available in: Atom PDF