Actors attached to each other in the "updated always" event don't move together

I have an actor that's being moved using a slide block (actually, a call to moveTo() in a code block) and another actor that's attached to it using a separate actor behavior (in the attached actor) that sets the second actor's (x, y) coordinates to the first actor's coordinates, in the "updated" event.

This works, mostly, but the second object seems to drag a bit (by a pixel/frame) behind the first object. I would like the two actors to move together, with no visible drag.

Is this the expected behavior? If it is, is there another way of achieving the same effect? I believe the documentation called the problem I'm trying to solve "the Zelda problem." At this point, I can think of a few other, less polite names to call it...

While researching The Interactive Stencyl Book, I had a truly enlightening moment. When I first started using Stencyl, I was used to GameSalad. I treated actors separately. Their code was separated. Stencyl doesn't have to work that way. You can control everything from a central location.

Instead of having the first actor move, and then having the second actor move... the first actor can move itself – and then move the second actor – in the same event.

I'm not exactly sure what the problem is in your game, but it seems like the issue is there's lag. The code from one actor is not running at the same time as another actor. Perhaps putting the code together in the same event could fix that problem.

Thanks for the answer.

Like I said, the first actor is moving using a moveTo() method, which means that I don't have ready access to the place in the code where the actor moves itself. The engine is moving the actor. I suppose I could rework the code so that the first actor's "updated" event modifies the second actor's coordinates, but my understanding is that all the "updated" events are supposed to run together, and not be separated by frame redraws. Is this correct? Even if it is, the engine appears to have its own ideas on when actors' coordinates should be changed, and it seems to happen separately from when the "updated" events run. Otherwise, there wouldn't be a visible lag between when one actor is moved by the engine and when the other actor is moved by my code.

If anyone with knowledge of how the engine handles "updated" events can chime in, I would really appreciate it. Right now my best guess is that the "updated" events run before the engine has a chance to deal with tweens, which would definitely cause this problem, and which I would consider an engine bug - or at least a misfeature...

Maybe you already know this, but you can drag "Actor" attributes onto the Tween block. I attached a picture to post.

Also, while there is the "Updated" event, the order in which actors are run before the next frame is "Drawn", might not be in the order you want. I'm not sure. But since you say there is a "pixel/frame" lag, it seems like it might be wonkiness with actor updating.

Stencyl's tweening (in general) has caused problems for me. I've been able to solve some of my Stencyl problems with creative thinking... but that's usually after a long time of figuring out, "Why does it do that?"

This is what the documentation on github has to say about the game loop:

"Here's the order in which things execute within one STEP of the game loop.

Update Tweens
Mark physics objects as on/off screen
Update Mouse / Trigger Mouse Events
Update / Trigger Timed Tasks (do later, do every N seconds)
Update Keyboard / Trigger Keyboard Events
Native Mobile Events
Update Physics
Update Regions
Synchronize Animations
Update Actors
Update Animated Tiles
Update Transitions
Update Camera
Poll Input (Mouse, Keyboard)"

This is not how things are actually done, apparently. I was able to fix my problem by moving the call to invokeListeners2() from where it currently is, right after the code to handle native mobile events, to right before the call to draw() in postUpdate.  This is all done in com/stencyl/Engine.hx, by the way.

Specifically, I think the problem is that updating tweens is done a lot later in the game loop than the above quote from the engine documentation claims that it happens. This is what's causing the problem. I think there are other discrepancies between the documentation and the code, but they haven't caused me any problems. My testing is in no way exhaustive, though.