The 18xx style grid notation reporting I developed in 3.6.5 does not work in 3.6.7. I tried it in 3.6.6, and it seems to work there.
Here is a link to a sample module using it:
Edit: Changed link to version which now works:
The part that no longer works is the Location format in the Grid Numbering of the Main Map.
In 3.6.7 the chat log says this when I place a number 3 tile in hex C4:
SampleTilesOnMap version 0.005
Bad Data in Module: Source: {column+((2*row)-((“ABCDEFGHIJKLMNOPQRSTUVWXYZ”).indexOf(column)%2))} Error: Expression evaluation error. Turn on the Audit Trail preference to generate more details in the errorlog.
TrackTile3 moves Tile_3 → *
TrackTile3 placed in facing SW
When I tried to re-install 3.6.6 I got this error:
So in 3.6.5 placing the tile in hex C4 generates this chat log:
SampleTilesOnMap version 0.005
TrackTile3 moves Tile_3 → C4 *
TrackTile3 placed in C4 facing SW
This is what I expect in the chat log from that action (working correctly)
This is the specific reason for the Unimplemented binary String operator error, the column variable has a value of “C” which is causing the arithmetical expression to fail.
D’oh! Don’t know how I missed that. I don’t understand how that expression could have ever worked.
Edit: Nevermind, I think the idea was to end with the string “C4” as the result–in other words, the initial + is supposed to be adding a string to an integer and resulting in a string (which apparently it did before 3.6.7).
Would adding .toString() after the last closing parenthesis fix it?
Hmmm. Actually, that should work. If the first argument of + is a string, Beanshell should try and coerce the second argument into being a string as well.
Ah, I know what it is.
We did make a change where Strings commencing with “0” are internally stored as Strings, even if they look like an integer so that the leading “0” is not lost. These tend to only be created by HexGridNumberings and the leading “0” is significant when reporting. So in your case, you will need to convert row to and Integer before multiplying it by 2. This is a bit painful, but it is the only way we can keep the significant leading 0.
So, to summarize, the failure is actually with the 2*row part of the equation, because VASSAL is now refusing to automatically convert “02” to an Integer, because of the leading zero. The solution is to change 2*row to 2*Integer.parseInt(row).
There is a way to make this work in all cases, but it would require significant surgery on the Beanshell Interpreter and a significant run-time overhead for every arithmetic operator applied to two strings, or a String and an Integer, of first re-checking whether both are actually numbers and doing the numerical operation instead. I considered that this would likely impose an unacceptable performance hit.
Hmm. Might want to rethink that, as we now know that change broke at least 1 module (admittedly, I think @pawnpusher only just added that feature to the module, but there’s no reason someone else couldn’t have already been doing math with numbers with leading zeros).
How many complex modules will become unacceptably slow if the change is added so that one module (that we know of) can keep working unchanged using the old buggy behavior? Using Hex co-ordinates for any meaningful arithmetic is pretty esoteric. I would not have touched this except that the existing behavior was demonstrably bugged and correctly using Hex-coords with leading zeros in several different areas was impossible.
If this does turn out to be a wider problem, then I will consider adding a Compatibility option ‘Hex row/columns with leading zeros are numbers, not strings?’ Y/N
Well, another use of hex coordinates in meaningful arithmetic was demonstrated in another thread we both participated in recently, where Palad0n was trying to find the distance moved by a piece. I suppose that was still fresh in my mind as a possible example.
Hmmm, this will potentially affect arithmetic on Square grid co-ordinates as well which is far more likely to have been used in the past.
Perhaps a better solution is to add a Global Option (i.e. can be set by the Module Designer) to opt-in to the ‘Convert numbers with leading zeros to strings’ behaviour. Then only modules that require that behaviour will need to be updated. And add some text to the Grid Numbering reference manual page about it.
For the benefit of those who need the leading zeros in their hex designations (numbers), I will gladly add the conversion of the numeric part to my grid designation conversion formula.