Region names vs numbers

So i have about 30 regions on the map. Each is named after a geographical entity, except 10 which are named 1-10 to simplify various internal functions.

When a unit moves, the game reports the unit and its new location (and I want it to), but the problem is some of the regions have digits, so it reports “alpha moved to 6”, instead of “alpha moved to Saigon”.

What would be the most efficient way to have the reports report the “game” location name, not the digit?

At the moment I am thinking a simple java function, with the function taking the location as the input and simply returning the input unless the input is a digit, in which case it would return the correct text. But I am a little hazy on how traits send and receive data from attached java code, so I welcome someone sketching that out.

Or is there some obvious vassal method I have missed?

I’d split your map areas into more zones. Every zone can contain its own irregular grid (where you can assign named/numbered regions as you wish). For the non-numbered areas, perhaps a single zone will suffice, with an irregular grid containing the names for each region. For the places that you seem to want the ability to refer to it by its name or number, make one zone per area, each containing an irregular grid with one region (the number).

A zone can report back its $name$ or its $gridLocation$, which you can set in the properties of the zone. For these 10 areas that have a number associated with them, you would choose $name$ as the reporting format. For all the remaining 20 or so areas set up as regions in a single zone, set that zone’s reporting format to $gridLocation$.

Seems to work. Holy preholy, who thought this stuff up? I can understand how new vassal developers are created - with immense amounts of blood, sweat, tears, heavy casualty rates and vast quantities of help from other vassal developers on the forum … but where did the first vassal developer come from?? … Something to do with the pyramids I suspect…

The manual seems to imply that zone shapes are optional, but the zone’s regions within don’t seem to appear [visible on map during editing or game] unless they are within a defined shape. Can anyone confirm or deny this?

The manual also says
“Use of a multi-Zoned Grid is not recommended for a map with many Zones.”
Any speculation on whether this would this be an issue for a map with 20 one-region zones?

I think a Zone must necessarily be a defined, bounded area. How else would named regions in an Irregular Grid belonging to that zone know they’re in it? The tool for drawing zones is badly broken if you need to make complex shapes, unfortunately–it messes up the placement of new vertices.

The For The People module has a multi-zoned grid for its map, and there is a zone for each of the States (so 11 Confederate states, 3 border states, and however many of the Union states actually appear on the map, I feel like 7 or 8, PLUS separate zones for the two army displays, the turn track, the two army strength tracks, the blockade track, the amphibious track, and the general reinforcements area, maybe a couple more even). Most of these (have tend to have 5-10 regions inside the zones, but some have only a single region e.g. Washington DC). So anyway I’m gonna say you’ll be fine with your number of zones.

Meanwhile Regions for your Zone will not respond correctly unless they are inside your Zone. (I occasionally break this rule accidentally and then spend a while wondering why nothing will work right in some specific one location)


Well, i was afraid of that…i noticed the manual implied that a board shouldn’t have more than one grid at a time…however the program let me do it…

So my board had an irregular grid with many regions.
I added a multizoned grid and created several irregular grids per your advice. I then cut and pasted the existing regions into these grids.
I then deleted the original, now empty, irregular grid.
Unfortunately the at-start stacks don’t recognise the new structure and can’t find their regions-
when saving: Bad location name in
when running : Error.setup_stack_position_error
Any suggestions on getting it to recognise the new structure?

Check and make sure all your new zones have $gridLocation$ rather than $name$ or whatever the default is for their name reporting. Because otherwise setup stacks will try to match with Zone names rather than Region names and won’t be able to find the regions.

OK, so all above is sorted, to summate:

So I had an irregular grid of 30 regions, 20 with names, 10 with digits.
Using digits is very handy for loops counting or deploying units.
However it resulted in ugly movement messages like Mekong->7.

I implemented zones, with 1 irregular grid for the 20 with names, and 10 one region zones for the digited regions (with each zone being given the regions ‘geographical’ name).

The large zone reports back using $gridlocation$, and the small ones report back using $name$.

This works for message reports, which now report back Mekong → Saigon. Luverly.

It works for sendToLocation, which sends the unit to the right region.

However it has run into two problems which seem to mean that the cure is worse than the problem.

It doesn’t work great for at-start stacks. If you nominate the digit as the starting location, it returns a can’t find error. If you nominate the name (in effect the zone name) it does not appear to place the unit on the region per see, just near it. Thus when further units are added or move to the region, they form their own stack (instead of all being a single stack on a single region in a single zone). Not a deal-breaker as their are workarounds (like sendthetoLocation at starting instant of game), just annoying.

But uh-oh, it doesn’t work for census functions, which initialise some Num=0, some Destination=7, then send a GK asking each unit to increment Num if its location matches Destination.

What I was hoping for was a method by which a unit thinks it is at region 7 for counting/calculation purposes, but thinks it is at Saigon for message reporting purposes.

I guess the problem could be solved by a java lookup function, or by actually using pieces as the locations instead of region, but I’m a bit reluctant for either. Maybe I will just drop the movement reporting (the census functions are too valuable).

Actually given that cards and pieces are all pieces, I am surprised the system does not treat regions as pieces as well. I must have a look at the source code sometime see what it does.

Fun fact with regard to at-start stacks, if you give them the exact x,y of a region, they will adhere themselves to that region.