Oh interesting you could also maybe notice things being added to a mat, and then have a little “sort all these dudes on my mat” algorithm that ran via GKC since you can fast-match for on-same-mat? The one thing that unfortunately I don’t think is presently supported is transforming things along the current angle of the mat – since one would want to have e.g. "spot 1, spot 2, spot 3, … " for the mat and tell the pieces go jump to the designated spots - but those offsets would need to account for rotation, not just just e.g. x + 50
Argh, rotation, yeah. Nightmare.
Maybe just do that for the hands for those drag everything and ignore instructions players =P
1 Like
As far as the snap-to on your player sheet, I remember at one point I had devised some way to prevent an infinite loop when the apply-on-move sends a piece “to its own location” as a way of snapping things.
OK, that scares me. I’ve been using send to CurrentZone forever, and never even considered the possibility of infinite loops. CurrentZone!=OldZone would be the default trigger condition, but in this case I kind of do want a trigger even if someone tries to move the piece in the CurrentZone.
Well you probably weren’t doing send-to-location to LocationName from the apply-on-move key.
I think what I did is the trigger that received the “moved” command first set a semaphore property to true, then did all of the movement adjustment, and then set the semaphore back to false. And that trigger wouldn’t run at all if it was encountered and the semaphore was already true. Screenshot below gives the general idea.
Oh, I have, in a few modules.
Now I wonder why it never seemed to cause any problems.
I also have used on/off flags in several situations. It never occurred to me to do it all in one trait though, that’s much neater, thanks.
1 Like
(If you have a moment, since you already have the module, could you take a look at Mat shrinking in 3.6.0 too?)
Bad news – Brent pointed out that it is possible to have multiple pieces in one listing. It’s if the pieces are in the same stack. Then you get multiple pieces, one move summary, and that’s why the pieces can’t properly be used as property sources there. I’d probably have to put in some switch to turn off the stack-grouping behavior.
Meanwhile below is the inside of a fairly simple Prototype I use to do move reporting. The only reason there are even those two different Trigger traits is because I wanted to distinguish between “created” and “moved” – one could also do without the distinction. The ToLoc and FromLoc I generate from calculated properties just so I can actually report the name of the Mat as the source or destination if one is involved. Anyway just an idea.
1 Like