Please download the module: dropbox.com/s/a21tqgqw3xyz5d8/1D.vmod?dl=0
It seems that VASSAL interprets properties named “1D”, “1F” as Java types and would not read their values through GetProperty.
In the aforementioned module Counter 1A is appropriately labelled with value of GP 1A read through GetProperty and passed to TextLabel. When value is changed, so is the label. For pieces named 1D and 1F, even though corresponding GP have been defined, the label won’t show up.
Thanks for the report.
I think I have an idea on what the problem may be. Interestingly, “1D” and “1F” can bother be interpreted as numbers by Java. They represent 1 as a double type and as a floating type.
Are you trying to apply any String function to the values returned from the Global Property? Like .contains() or .substring()? If so, you will need to GetProperty(gp).toString().contains(‘x’) instead.
This is a limitation of the interface between Vassal and Beanshell where anything that looks like a number gets returned as a number. We are planning to add the function GetString(“propName”), which will be a short-hand for GetPropert(“propName”).toString() and also to add the .toString() function to the Expression builder (This is already usable). However, it will be up to you to decide whether or not you need to use GetProperty() or GetString().
Regards,
brent.
Cheers, Brent.
Here is my use case.
This is game Ici, c’est la France that we are talking about.
In this game map is divided into large regions wilayas. Wilayas are numbered 1 to 7. Each wilaya is divided into regions, these regions are named with a letters so in wilaya 1 you would have regions 1A, 1B, 1C and 1D.
I am tracking each region Allegiance and SupportLevel. For each region I created corresponding properties 1AAllegiance and 1ASupportLevel.
On the map, in each region, there is a unmovable piece that shows region Allegiance and SupportLevel. I made Prototypes for these, like there is a TextLabel reads value of calculated property (as far as I know you can’t pass value of GlobalProperty to TL but regardless). CalculatedProperty is defined as GetProperty($BasicName$+“Allegiance”). Each unmovable piece has a BasicName set to 1A, 1B… that corresponds with a region it is placed in.
The above setup works for 1A, 1B and 1C but failt to work for 1D i.e. the marker will not show TextLabel.
For starters, don’t do this. Use GetProperty(BasicName+“Allegiance”)
Where did you get the idea you needed to use $'s here? You should not use $propertyName$ inside the {} Beanshell braces except in the very specific case of a GKC Property Match Expression where you want the $propertyName$ to be evaluated on the source piece prior to executing the GKC.
This use case should not be affected by issues I noted earlier.
What happens if you just type $1DAllegiance$ in as the label text? I don’t see why you would need a GetProperty call.
Regards,
Brent.
Ok, have reproduced what you describe, there is something weird going on. Investigating.
The problem is as I first thought. Some strings are recognised as Java numeric literals and are being converted as such by the Vassal to Beanshell interface, which causes your property lookup to fail.
1D and 1F are both converted to “1.0”. 1L would be converted to “L”.
I am working in a fix to prevent this behaviour. I don’t believe there is any reason this would be wanted in Vassal. Should have a fix for v3.4.1 which will be released soon.
Regards.
Thanks for this, Brent.
Proper use of $ remains a mystery to me. As a rule of thumb I don’t things if they work in a fear of breaking them… As it worked for other cases, I let it be.