My triggers are getting grayed out when I don' think they should be

Technical Support & Bugs
1

I’m trying to implement an “if X else-if Y else if Z” construction using triggers. In my specific case, it looks something like this:
if (PlayerSide == “Red”) then do red stuff via ^T
else if (PlayerSide == “White”) then do white stuff via ^T
else if (PlayerSide == “Blue”) then do blue stuff via.^T.
So a player knows ^T does his stuff, and he doesn’t have to remember a different keystroke depending on which side he is playing. In practice, ^T sends a unit to a spot on the board and updates some global properties, but different for each player.

In Vassal, I use triggers, and in shorthand form, here’s what each one looks like:
Trigger. property-match {PlayerSide==“Red”} Menu-command=“Send to my tray”. Key-command=^T.
Trigger. property-match {PlayerSide==“White”} Menu-command=“Send to my tray”. Key-command=^T.
Trigger. property-match {PlayerSide==“Blue”} Menu-command=“Send to my tray”. Key-command=^T.
The performed key commands vary depending on the player side.

When I test it and right-click on the piece, I see that the menu command is grayed out much to my chagrin. I’m guessing that vassal is “helping” me because it sees two impossible cases, so it grays out the menu text. I note that if I wanted it grayed out, I could use the “restrict command” trait. I also note that ^T still works even if the menu text is grayed out. Is there any way to stop this “help”?

I found a workaround with a fake “facade” command. I created a dummy dynamic property (called “dummy”) with a single command ^T and with menu text “Send to my tray”. All it did was set dummy=0. Then I had all the triggers watch for ^T. This worked. “send to my tray” is not grayed out.

The trouble with this is the future me, who looks at this code, is going to think this me is an idiot. I’m going to have to write an apology and explanation to future me as to why I had to do this apparently stupid thing.

2

I don’t understand why you felt you needed a dummy Dynamic Property. Just use a 4th Trigger Action. This new Trigger Action has the Menu Command “Send to my tray” with a blank “Trigger when properties match” field and ^T as its Key Command; all it does is call the other 3 Trigger Actions, preferably using a Named Key Command. The original 3 Trigger Actions should then be altered to have no Menu Command and look for the Named Key Command the new TA is sending.

2 Likes
3

You’re right, of course. My first reaction was I needed a command that issued another command and nothing else, and I looked for the cheapest way to do it. A trigger is better because it’s more natural here and not as silly as what I did.

4

Why do you test for PlayerSide?
In this case, don’t you want the same response, no matter which Player? (“Menu-command=“Send to my tray”. Key-command=^T.”)

5

I have to test PlayerSide because the ^T trigger does a bunch of things and not just sending a piece to a single location. Each player has his own “tray,” and there are a few player-unique global properties involved.

I ended up using a master trigger as JRWatts suggested, whose only function was to provide menu text and the ^T command. Otherwise it did nothing. The PlayerSide ^Ts all just watched for ^T and did their thing if their PlayerSide check tested true.

1 Like