Inexplicable piece movement

Although I didn’t directly use anything from your example, I did learn a lot from it and found it really useful. Thanks again, you’ve been really helpful!

This I find interesting because I tested quite a few ways of achieving the same effect in my module, as opposed to a stripped-down test module where lag does not occur.

When I put an If() chain on the sendto trait itself, I got horrible slowdown the first time a piece was moved by drag and drop or Return.

When I put an If() chain on a control piece, as in your example, I got a pretty bad delay the first time Return was used.

In both cases, the delay was marginally reduced by replacing Zone destinations in the If() chain by Y coordinates.

However, the only way I found to entirely eliminate a noticeable delay was to use 12 triggers and 12 sendto traits. Messy, and it seems to increase log file sizes, but in terms of user experience, apparently the best solution.

So, I do think there are better and worse solutions, but it is not always apparent which is which, and the results can be quite unintuitive.

Incidentally, about 10 If()s seems to be the threshold for causing noticeable delays.

I now have a question.

I note that in the example module you kindly prepared, you have the tracking piece with a calculated value trait, and the SGP references that calculated value to set the GP.

Is there any reason not to have the SGP set a New Value of {insert calculation here} instead of {calculated value}? Something to do with processing load?

There’s no technical difference. Obviously if you will need to use the same calculation somewhere else Calculated Property has that advantage. And its expression window is a little easier to read when maintaining the module. But doing the full calculation in the Set Global Property’s set-to-value field will totally work.