after 10 (10! ) hours of test, trials, forum search and bad mouthing i’m almost sure that this is a bug… but being my first approach to Vassal i can be wrong, so please don’t shoot at me if i’m just making a mistake.
I attach a very tiny module, where a car can do 2 moves: forward, and pivot.
There’s also a Trigger that fires the two moves in that order, and that show a wrong result.
The last Triggered move is inverted (first pivot, the forward) and it works well.
Seems to me that, in the Forward → Pivot Trigger, the Pivot command always goes first (which is not correct), but it does not update the counter angle, so the forward move goes in the starting direction, and finally the counter is rotated by the angle specified in the Pivot… a big mess, in the end.
And that post confuses me instead of make things clear, 'cause as the Can Rotate need to be “declared” AFTER the labels (as example) to make them rotate, it must be also declared BEFORE the Can Pivot or the Move Fixed Distance traits, or they will not “rotate”.
To me, it should work in a unique manner, so to allow rotations Can Rotate should be at the very top or at the last posistion of a trait list, but there’s must be technical reasons to make Can Rotate as it is so i’m not really complaining about it.
The ‘Moved Fixed Distance’ (MFD) trait is a problem child. It has special code included that results in the move being performed in a seperate thread. This causes a couple problems:
MFD does not combine properly with other commands in Triggers, the MFD always ends up getting performed last.
Extra Commands are generated that result in multiple undo’s being required to undo a MFD.
The special code was added years ago to handle the case of a single control key issuing MFD commands. The special code combines them all and produces a single move command for the entire distance. The original problem had to do with the counter merging with other counters at the intermediate points.
My feeling is the special move code is an overkill that has caused more problems than it originally fixed. I would like to go back to the MFD acting as you would expect, move the counter a set distance and have it happen immediately.
What I don’t know is how this will affect existing modules.
One solution will be to add a new option to the MFD trait ‘Run moves instantly?’ (better wording someone please!), when selected will run the MFD’s instantly one at a time and should solved both the Trigger issue and the extra Commands issue. This new option will default to TRUE in newly created MFD traits, but will remain FALSE in existing traits to allow existing modules to work unchanged.
Thoughts please…
I will put this down as an Enhancement request for 3.2 rather than a bug. If I get it working soon and it looks good, we could possibly look at including it also in the next 3.1.x release.
About the solution, do you really think that someone have build a module using the bug as a “feature”? I can’t see how it can happens, but i’ve not enough knowledge to have a valuable opinion.
Meanwhile… any workaround?
I’ve tryed using the Place Marker trait, 'cause it can fire a keystroke after (so it seemed to me a good way to make a chain of keystrokes) but it did not work…
edit:
why not just add a “correct” MFD as a new trait, and declare the OLD “deprecated”?
uhm… i may have been not clear enough: i meant a workaround to obtain my move, not for the code. i can accept a non-elegant, non-standard way to chain 2 commands or to “teleport” a counter somewhere that works in a Trigger, while the MFD get fixed… 'cause if a trait is bugged, it should be fixed anyway, right?
Again, sorry for not being clear. With “deprecated” i meant that the module maker will see somewhat like “Why are you still using this?” in the MFD dialog titlebar, just to make him aware that’s the MFD trait is still here for compatibility reasons, and not to be used.
Hmm. Would that problem still happen if MFDs were not combined?
My preference would be to eliminate the old behavior, since doing MFDs
on a background thread is itself a bug, as it means affecting Swing
components off the EDT. (And it will continue to be a bug until we have
proper model-view separation… Augh, so many months behind where I was
plannint to be at this point.)
) hours of test, trials, forum search and bad mouthing i’m almost sure that this is a bug… but being my first approach to Vassal i can be wrong, so please don’t shoot at me if i’m just making a mistake.
