I just spent hours, literally hours banging my head against the wall trying to debug a fairly simple problem:
Some pieces set a Global Property “Suit” to whatever their Marker value for “SetSuit” is (Hearth favor, Nomad favor, Beast favor, Arcane favor, Discord favor, or Order favor) when moved to a subset of Zones that have the Global Property.
A global key command tells all “Favor” pieces with a matching expression Suit=~“Hearth favor|Nomad favor|Beast favor|Arcane favor|Discord favor|Order favor” to do a thing.
Every Favor piece in an appropriate zone did the thing, except Favor pieces in zones with “Order favor” as the Suit.
I debugged for hours, going round in circles checking and rechecking. Eventually I tried changing the matching expression to Suit=~“Hearth favor|Nomad favor|Beast favor|Arcane favor|Discord favor|Order favor|Order favor” or in other words I just added an additional Order favor to the possible matches.
As soon as I did this, the global key command worked on every target Favor piece as intended.
Rechecking, reverting the matching expression to Suit=~“Hearth favor|Nomad favor|Beast favor|Arcane favor|Discord favor|Order favor” and again the global key commend stops working for Favor in zones with “Order favor” as the Suit value.
Can anyone explain this? It makes no sense to me. It is not a typo problem.
You could add another “bogus” suit on the end after Order favor, to transfer the bug to that “extra suit” and have all your other ones match? Oh right, it looks like that’s what you did.
Or, what I often do is bypass the whole regular expression fussiness with: “Your|String|Of|Things”.contains(Suit) which would work for your case.
No, that doesn’t work for any of the suits. Is that use of brackets correct? Or is this highlighting the fact that if it’s the last expression bugging out, this rewriting makes all them the “last” expression?
Thanks. This seems to work, but I don’t understand why.
It also introduces a new bug, I suspect because the gkc condition now also affects other pieces resulting in a “Bad data” report where some pieces targeted by the gkc don’t have a Suit value for a Send to destination. Maybe there are already in Zones that do not have a “Suit” value, but do correspond to “Your|String|Of|Things”? I assume I can fix that by giving those Zones a Suit value, but it does seem like a problem if .contains() regularly picks up stuff that the original regular expression is not supposed to.
It worries me that people are circumventing regular expressions as a matter of course. Is this a common source of very difficult to detect bugs? I use them all the time, and some of my modules are riddled with them.
It seems that the problem might lie in how I was using the new gkc UI. Previously, my expressions were consistently wrapped in beanshell brackets {}
The new interface, with the expressions split into two either side of =~ in a dropdown menu, seems to make {} unnecessary, or at least, impossible to use with fast matching.
When I don’t use fast matching, and write {Suit=~“Hearth favor|Nomad favor|Beast favor|Arcane favor|Discord favor|Order favor”}, the expression seems to work correctly, while Suit=~“Hearth favor|Nomad favor|Beast favor|Arcane favor|Discord favor|Order favor” does not (only for “Order”). Further, {Suit =~ “(Hearth|Nomad|Beast|Arcane|Discord|Order) favor”} also works only with the beanshell wrapper.
I should clarify: I meant that because the fast matching doesn’t show a {} wrapper, I wasn’t using them in the additional property field either. So, my fault. I haven’t tried fast matching with the problem regular expression yet.
This is working for me in a legacy Fast Match comparison
BasicName
=~
(Target|Retire|Stand)
It did not work until I enclosed the RegEx in the round brackets. I’m guessing that is a RegEx thing.
Re: Beanshell - Fast Match seems to strip out redundant {} and “”, converting the expression back to a legacy one. On the other hand, with something like {"(Target|Retire|Stand)"+"|XXX"} the beanshell expression will persist and, presumably, work.
I ran into this when parsing through a list of nations in a Send To trait and used .contains to solve. Some pieces did not have, or need, the Country trait. I had to add it to any that might receive this trait. It often showed as a null.