Is timing in C2 accurate?

The main issue here is game engines run in discrete steps (frames), rather than continuously. They create the illusion of continuous motion with many small incremental steps at a relatively fast rate (normally 60 FPS). A smaller factor is system timers are not always perfectly accurate, so dt has small random variations. And an even smaller factor is adding up floating point numbers accumulates error with every addition.

If you rotate an object by 90 * dt degrees every frame at 60 FPS, then it will be rotating about 1.5 degrees per frame. You only need 'Every X seconds' to be off by a single frame and you have greater than 1 degree error, without even taking in to account the small random variations in dt, or the floating point addition error. Even if all timers were perfect and the framerate was perfect, at 60 FPS then 'Every 1 second' is due to run exactly at the time the 60th frame runs. Then you only need the tiniest bit of random jitter in the timing systems to cause the next timer to fall on a random frame: either just before when it's due (so that frame), or just after when it's due (so the next frame). In practice there's probably enough jitter to throw this out by 2 frames.

Solution: don't expect to get the right number of frames. A better way to achieve this type of thing is to use an algorithm like "rotate at 90 * dt degrees per tick until it is clockwise of its destination, then assign the end value again". The "assign end value" bit means that if you end up somewhere like 90.0001 degrees (due to any of the other sources of error), then you just set it back down to the exact value of 90.

None of this is specific to C2 - it will be the case with any game engine using this approach.

Thank you once again, Ashley, for the detailed explanation. I see that custom event work is the solution. It would be great to have a timer component for the simple movements like rotation, bullet, etc. If it's 0 the movement doesn't stop, if it's a time it stops around that time and at the right distance/angle instead of around the time and around the distance as it is now (using Base events).

Why do I keep on about automating things that can be overall achieved with events? Laziness, user friendliness and being true to the "no coding needed" mantra of C2.

If I may ask, though - why does dt dt*90 end up at a different distance from the behaviour?

The only flaw in your example, if my analysis is correct, is that you were using a less accurate method (world time) to time a more accurate method (tick based).

I'm pretty sure you should be able to replace "every x seconds" in your example with a Timer behaviour, which would then be tick based, and then get consistent results

The results were about equally bad - like Ashley explained above an "error" of up to 3 degrees is apparently nothing special, so, like you mentioned something like this is called for (this was the cleanest and leanest I could come up with):

It's basically imperceivable to the naked eye that there's a mild jump near the straight angles. What is annoying, though, is the need to set up the timer behaviour on startup - why isn't that streamlined like the other behaviours?

[Not my idea] There's two tricks I mostly resort to to ensure sync [timing]...

So, r196 has had some changes, related to this post, I suspect:

Delta-time measurements are now based on the browser's rendering timestamps instead of time measured from JS code. This means motion should be smoother since it is based on when the browser is scheduling frames instead of when the JS code happens to run.

For one dt is suddenly way more accurate (no clipped to 2 digits):

But at the same time - look at that framerate - same capture conditions, there's almost no CPU load when it runs without capture and yet unlike the previous example it never goes over 40 fps. And those DT numbers - are we in sub-tick territory now?