Possible for 'send to' to bring zone highlight data

There’s a map with zones. Land zones cover the land and have a hex grid. Seas and oceans do not have a hex grid. All also include weather zones, as weather affects more than just land. Each sea/ocean exists in 1 weather zone, but land zones contain multiple weather zones.

Weather zones are below the land zones when viewing them while editing the module. Placing the weather zones above the land zones kills the land zone ‘snap to’ function. Weather zones use ‘zone highlighters’ to visually display what weather each zone is experiencing (fine, rain, storm, snow or blizzard) (zone highlight names being 1, 2, 3, 4, 5 respectively)

I have a ‘send to location’ trait, the target being an off map separate window to do some maths to obtain a number for combat. I would like most of the combat math to be automatic with minimal input from players. Game pieces report their CurrentZone as the land zone name when on land and the weather zone name when not on land.

I would like to have, at least, the zone highlight name come with the game pieces on activating the ‘send to location’ command so I can then determine what the weather is for the weather zone the game piece(s) came from.

ATM I’m using a trigger action that runs a dynamic property before the ‘send to location’ command (as an aside, this method does not blank out the ‘send to location’ command after the game piece has being sent and a repeat selection of send to cancels the return coordinates on the main map).

Is there a way to reference the zone highlight name that is currently active for a weather zone? Said weather zone not being available for a land game piece using CurrentZone.

I suspect that the players will be required to manually input those elements not directly available from the game pieces, but I have some hope.

You are going to run into problems with this sort of implementation because Vassal does not really support overlapping zones. When anything tries to reference a Zone at a particular location, Vassal runs down the list of zones defined on the map until it find the first one that contains that location. As far as Vassal is concerned, no other zone exists at that location.

You have manged to get around this restriction a little by using Zone Highlighters which ‘light up’ the weather zones and give the impression that they extend under the other zone defined on top of them, but this is just an illusion, Vassal does not ‘know’ they are there under the other zones.

Basically, no, it’s as if the weather zones under the Land zones do not exist, even though they they are being highlighted.

I don’t know how complex you zones are, so I don’t how feasible this is, but here’s how I would approach it. It’s a fair bit to set up, but should be stable and efficient once done.

I think you are going to have to merge the Weather zones and the Land zones.

Basically, cut each Land Zone into as many pieces as the number of different Weather zones it lies over. Each of these new zones will have the same name as the original Land Zone, so any reporting via Land Zone name will remain unchanged. Painfully, you will have to re-align/re-number a new hex grid in each of the new zones (Cutting and pasting the original grid should be fairly close though).

You will then need to create a map level Global property for each Weather ‘zone’ (not land zone - A Weather ‘zone’ is now made up of multiple Land Zones) to control the highlighting. Each of the new Land Zones would then have its Zone highlighters following the appropriate global property for the Weather ‘zone’ it is in and will also need a Zone-level global property containing the name of the map-level property containing the weather for this zone. You can use this to look up the weather value you need for the combat calculations.

It would be something like {GetProperty(GetProperty(“WeatherProp”))}

Where every zone has a zone-level property named “WeatherProp” that contains the name of the map-level property containing it’s weather. Your map-level property names might be “Weather-NorthEurope”, “Weather-Pacific” etc.

You can tweak the weather in all the Land zones that make up a Weather ‘zone’ by changing the appropriate map-level global property.

Thanks for a rapid response. The concept looks good but implementation will the offspring of unwed parents. :slight_smile:

Will examine in detail later. Thanks

OK. Have completed the re-zoning process. But cannot get an expression to give me the global property value to work with.

I understand the logic of GetProperty(GetProperty(“property”)), but all it comes back with is a null.

Each defined zone has a name and what highlight global property to use. As I wanted to get the weather value of the zone the unit was in before being sent to the combat map I used OldZone for the property. GetProperty(“OldZone”) works fine, the name of the old zone is returned. Adding the 2nd GetProperty just gives a null.

Do nested GetProperty’s really work? As in GetProperty relies on text (does it not), thus maybe the first GetProperty result is not text, thus the 2nd one fails.

for info, there are 6 weather zones (arctic, ntemp, med, nmon, smon & stemp - temperate, monsoon, Mediterranean) and 5 weather types (clear (1), rain (2), storm (3), snow (4) & blizzard (5)). Would changing the numbers to the words help? (a process that will take a lot of time to do, although perhaps direct editing of the buildfile may be quicker. something to look into if needed)

All highlights work well (overlays a pic representing the weather type for each zone). I’m trying to get the value (1 to 5) of a zones weather. Is the zone highlight property accessible via another way - zone_Highlight for ex

Renamed all zones to have the first 6 characters define the weather zone (arctic, ntempa, etc). Used a set global (on trigger) to get these six characters from the longer zone name:

hexweathera: {If(CurrentZone==“defr1a”,(GetProperty(“OldZone”).substring(0,6)),“Fine”)}.

Then using a calculated property of GetProperty(hexweathera) gave the result I wanted.

Problem solved.