I’ve also tried omitting the $$, but still get the error…
CHAT LOG -
Bad Data in Module: Expression evaluation error Expression={Neutral =~ “Neutral”|“PERM Neutral”}, Error= inline evaluation of: ``_xyzzy=_plugh();’’ internal Error: Unimplemented binary String operator
I used the expression builder to help construct this and it showed the “green check” as a valid expression…
It’s possible I’m using improper syntax, but from what I can tell in the Designer’s Guide and the expression builder validation, I don’t see why it doesn’t work unless it’s a bug…
I don’t like the look of those quotation marks. Also, I’ve found enclosing this type of RegEx in rounded brackets may be required (not 100% sure about that).
Try:
{$StatusFinland$ =~ (Neutral|PERM Neutral)}
if that bombs, try
{$StatusFinland$ =~ “(Neutral|PERM Neutral)”}
Hope that helps. I’m only just getting to grips with RegEx myself.
{$StatusFinland$ =~ “Neutral|PERM Neutral”} → a single set of quotes around the entire IS IN template.
I also avoid use of the $ in Beanshell statements unless the expression clearly will not work without them. I think it (or maybe me) can get confused by the mix of original expression rules and the new (Beanshell) expression rules. It does depend a bit on what kind of property StatusFinland is.
I would have written:
{StatusFinland =~ “Neutral|PERM Neutral”}
A Regular Expression used by =~ is always a single quoted string.
Rules of using $$ variables in GKCs:
Rule 1: If the GKC is not a Counter Global Key Command, do NOTuse $$ variables
Rule 2: If the field is notthe Additional Matching Properties field, do NOTuse $$ variables
Rule 3: Unless the $$ variable references a property available to the piece that issues the GKC that you want to compare the value in each piece the GKC is applied to, do NOT use $$ variables. Use a Trigger Action to prevent the GKC being called in the first place.
Rule 4: If $$ variables are used inside a Beanshell expression, enclose them in double "s
Rule 5: Always check the back seat
So {StatusFinland =~ “Neutral|PERM Neutral”} means check if your target pieces are Neutral
{"$StatusFinland$" =~ “Neutral|PERM Neutral”} means check if your calling piece is Neutral, but this is very inefficient, as you are processing every piece on the map, then checking something on your source piece to decide whether or not to apply the GKC to the target piece. Use a Trigger Action on the source piece to prevent the GKC being fired unless the piece is neutral.
{"$StatusFinland$" == StatusFinland} Something like this is a valid use of $$ variables, checking if the StatusFinland in the target piece is the same as StatusFinland in the source piece.
PS. You might get away without rule 5, but be careful out there!
As an aside, if you’re using a regular expression anyway, it would probably be more efficient just to check if StatusFinland ended in “Neutral”, rather than specifically checking for “Neutral” or “PERM Neutral” (unless, of course, there are other forms of Neutral that should not count). You can do that with {StatusFinland =~ “.*Neutral”} (the “.” means “any character”, and the “*” means repeat the last character any number of times, including 0 times, so the final result is a string that has any number of any characters followed by “Neutral”).
Edit: Another possibility is the Java string function “contains()”, but I’m not positive if that works in BeanShell or not (Brent would know!): {StatusFinland.contains(“Neutral”)}.
It might be helpful to add some of Brent’s 5 rules to the Designer’s Guide, as this was really unclear when I was trying to do it… Also Brent’s rule #3 (inefficiency of using $property$ on left side) conflicts with the Designers Guide, which says to do it that way (see below). Also suggest adding an additional example with properties that use strings, since it was confusing…
A regular expression checks if a Property has any one of several values. A regular expression is
denoted using the =~ operator. Surround the name of the Property on the left side with $-signs, and
separate each value by a pipe character (|). There must be no spaces between pipe-separated
values. For example:
CurrentPlayer =~ Blue|Green|Red (checks if the Blue, Green or Red player is the current player)
I actually considered the “A|B” construct, but thought that it would interpret the pipe character as a literal part of the string… Which brings up the interesting question…
If you are using a regular expression AND one of the strings contains the pipe character, would you use the “|” construct?
A = blah
B = he||
My point is not that using $property$ on the left side is inefficient, but that it is pointless to use a $property$ in a GKC property expression at all if you are not comparing it to a property on the target counter. {“Division” == “$unitType$”} is just as bad.
That text you quote is way out of date and looks to be pre-Beanshell and talking about old-style expressions when any $property$ values HAD to be on the left hand side.