Obscure timing error with global transition

[Tricky_Widget]

I have what seems like a simple setup, but for some reason it breaks on occasion.  I've been working with this for two days and can't for the life of me figure it out.

I want to collect touch inputs to rotate a tile by 90 degrees.  If it is touched multiple times before the rotation tween completes, I want to queue the touches so it will rotate multiple times.  The queue size is limited so it doesn't get out of hand.

There is a different sprite for each tile orientation (north, east, south, west).  The sprite needs to be in sync with the tile rotating.  The sprite is updated at touch time so that it will be correct when the tile eventually stops rotating.

Attached is a simplified version of the logic I'm using to handle this.  The tween fires the global transition when it completes.

99% of the time it works perfectly.  However, once in a while it gets out of sync.  The sprite does not match the rotation.  This seems to happen when touching rapidly during a tween finish.  But I can't see how that could happen.

Can anyone see how this could go wrong?  Any input would be greatly appreciated.

[djaydino]

if there is no touch does it need to do something or just go to next frame?
i somehow do not like that next frame thingy in your setup
but that might just be me

the touch action is it in Got Touch? or in a different fsm?

[Tricky_Widget]

i somehow do not like that next frame thingy in your setup

It's necessary to keep it from looping.  The input events are "true" for the entire duration of the frame, so if it didn't wait for the next one it would go into an infinite loop.

the touch action is it in Got Touch?

It's actually using both "Touch Object 2d Event" and "Mouse Pick 2d Event" so that I can test on my PC and on Android.  But the behavior is the same with either (they trigger the same transitions).

I've made a change that seems to have at least gotten around the problem.  Originally when there was a new queued touch, I was cancelling the current tween, changing the sprite, and then creating a new tween for the remaining angle/time.

Now I've put the sprites on a child object.  Instead of canceling the tween and making a new one, I just adjust the child rotation to suit the new sprite and let the original tween continue.  I can't see how it's any different from a flow-of-logic perspective.  I only made the change because it was a bit more efficient.  But so far it seems to have fixed the problem, as well.

It's a mystery!

[djaydino]

nice to hear it is solved

can you add [SOLVED] to you subject pls

greetings,

Dino

[Tricky_Widget]

nice to hear it is solved

can you add [SOLVED] to you subject pls

Well, it's not really solved.  I just changed the circumstances and the problem stopped happening.  But I have no idea why.  A solved tag would imply that if someone was having a similar problem they could look here for a possible solution.  Which isn't quite the case.