Expression Builder problems

Hit me with them :slight_smile:

I have already:

  • Added the java ternary if ( x==2 ? x+2 : 55 ) to the Function drop-down section
  • Improved the Function drop-down descriptions to show the parameter usage
  • Added a couple of treats.

Will be accompanied by a manual page re-vamp with additional examples.

Any other issues/bugs people have?

Ooh! Ooh! There’s a huge one –

In a Global Property trait, if you try to put the expression name as:

GetProperty(“CurrentZone”)

(Meaning of course you want it to read what’s in Current Zone and use that as the name of the Global Property to be modified)

Then it instead “helps” you by changing it to simply CurrentZone, which of course leads to disaster.

I have modules where I’m literally typing GetProperty(“Current” + “Zone”) into the box to avoid this problem.

I recently wrote this up as 12980 but I don’t think it has cleared moderation or whatever. vassalengine.org/tracker/sho … i?id=12980

How about this: https://forum.vassalengine.org/t/nested-getproperty-in-text-label/10666/1

One expression builder function that I suspect would be super-valuable to a lot of folks is something like…

ParseValue(String)

Where the value provided is parsed for any embedded numeric value (e.g. “Scoring Track 5” becomes 5), and if no numeric value is provided puts a 0 instead of e.g. throwing an exception.

Here is what I currently have to put to get a similar result:
Integer.parseInt(If(GetProperty(“LocationName”).replaceAll("[^0-9]","")=="",“0”,GetProperty(“LocationName”).replaceAll("[^0-9]","")))

And even THAT throws an exception (ironically) if the initial value of LocationName is ONLY a number (e.g. if LocationName is literally “5” it gets mad for some reason).

I guess a decision would be whether to include the minus sign too so that one could get negative numbers.

Obviously “5Q7Z0” would result in “570” in this case, but as odd as that is it’s still consistent and usable. Plus I mostly imagine this as useful to parse location/zone names for the myriad times in gaming that something has to move down a numbered track.

Brian

While I have no particular problem with adding additional BeanShell functions as they are relatively ‘cheap’ and harmless, in 20 years of module design I have never, ever had the need for such a function and I have created plenty of scoring tracks.

I wonder if you are making life unnecessarily difficult for yourself by including non-numeric information in the location names of score tracks? Presumably you are doing this for reporting reasons? I find it much easier if scoring tracks just return a number in LocationName and any reporting requirements are handled in the name of the score marker.

Instead of : Green moves Score Track 4 → Score Track 5
I have : Green Score moves 4 → 5

When I only have one track that’s not a problem, but every one of my game boards offer several different tracks, all numbered.

Not just reporting – I end up e.g. needing to:
(a) Figure out which square the player just dragged the marker to (“Scoring Track 5” as opposed to “Turn 7” or “Blockade 3” or “Amphibious Assault 4”). So that, among other things I can adjust the relevant Global Property to the right place.
(b) Or when an event card moves a marker (or player just hits the +/- key with the marker selected), I want to move the marker to the right place on the right track.
(c) And sure, when all is said and done it’s nice to be able to customize my reporting, but that’s the least of my concerns here.

Brian

Here is a significant one:

When a gamepiece issues a GKC to other pieces you can use a non-beanshell expression in the GKC matching properties to compare the value of properties in the issuing piece to the value of those same properties in the receiving pieces like this:

Matching Properties: Designator=$Designator$ && CurrentMap=$CurrentMap$

Pieces that have the same value in property Designator and are on the same map, as the piece issuing the GKC, will execute the GKC.

There is currently no way to handle this (comparing properties in the issuing piece to the same properties in the receiving pieces) in a beanshell expression – and it is very much needed.

Tom

Thanks Tom,

I had already identified this problem and have supplied a fix for it that will be included in the 3.3.1 betas (not 3.3.0). The matching Beanshell expression to your example would be:

{Designator=="$Designator$" && CurrentMap=="$CurrentMap$"}

This is described in the manual, but has never worked.

Regards.