I have Pieces that Return to a Deck that is at negative x-y coordinates on the Main Map. This leaves a movement trail that never goes away, even with a Global Key Command. The only was to remove the trail ever, is to use a Return to Deck on another Piece, sending it to the same Deck. This got me thinking that a wonky workaround was to create a hidden pile of dummy units and send one to that deck every time a Piece is returned. Low and behold, that works, but is there a more satisfying solution out there? I’d like to avoid having a giant pile of doppelgangers to match every real unit. I guess I could just create one unit and move it back and forth each trigger. Is there any other way to clear the movement trail? Or is there a way to suppress the trail entirely?
PS Any movement trails created by dragging and dropping units are cleared normally by my Global Key Command.
It turns out the behavior is not consistent and the trails are not always cleared. I did notice that no trail is created if you Return to Deck on a different map. The problem with that is I need to perform expression counting on those decks and for some inexplicable reason, that is only reported on the same map. So I either lose the expression counting ability or movement trails. That’s an easy choice. I’m starting to think that movement trails are non-functional if your module has any degree of automation.
So: first thing to remember is movement trails have a very clunky implementation as far as being able to do anything globally with them (as opposed to individually on a single piece), but it is possible. They’re not completely non-functional as you suggest, they’re merely almost non-functional!
Here are some facts/ideas from my long painful history with move trails:
(1) On a Map window there is an option to create a button to “Mark Unmoved”, which I usually rename to something easier to understand like “Clear Move History”. If you turn that on, it will clear movement history (trails) for all pieces when you do it. (But it will obnoxiously set those pieces’ trail on/off state back to the default they started the game with – it looks hopeful this bug may get fixed for 3.3.1, but in any event if you don’t care about trails getting continuously reset to their default state, then this button will work for you).
(2) On an individual piece you can add a “Mark when moved” trait, and this will allow you to clear an individual piece’s move history. (Obnoxiously it will put a blank line in your piece’s menu even if you leave the command text blank).
(3) If you move a piece to a different map (that has “mark moved” turned off), their history will be cleared. Since you just have a weird deck that nobody ever needs to see, then you could send them there. (I now see from your second message that you have discovered this but have found other problems – possibly you could return them FIRST, briefly, to the off-map deck and THEN to the on-map deck, and this would clear the move trail but then they’d come to rest in the deck where counting is working for you?)
(4) Empire of the Sun has a decent implementation of a pure-vanilla-vassal “global trails on/off” switch.
(5) For the People uses a custom class I wrote that lets me set a key to manually force trails “off” or “on” directly rather than have to “toggle” them and try to separately keep track of where I think the toggle state is. This makes life much easier when I want to provide a switch to let players turn trails on / off for all units at once.
Thanks. I’ll revisit at a future date. Maybe they’ll fix the bug by them. Non-functional was perhaps bad word choice, but if any random red lines get permanently stuck on the map, any added convenience of movement trails is more than offset by the destroyed aesthetic. I have to cut my losses though. I literally spent the entire day yesterday learning the hard way that reporting doesn’t work for deleting pieces and movement trails are broken. I’m back at the office next week so my carriage is turning into a pumpkin and I won’t have so much free time to program in Vassal anymore
To get reporting to work right for deleting pieces I do the following:
(1) Add an actual Delete trait, clear the command line text, and set the keystroke to “DoDelete”
(2) Add a Report trait, have it report on keystroke “ReportDelete”
(3) Add a Trigger with actual command line string “Delete” and keystroke Ctrl+D or whatever
(4) Said trigger then sends a “ReportDelete” followed by a “DoDelete”
You could probably just report directly on the e.g. Ctrl+D keystroke, but sometimes I have other logic I want involved here.
I just did a trigger action with a CTRL-R (Report Action) followed by a CTRL-D (Delete). Unfortunately, that was after I tried every permutation and combination of $LocationName$ $location$ $OldLocationName$ $PieceName$ $BasicName$ $oldPieceName$ and the 20 associated test launches…
I am curious about what secret knowledge is behind this statement. I have got movement trails working exactly as I like them with one very minor quibble. I would like the turn counter to trigger clearing the movement trails at certain points. I already have several such triggerings of other stuff and the clear movement trails button works fine. I just need to connect the turn counter to a global Ctrl-M. It hasn’t worked so far. I suspect it should and that I have simply got my hotleys muddled with my global keys or something like that. But since I need to go and do some mundane housework I thought I might as well ask.
Are you using Send to Location or Return to Deck on the pieces with movement trails? As Brian describes, the trail disappears if you send them to another map, but if its a piece that never moved before the Send/Return, the global Ctrl-M has no effect.
Neither they are manually moved. I don’t think I have any key commands on them except for the “clear movement trails”. There is one exception but that gets converted to something that cannot move at all.
I have a set of fixes checked in that I hope will be approved for 3.3.2 or thereabouts, but here are some presently true details:
Movement trails can only be “toggled”, not forced on or forced off. So if you want to offer the player the option to “turn all the movement trails off” and/or “turn all the movement trails on”, you have to somehow keep track (individually) of which units currently have trails turned on or turned off.
Keeping track is made harder (presently impossible, in fact) if you turn on the “mark all units moved” button on your map, because it will also re-initialize all pieces that have trails to their starting on/off state, but will only do that for pieces that have moved, AND will not send any kind of GKC out to let you know this has happened.
Keeping track is also made harder because pieces have their trail/moved flags “initialized for the first time” when they are drawn for the first time. (This was “exhibit one” of when I started to think of this as a “clunky” implementation). So if you have parts of your map you haven’t ever scrolled over to yet, then, yeah, you can have problems. And I’ve had them.
Trails traits are messily entangled with the “mark when moved” trait, and although it is presently possible to have “only” a Trails trait (it secretly makes a hidden mark-when-moved attribute), it is NOT possible to then individually clear that pieces’ movement history without adding a “real” mark-when-moved trait.
THAT is presently made more difficult by the fact that if you add a Mark When Moved trait to a piece, then even if you clear the Command Line string for the trait it will not get rid of it from the piece’s popup menu, it will just put a blank line (so I’ve have to resort to a trait that I restrict and then briefly unrestrict for the operation, since I don’t want an individual mark-when-moved popup item entry on every single piece, any more than I want to see a trails on/off entry on the menu for every single piece)
If my fixes are approved a lot of those issues will go away.
All that said, it sounds like the specific application you’re describing (activating mark-when-moved on everything, to clear their trail movement history) SHOULD work.
From what you say I cannot see anything that impacts my very simple use case. It is probably me just muddling it up. So far I have always figured this stuff out but I have to do a mixture of going back to the manual and taking one step at a time.
One thing I discovered on the way: I need to restrict sending the Ctrl-M by {Moved==true}, otherwise everything that did not move is marked as having moved.
This is an excellent write-up and also explains why I was getting inconsistent behavior that I couldn’t account for. The units that returned to decks before being drawn were the culprits. Geez, I wish I had you around to supply these writeups before every task. Then things I expect to take one hour, would actually take one hour, not five…
Agreed. An excellent write up. I only had half the story worked out from a long and boring battle with the opaque implementation of trails, and I still have the annoying blank command on my pieces in one module.
I fixed that issue by adding a Restrict Command with the property {Selected==true}. It does have the side effect that trails are not cleared for pieces that are selected, but that could also be useful.
That is a clever solution - much more elegant than my global “ClearingSemaphore” that I turn on when I want to send a clear movement command around. I guess it would keep your global commands from affecting your currently selected units.
It appears that the behavior of Movement Trails has changed again since the last correspondence on this thread. I now have movement trails in 3.6.4 with Return to Deck and Send to Location commands that weren’t happening previously in 3.4.13. Is there a writeup somewhere of how this behavior has been changed?
Answering my own query again. My guess is “3.5 - 13821 - Send To Location generates Movement Trail points.” is the culprit. It’s odd tho - reading the Issue name, it suggests the problem is that Send To Location isn’t supposed to generate a Movement Trail but that it was. In fact, it was the exact opposite. Unfortunate that one man’s bug is another man’s feature. Can someone confirm which is supposed to be the correct behavior? Thanks.
