Problem: Numbered Grids revert to default values

I seem to have discovered a recurring issue, but I don’t know if I’m causing it or if it’s an actual bug.

In two different custom modules, I have created a rectangular grid in at least one Zone of a Multi-Zone Grid. The rectangular grid never gives me a problem. However, when I add numbering to the grid, the following happens:

  1. I create the numbering, changing parameters such as “vertical first” or using letters for one axis of the grid.
  2. I click OK to accept these parameters.
  3. I do some other unrelated work on the module.
  4. I return later to adjust some portion of the grid numbering or to test some item associated with the numbering.
  5. When I open the Grid Numbering dialog box, all of the values are reset to the defaults as if I had created a new numbered grid.

Further, when I try to use the modified (non-default) numbering that I set up earlier, the module doesn’t recognize it. When I try to move the grid so that the required numbers/letters fall in the required boxes, they just “wrap around” and don’t increment or decrement to new settings. For instance, if I want the first box of the grid to be F04 and the last to be F00, no matter how I move the grid with the arrow keys, the grid never gets any closer to these settings. The same settings just keep reappearing as the grids scroll by. I have tried this with both modules and with different Zones/rectangular grids in each module with no success.

Is there a known bug with grid numbering and I just missed it? I’d really like to set up the grid numbering so that its LocationName corresponds to the actual numbering on the game board, if for nothing else than ease of reference.

Any help would be appreciated, as I just can’t figure out what the problem is here.

What version of VASSAL are you using? I will take a look after work and see if I can replicatethe issue.


I just installed 3.1.17, but this grid numbering issue has been occurring since at least 3.1.14 for me. From what I can tell, it’s not specific to the latest version.

If I get a chance today, I’ll see if I can accumulate any additional data about the apparent problem, but I think I’ve already provided all the useful information that I can.

Thanks for taking a look at this issue–much appreciated.

I am the grid-numbering guy; but I cannot promise to fix it short of V 3.2.

I will keep you posted, though I don’t have too much time tonight to check it out.


I’m sorry to resurrect an old thread, but I originated this one with v3.1.17 and the problem is still present in v3.2.12.

I have tried to create a rectangular grid with an a vertical axis of alphas, listed first, then a horizontal axis with numbers (L-00, L-01, L02, etc.). I create the grid, set up the grid numbering, declare the starting alpha / number for each axis, and click OK.

When I return later to view the grid, the numbering does not start with “L” and the numbers do not start with “00”. What I see is something like “S-39”. When I try to move the grid so that I decrease the numbers or letters to the right spot, they never decrement. As soon as “S” disappears off the top, the “R” row instantly changed back to “S” again, so I make no headway. The same thing happens with the numbers as I try to decrement them–they revert back to where they started once they scroll off the edge of the grid.

This has happened in more than one module, so I don’t think buildfile corruption is the issue. To get around this, I am required to dump grid numbering altogether and rely solely on triggers that recognize irregular grids and region names. While this works most of the time, it’s not helpful and takes more time/effort in some cases.

Could someone please take another look at this? The work-arounds are killing me. Thanks!

It sounds like you are trying to adjust the grid numbering parameters using the arrow keys in the visual grid editor?

This editor only adjusts the size and position of the grid, it has no effect whatsoever on any parameters in the grid numbering. These can only be changed by opening up the Grid Numbering component and manually changing the values in there.

The fact that the grid numbering appears to change as you move the grid about or resize it is only by chance as vassal tries to apply the fixed Grid Numbering parameters to grid that has changed size and/or location.

The fact that the numbering doesn’t start where you expect is usually due to using grids with zones, or because the direction of the grid numbering (up/down, left/right) is not the default. The grid numbering starts from the board corner regardless of the position of the zone and numberings will change wildly if you change the numbering direction… You have to manually adjust the starting grid number in the Grid numbering then look at the grid again and repeat until you get the Vassal grid to report the same as the map grid.


Hello and thanks for the reply.

Yes, I have a Rectangular Grid inside a Zone, as some pieces must be sent to areas inside the Zone but outside the grid, subsequently reporting their status as such. While I don’t absolutely have to list the vertical axis first with a letter and horizontal second with a descending number, it makes Property / Marker assignment and Prototype construction easier and more intuitive to remember.

As for your explanation, let me see if I have this correct:

  1. If I have a Grid inside a Zone, and that Zone is in the middle of the Map, then setting up the grid to start at L-00 is a losing proposition from the beginning, especially if you want the vertical axis first and descending numbers, as the interface freaks out in this case.

  2. Because all grid numbering on the Map is calculated from the upper left-hand corner of the Map, there is no way to know what letters/numbers you will really see in the aforementioned Grid/Zone without going into the visual editor, because what you enter into the grid numbering menu is not what you will get.

  3. The only way to create custom numbering in a zone-embedded grid is to repeatedly go back and forth between the grid numbering menu and the visual editor, inputing “offset” combinations of numbering until you happen across the correct combination of letters/numbers that displays the correct grid numbers on the map.

If my understanding above is correct, then grid numbering seems even more broken than I first thought and makes no sense at all.

Why should the module programmer be required to go back and forth multiple times entering non-intuitive information into the interface to create an “adapter” for a data model that has already been built? This seems to defy the fundimental tenants of good interface/program design. Wouldn’t it make more sense for the “conversion” of the input to happen behind the scenes as part of the code? Also, if changing the default numbering scheme (switching which axis is first, using descending numbering, etc.) freaks out the program, doesn’t that constitute a bug, especially if it’s been this way since at least 3.1.17? At the very least, shouldn’t the ability to change the axis/numbering direction options be removed temporarily if it’s going to cause significant issues with module data?

I’m sorry, folks, but this is really disappointing. I have several modules based on zone-embedded grids and reworking all these modules is going to take hours. Had I known that grid numbering was this convoluted and non-intuitive, I would have developed a work-around well before now. As it is, I have many long nights ahead of me.

Brent, is there something that I’m missing in all this as to why grid numbering must be configured this way? This has been a really frustrating experinece, but I’m willing to admit that I don’t have all the facts.

Some additional things may be useful in following Brent Easton’s helpful reply from July 8, 2014.
This isn’t just for Numbered Grids reverting to default values, but for any misnumbering.

  1. The changes are made on the Properties window for Grid Numbering.
  2. The very last entry in these properties is a check box called “Odd-numbered rows numbered higher?” If every other row
    has numbers off by 1, or if the difference between desired and actual numbering is off by 1 in every other row: you should
    change this check box.
  3. Once #2 is taken care of try adjusting the “Starting number in vertical:” and the one for horizontal by the difference
    between actual and desired numbers. If actual is lower, raise the starting number, etc.
    In other words: (new value)=(old value)+(desired value)-(current value)

Probably the help files should include something about this. I found Brent’s post with Google, but I may have been lucky
or unreasonably persistent.