If you create a hexagonal grid on a map, the grid covers the entire map, extending in perpetuity (an annoying trait I discovered when trying to set up a numbering system that matches what’s printed on the paper map).
If you need to set up zones that also reside on the map, what are the “rules” for overlap, especially regards movement reporting? In the list of such zones inside the Map folder, do the items “above” the others in the list ‘overprint’ or supercede those below it in the list? Will both maps/grids/zones report movement to/from the same area?
And finally, is there a way to edit the format and content of movement report messages? Say for instance, I have a draw cup in a map/display, and also a map/chart I’ve set up to place or display drawn chits from the cup. Can I edit the format of the movement report from one zone (draw cup) to another zone (holding cell on a different map/chart) to read something like, “An AM is drawn by [player]” and then, “[Name of AM chit] is moved to [Name of holding zone]”. All this assuming I’ve given names to the AM Draw Cup, and each of the the chart zones I’m moving pieces among? Could this also be extended to movement to and from the map (e.g., if a unit is routed and must temporarily be placed in a player’s Routed unit space on a different chart, would the movement report read, “[Name of Unit] moves from [hex 2013] to [Union Rout zone for {specific organization, as named in the zone identifier}]”
[attachment=0]interzone_movement.PNG[/attachment]
Example in this attachment: where the 74th IL regiment is routed by McNair and his unit, and thus is dragged from the hex on the map to the Routed Units box for Union chart for Davis’ Division of the Right Wing. Could the report format be edited so that the report would read, “74 IL moves from hex 3512 to RW/Davis Routed Units”?
The movement report format here would be almost identical to the default movement report format: $pieceName$ moves from $previousLocation$ to $location$
The key lies in the configuration of each of your Zones. In any Zone’s properties, you can specify the location format–i.e., which value gets returned. Zones commonly have a name ($name$), but in many cases grids embedded in them. You can return that by setting the location format to $gridLocation$. This will give you the hex identifier for a hex grid, a region name for an irregular grid, or row-column coordinates for a rectangular grid.
Thanks for the swift, cogent reply. Now I’m actually looking forward to diving into that part of my first module design…
Oh, but you missed the first part of the question: when multiple zones/grids are superimposed over a map, how does VASSAL know which zone has preference where they “overlap”?
I would avoid overlapping if you can possibly help it, but I’m almost positive that only one location will be returned. Whether it’s the first or last zone listed in order from top to bottom in the Editor I’m less certain about. You could whip together a super-minimal demo module to try it and find out.
When zones overlap or you have zones within zones for example the higher
zone in the editor tree is the zone that takes precedence (See that mod I
linked you - this does that)
I would avoid overlapping if you can possibly help it, but I’m almost
positive that only one location will be returned. Whether it’s the first
or last zone listed in order from top to bottom in the Editor I’m less
certain about. You could whip together a super-minimal demo module to
try it and find out.
You can’t help overlapping zones if you have a hex grid as one of said zones. There’s no way to truncate, shape or limit a hex grid (annoyingly enough).
