New error in 3.6.7 - Unimplemented binary string operator

I found something than seems a bug upgrading from 3.6.6. To 3.6.7.

I have a piece with these traits:
Calculated property A: 10
Calculated property B: 0.5
Calculated property Res: A*B

I get this error in the error.log

VASSAL.tools.ErrorDialog - Piece: Trait: Calculated Property - Res - Res Source: {AB} Error: Expression evaluation error. See the errorlog for more details.
Expression Audit:
Source type=Piece Trait
Source name=Piece:
Source description=Trait: Calculated Property - Res - Res
Source field=Expression
Source Expression={A
B}
A=10
B=0.5
Error=internal Error: Unimplemented binary String operator

More info:
The same module was ok with Vassal 3.6.6.
If B is =1 or >1 there is no issue ( for ex. A=10, B=1.5, Res = 15.0).

Can someone help me?
Thanks.

Source expression {AB}, should not that be {A * B}?
We are also experiencing the leading 0 bug. 100*5/10 will work.

This is an unintended side effect of a change to allow leading zeros to be preserved. It is already fixed for 3.6.8 (that change now requires opting in); 3.6.8 should be released soon. If you need an immediate fix you can either revert to 3.6.6 or download a 3.6.8 snapshot (I forget exactly where to find them off the top of my head)…(edit:)or, use pald0n’s suggested change.

Edit: When pasting error logs, it’s best to put a line containing only three tic-marks (```) before and after the error log text, to avoid having the forum software read special characters (like *) as formatting codes.

If the 0.5 is a constant property or part of an expression, then using .5 instead should also work in 3.6.7

Does someone know the exact 3.6.8 Snapshot so I can download and test? I just opened my module in 3.6.7 and it crashes and burns horrifically at startup. 5 Bad Data in Module errors: 3 “Possible infinite loop” and 2 “Expression evaluation error”. My guess is the leading zero bug but I’d like to confirm…

The latest master will have the fix in.

I installed VASSAL-3.6.8-SNAPSHOT-ea5a93f-master-windows-x86_64.exe and all the errors still occurred. Is that the latest master you were referring to? If so, perhaps this is a different issue. I’m starting to think it might be because I noticed the changelog referring to “11330: Allow .toString() to be called properly on property names in Beanshell” and every error reported is by an Integer.toString function…

1 Like

I am extremely puzzled as to why you’re using Integer.toString() in the first place. What is (Integer.toString(GetProperty(Capital+"_Units")+0).replace("0","").length()<2) supposed to be checking, anyway? It seems to be checking to see if Capital+"_Units" has less than 2 non-zero digits?

In any case, I suggest you turn on Audit Trails as the error message suggests and then post the new error log (preferably as text between two lines of three back-tics (`), not as a screen capture that’s almost impossible to read.)

E.g.,
```
error log paste
```

Edit: It looks like you’re using multiple workarounds to try to avoid errors from the CP being calculated before the referenced properties are initialized. That should not be necessary in current versions of VASSAL (CPs are now disabled if the piece only “exists” in the piece palette). Or am I misunderstanding what you’re doing there?

I believe you should be able to simplify that mess down to GetProperty(Capital+"_Units").replace("0","").length()<2?keep this bit the same:Default

Might possibly need to use GetString(Capital+"_Units") instead of GetProperty to allow the .replace() method to work…

1 Like

I’ve assigned a GP (AreaName_Units) to each area that reports the number of units present for each faction. I use it to determine if an area is vacant, contested, or controlled, if so, controlled by whom. The number of non-zero digits in that string is very meaningful. 0 non-zeros means its vacant. 1 non-zero means its controlled by one faction. 2 or more non-zeros means it’s contested.

This is a stable module so I’d prefer not to start rewriting all those expressions. They are used hundreds of times. My module has a level of automation that I now regret as it breaks with almost every new release. But what’s done is done. Anyway, I’ll wait for one of the developers to chime in as I’ve sent the module to look into these issues several times now and they’ve always been responsive and helpful.

A post was split to a new topic: Errors installing 3.6.7