I want to thank the folks that created the online documentation. I’ve been learning a lot reading through it all.
I have a question about the Send To Location trait. It doesn’t seem to make the system property; Moved = true. When I send units to a location, I get a movement trail but not the default marked moved icon. Yet I can clear the movement trail using the map board menu enabled marked unmoved option.
Why is this? Do movement trails fire a different system property than the Moved=true property? If so, what is it? I’m trying to select a piece by the trail…bad pun.
I’m trying to develop a way to clear some movement trails on some pieces but not on other pieces. I’ve found a way to do it by using a GKC and a trigger action. The problem is that the movement trails formed when a unit is sent to a location will not clear unless the piece is moved by click drag at some point. I thought send to location would make Moved = true but apparently Moved = true only fires when a unit is moved by click and dragging.
I understand how important the order of traits are and I hope my problem isn’t related to that. I’ve experimented with many different trait orders and the issue is unchanged. That being said, my apologies in advance if I’m missing something simple like that.
This is still an issue as of Jan 2020. A mere send-to-location does not set the Moved flag – which also means that a “Clear Movement” (even a global one from the auto-generated toolbar button) command will NOT clear the move trail history of a unit before the unit has been manually dragged. Example: piece is on Force pool window (Loc A). Piece is “sent-to-location” on the main main to its entry point (Loc B). Clear Movement / Mark Moved is executed - most pieces have their move trail cleared. If Piece is now dragged to Loc C, and move trails turned back on, it will show lines Loc A to Loc B to Loc C even though Mark Moved happened AFTER the Loc A to Loc B send-to-location.
In addition Send-To-Location frequently interacts oddly with Move Trails – it often seems to “hijack the last point on the move trail” rather than adding a new point of its own, so a piece dragged from “Space A” to “Space B” and THEN “sent-to-location” to “Loc C” with a hotkey or right-click will show a line directly from “Space A” to “Loc C”, with “Space B” no longer in the history.
You also pointed me to the solution - if you move the “Mark When Moved” and “Movement Trail” traits above your “Send to Location” traits, they start working as you’d expect them to.
Pieces moved by Send to Location still won’t always gain the “Moved==true” flag. The ONLY way to clear all trails reliably is to use the Map button specifically for this purpose, which is annoying.
I am able to clear them reliably (with an asterisk to be described below) by using a GKC to all pieces (or a designated subset of pieces) which then causes them to invoke their “Alt+M” (key I have assigned to the Mark-When-Moved attribute on the piece).
The asterisk is… it turns out there seems to be some “uninitialized local data” in the trails code (the “locallyVisible” flag, if you’re the type of person who looks at the code), and the way it gets initialized for the first time is when the piece is drawn for the first time(!). So the one kind of piece where the GKC fails is a piece which has never yet been drawn in the game – in this case invoking the clear movement ends up turning trails on for the piece. So workarounds might be things like a dynamic-property on the piece recording whether it has ever been moved on the map at least once (in which case it has presumably been drawn at least once) to screen the GKC from accidentally turning trails on.
I certainly agree that the Moved/Trails interaction is incredibly annoying, and at least in this case buggy as well.
It would be most helpful if:
Trails visible flag could be “read” for an individual piece (so I could know if I wanted to turn it off or not)
Trails visible flag could be forced to a specific value (on or off) as opposed to only toggling it. (So I could guarantee a known state).
At minimum the “locallyVisible” flag were properly initialized without the piece needing to be drawn.
Thanks for the info! Definitely something wonky with the hidden-to-the-user trails flag.
When I used a GKC, I set it to only affect pieces with Moved==true. The pieces it didn’t affect had been moved in a previous turn (so locallyVisible must have been initialized, right?) and had been SentTo the coordinates they were initially sent to when first drawn on the map, leaving a trail (could this be confusing locallyVisible?) So those pieces kept their trails. When I use the map button instead, those trails are also correctly removed.