Highlighting not Changing during Online game

Technical Support & Bugs
21

I am not certain whether Zone names need to be unique across the Map they’re in to work correctly. I suspect this might be the case.

A safer solution might be to change the module so that no two Zones within a Map share a name.

22

The bug - and I do believe it is a bug - addressed by the pull request is triggered in some particular circumstances:

  • The module defines a Map Window that may hold one board.
  • The module has multiple candidate Map Boards that can be put in the above map
    • The boards must have distinct names
    • BTW, the Board page should be linked to from the summary
  • Each board defines a number of Zones
    • The Zone names within a board should be distinct, or it will be impossible to address a particular zone
    • The Zone names does not need to be distinct across boards (i.e., boards B1 and B2 may both have the zone Z1)
    • In fact, it may be Desirable that the zone names are constant across boards, so that the piece, and other, logic may simply address the zones with the same name. That makes the number of boards much more scalable.
  • The zones contains Properties.
    • Within a zone, these properties must have unique names
    • But across zones, these properties can (and often will) have the same name. For example, it could be the property that defines the zone highlight - say Highlight, a movement cost property - say MFCost, earned victory points - say VP, and so on. In all these cases it is desirable to have the same property name.

Note, in the above, the realised Map has one board. What I mean by realised is that the Map setup has only one active board. When Vassal produces a ChangePropertyCommand and sends that off to the other client, the receiving client does not check if a board is actually active. Thus, the ChangePropertyCommand will end up at the Zone with the right name in the first defined board - whether it is active or not.

The above PR addresses that issue by scoping the ChangePropertyCommand to a particular board.

If the Map is defined to be able to hold multiple boards (which is not the situation described above), then to address a Zone - or a property within that zone - the names of those must be unique. That is, if the map can contain boards B1 and B2, then these boards should not define zones with the same name.

However, that is an entire different use case from the one outlined above. In that case, the map may only contain a single board, and it is then desirable that zone names can be the same across boards (all candidate boards could for example define a zone named DeadPile, and piece and other logic will be able to address that zone through that single name).

It is not uncommon for a map to have multiple candidate boards, but only allow one active board. Since Vassal does not, when it receives a ChangePropertyCommand check if the addressed board is active, it may mean that the command ends up on an in-active board, and thus the command is gobbled up and never realised.

Also note, that without the above PR, there’s an asymmetry in how pieces and zones are addressed. Pieces are always addressed within a particular board context, while zones are not.

That is actually not safer when the realised map may contain only one (of many possible) boards. If the zone names are unique across all boards, then the piece and other logic will have to deal with that in a way that will grow quickly - that is not safer, but much more error prone. This is probably also why addressing a piece is already done within a particular board context.

I suggest you take a look at how zones and properties are used in the module under consideration. It is a perfectly valid way of doing it. The map contains a single board (chosen from a number of candidates), and these boards contains zones in which a property need to be changed to set a different highlight. Multiple boards may contain the same zone - say West Germany, but only one such zone is active at a time. However, Vassal does not check if a board is active when it receives a command to change properties in a zone, and so the change can go to the inactive (or wrong) board zone. The above PR addresses that.

Note that the PR has no effect in the case that the realised map has multiple boards, because in that case the zones presumably already has unique names. In the case where a realised map has multiple boards and some of these boards have the same zone name, then the PR will isolate the effect of changing a property in such a zone to the instance where it is changed - which is likely to be the desired outcome.

I think the PR is sound and actually addresses a real bug in Vassal - one that isn’t mediated by changing the zone names in the module.

Yours,
Christian

23

Note, in the current situation, if a realised map M has two boards - say B1 and B2, and the both define the zone Z, and those zones have the property P, then ChangePropertyCommand of P originating from the zone M/B2/Z will always end up changing the property P in M/B1/Z, since the ChangePropertyCommand is consumed on the first match. That is clearly not what one wants. The PR would change that so that a change of P in M/B2/Z will go to P in M/B2/Z, and a change of P in M/B1/Z will go to P in M/B1/Z. This is far safer than changing the zone names in all cases.

Yours,
Christian

24

Christian,

Tried the Snapshot and that worked as expected.

Thank you for your work.
Tim

25

Great. I hope @uckelman will apply the pull request so that this issue can be closed.

Yours,
Christian

26

The pull request has been merged into master, which means it will likely be available in release 3.8.0.

You can mark the issue as resolved now, or wait until 3.8.0 is released. In any case, the issue should be resolved so that others may find the solution to their problems more easily.

Yours,
Christian