# First tween too fast; SOLVED...but not sure why

Newbie experiment here. I’m trying to create an object every 5 seconds and have them tween to an adjacent grid square (imagine a top-down grid-based game) using a tween (“Pulse”). Everything works perfectly…except that the very first object created jumps from its origin square to the adjacent square instantly instead of taking 500 ms as designated in the tween. After that it moves correctly and every subsequent object created also moves correctly: each tweens in the random direction (up, down, left, right) it was assigned at creation and over the proper time.

Can anyone see the error in my event sheet? Could it possibly be a bug? Thanks in advance!

500 ms = 0.5 seconds. You should use 5000 for 5 seconds.
Of course, if it’s working as intended at 500, don’t worry about it.

As for the problem only occurring with the first created object, I’m not quite sure, sorry. I suspect that the second block of events is the culprit and not the Tween duration.

Do the timer variables need decimals? It may not be an issue, just seems extraneous if you’re not trying to indicate a fraction of a second like 5.5 for example.

Thanks for your reply. The 500 ms as I have it is correct. A new ball object is created every 5.0 seconds. But the balls move to an adjacent grid space every 1.0 seconds. The tween time is 500 ms. So each ball moves in .5 seconds to the new grid square, waits another .5 seconds (for the stepspeed timer to reach 1.0 seconds), then moves to the next square, etc.

But why the first ball created jumps instantly upon creation to the adjacent square instead of tweening over 500 ms, but then moves properly, is still a mystery. (I’ll look into what you said about the second block of events. )And every subsequent ball, created on a random square, properly tweens (in 500 ms) to the next square upon creation.

Any further thoughts would be much appreciated. Here is a screenshot of the “balls”, (which are actually just blue squares) as they tween between grid squares, each going in the random direction it was assigned upon creation.

I fixed the problem by switching the 2 event blocks. I moved the object creation block under the block of tweens. Now the first-created ball tweens properly, as do all subsequent balls. But I’m not sure why it works or why there should be a problem with it in its original order. So if anyone understands this, I’d love to know.

An error often made is to consider the events as, well, events. The way GDevelop games work is like basically every game: an event loop. Every frame, it executes all the events in the order they were written. An events becomes (simplified)

``````if(condition1, condition2, etc) then do {
action1,
action2,
etc
}
``````

They are not propper events, because events would make their code (actions) trigger whenever their conditions are met, without assurance that any order is followed. Here, each frame each event has his conditions checked and their actions executed in case of met conditions in the order they were created. That is why order matters. If you first create an object then check something on all objects for example, it will include the new one while if you do it the other way around, it would only take into account all already existing objects but not the new one as it doesn’t exists, as it will be created just after.

That’s why order matter.

Thanks for taking the time for your considerable response! I understand—or at least I think I do—the importance of event order. What you’re saying is that GDev isn’t object-oriented, but that it runs more like a Basic program; just one long main loop. That said, I still can’t see why changing the order of the blocks made any difference in this case. Admittedly, I don’t have much experience with parsing GDev’s Events yet, but the tweens are all specified as being 500 ms, so I don’t see what could make the first one jump…or why all subsequent ones worked properly. Even though the re-order fixed the problem, I’d feel better if I understood exactly why, lest I run into a similar problem in the future.

1 Like

I guess there is some kind of problem with the tweens on the first frame, and by switching them you made it so the first tween actually begins tweening on the second frame (as the object is created after the tweening happened)