Strange behaviour from a Trigger Action - please help.

Hi,

I’m really stumped by the strange behaviour of a Trigger Action. I would be grateful if anyone could help out.

I’m building a module for an air game. Counters represent individual aircraft and it uses a hex grid. I’ve programmed 3 keys with basic moves - forward 1 hex, rotate left 60 degrees & rotate right 60 degrees. So far so good, the commands work correctly for any orientation of the counters and I can move my aircraft around the map using these basic moves.

But now I want to build more complicated manoeuvres by combining 2 or more of the basic moves in Trigger Actions which I can then invoke with a single keypress. For example, a ‘Right Turn’ will consist of 3 basic commands; forward 1 hex + forward 1 hex + rotate right 60 degrees. And a ‘Tight Right Turn’ will consist of 2 basic commands; forward 1 hex + rotate right 60 degrees.

The problem is the ‘Right Turn’ Trigger Action does not work correctly - it does not move the counter correctly unless the counter begins upright. In all other orientations it moves the counter into the wrong hex or does not move it at all. The really baffling thing is the ‘Tight Right Turn’ Trigger Action works perfectly.

In this screenshot the plane on the left shows what should happen if you turn a full circle by executing 6 ‘Right Turn’ TAs. The plane on the right shows what actually happens.
[attachment=0]demo.jpg[/attachment]

I think it must have to do with the ‘Can Rotate’ trait but I’ve spent most of today trying all kinds of variations without any success.

I have a cut-down version of the module demonstrating the problem but its still too big to be attached here (its 890k). Here is a Dropbox link:-

https://www.dropbox.com/s/yy8vgyng07o66sv/MTest_0.1.vmod?dl=0

Can someone please take a look at this?

Thank you.

Ian.

My system:
AMD Athlon II 630 (4 cores), 4 GB RAM, Linux Mint 17.3, Java - 1.7.0_151, OpenJDK Runtime - IcedTea 2.6.11, VASSAL 3.2.17.

I have been having some problems with triggers myself (when use to create composite commands), so I messed around with your test module.

First off, you should do some things, which I did, to put more light on the matter. In your hex grid, right click it and create hex labels–and print them on the map. Big help. Second, insert reports in your piece to report locations associated with your ctrl-L et. al. commands.

When I did this, I discovered some oddities. The big one for my problem is Vassal doesn’t update a piece’s current location until it completely finishes a trigger. For example, if the trigger moves it from location X to Y, each discrete command in the trigger will report it as being in its starting location X. This answers why my trigger problems occur and is a very unfortunate “feature.”

But that doesn’t help you. Here’s what I found for you. I created another trigger command for your piece that advances it forward twice with no turns. When I executed that command, the plane would only fly 2 hexes due east, west, north, or south. Never NE, SE, NW, or SW. Another “feature.”

It appears to me that triggers have several side effects that makes them risky and unpredictable.

shilinski - thanks for your efforts and the quick reply. I will follow up on your advice and investigate further. I hope I can work around this or it might scupper my plans for this module.

Ian.

shilinski - thanks for your assistance.

Your suggestion to log moves to the chat was very useful. It showed that there was a serious problem with the TAs I was using but it also pointed me to a possible work around.

The problem appears when more than one ‘Move Fixed Distance’ command is used in a TA. The second and subsequent move commands are executed incorrectly, sending the counter to the wrong location. I have lots more test results which I can provide if any of the VASSAL engine authors are interested.

For now I will try to rewrite my TAs using only one move command each. It will be more work but it should be possible.

Ian.

Trigger actions are the most wonderful things in Vassal because we can create small, discrete commands, bundle them into one package, and execute the lot with one keystroke. The trouble is triggers don’t always work as expected. I can test my small, discrete commands one at a time, and they work perfectly, but when I put them into a trigger, I often end up in a what-the-hell?! moment. I’ve wasted HOURS debugging them. (I’m writing a longer explanation for anyone who stumbles upon this thread after wasting hours fooling with a trigger.)

I think any reasonable person would expect a trigger, which invokes a list of commands in order, to do the first command to completion, then the second one, and so forth. Well, this is NOT what it does, especially when it involves commands that move pieces. Here’s an example.

I have a command that shifts all pieces on the map 200 pixels to the left (shiftLeft).
I have a second command that looks for any pieces at region R0 and flips them over (flipR0).

I put them into a trigger to invoke shiftLeft followed by flipR0 expecting the flip at R0 to happen after all pieces have shifted. I would be wrong.

What happens is a trigger won’t update a piece’s movement state until the trigger completely finishes. CurrentLocation, CurrentX, CurrentY and probably others do NOT update after a piece moves–in my case after shiftLeft, so when I do flipR0, I am only flipping over pieces that STARTED at R0, not any that finished there.

So writing a command that depends on the state left by the previous command is very suspect. In your case, you wanted to move (shift) an airplane two hexes NE, but the trigger put it in some bizarre space. I have no idea what happened there. I know triggers don’t respect a pieces state with moves; I don’t know what it does to other commands like rotate and mask.

I tinkered some more with your module. (I recently fought with my own triggers, and yours was small so I could test things easier.) I found if I didn’t put more than one command in a trigger that moves pieces, then I could get it to work. It meant I couldn’t put “move, move, rotate” in a trigger. It had to be “move 2, rotate.” You seem to have discovered this yourself.

This is one nasty bug.

Could you simply separate the the move into 3 triggers that are sorted in order by the moves you want to make? That way each trigger is only doing one function of the composite move?

I’ve thought of this (and tried it), but it works only if there is one path of commands.

Suppose I have an airplane piece. I implement a bunch of discrete, independent commands to go straight 1 space, turn left, turn right, etc. When I right-click it, I have a choice of number of airplane maneuvers. I choose “go straight 1 space, turn left, go straight 1 space” from a list of similar maneuvers.

The logical way to do this is to implement a trigger that executes in sequence “straight, left, straight.” (BTW, this won’t work because of trigger’s limitations.)

To implement trigger “listeners” as you suggest, when the plane executes “straight,” it would have to know what to do next—left, right, straight, etc. Triggers don’t implement if-then-else, so implementing this becomes very complicated and impractical. And it may not be possible, I don’t know. I could go on explaining the logic, but I suggest doing it yourself.

I was thinking more for things like wing overs or Immelmanns etc where you assign a key to the move then use that key to drive the triggers to execute it one hex/turn at a time.