(Assuming I’m correct), the problem is one of unintended consequences–before 3.6.7, VASSAL used to automatically drop leading zeros from property values (so, 0101 become just 101). However, sometimes module designers wanted to keep the leading zero, because they were reporting hex locations, not integers (it just looks wrong saying something is in hex 101 instead of hex 0101, and that also broke Send to Location). In order to allow for that, a change was made so that any property value that starts with a zero, unless it is exactly 0 and nothing else, is no longer automatically converted to a number when referenced.
Unfortunately, VASSAL doesn’t really support decimal numbers (as you’ve realized, you can use them, but you run into situations like this)–since the string 0.25 starts with a leading zero, VASSAL is now assuming the leading zero needs to be preserved, and so refusing to automatically convert it to a number.
Another possible fix might be to use scientific notation for your decimals, e.g. 2.5e-1 for 0.25. I have no idea if that will actually work or not.
Actually, I’ve looked at the BP counters and noticed I’ve used whole numbers, dividing by 100 when I need to. The DoD BP counters are unique in that the PM may change at any time, not based on the game year.
I believe that if I set up 8 new GPs, named xxxpmlookup, populate them with a long (not ticked as an integer) number (for ex China PM ‘number’ would be 005025050075100125150). Using the instring function can extract the required 3 ‘digits’ that can then be happily used in those expressions divided by 100. I then set up a DP in the PM counters to ask players if they want the PM to increase or decrease (latter in case of inadvertent increase).
Interesting idea re scientific notation, but, like yourself, would it work? Wonder the expression builder (green tick) would ‘say’.
I forgot to mention, the reason the errors are showing up in the text labels is because the default setting for a text label is to change the PieceName to $pieceName$ ($label$) (IIRC), meaning it adds the value of the label to the previous PieceName. This means that an error in the calculation for the label also causes an error in the calculation of the piece’s actual name. You can avoid this by removing the ($label$) part from the Name format field.
This string/float switch for handling of Property values gave me the same issues.
I eventually found that using a {Float.parseFloat(GetString(“PropertyName”))} construct every time I accessed a Property worked for me. (It’s amazing what you learn when you browse through the Release Notes.)
On the positive side, my other module I’m working on, which has lots of hex references, should be a lot smoother now.
There are many, many text labels. Groan.
How about the Default text label trait starts with no entries in any of the various fields. Fancy having a default entry that can lead to errors as a result of another error somewhere else. That is not a good concept - an accident looking for a place to happen.
I think I’ll be using notepad++ to do that editing. I hope it can do a global replace of ’ ($label$)’
Had a horrible thought. I’m still using leading zeros in those GPs. Rethink necessary.
As of VASSAL 3.6.7, leading zeros are actually OK (except for the weird case of decimal numbers between 0 and 1, which is causing your new error); they are now preserved. Once 3.6.8 is released, you may need to change a Global Option for leading zeros to continue to be preserved.
Fine. Now I’m getting some really weird stuff. A CP is supposed to give its result straight away?
Now can someone explain this:
Similar coloured arrow point to the same thing. So why is not $bpscalculate$ being calculated and thus displayed? The chinaxxxx are GPs, oilsave and unfacts are currently 0. They work as equations in the text labels (using {}), nothing works in the CP. Even just putting chinablue in the CP does nothing (chinablue been selected from the available GPs)
But it does work when placed on a map in a game. Is it because CPs are not processed from within the editor mode?
CPs are not calculated for pieces in the game piece palette, no (too easy to cause a calculation error, as they might try referencing properties that only exist once the piece is actually on the board).
1 Like
OK. Seems to working again. No infinite loops, etc. I do wonder though how many other modules may be affected.
1 Like
