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?

For 603 days at least?

Finally had a chance to read it through and somehow I get the feeling that some genius decided that "steady framerate is better" and hard-coded increments if five into it or something - I almost never get any odd framerates, they tend to "even out" after a while towards 60, 45 or 30. Hopefully with the extra attention this stupid bug will finally get sorted.

Also... BLOOP!

So I can see how it might look like I'm trying to shoot everything down, but really it's how I test ideas to see if they're worthwhile.

So we can assume you see no merit in the often-mentioned Boolean global variables idea? (As one simple example of decent ideas from users that haven't seen any response). If so, why?

Hey, I had built one as well, it wasn't exactly a hit. Sometimes useful, though:

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?

I have been thinking about this as well (why are you looking at me like that? ) and it seems like you could use a paster object for background and paste your corpses onto it every now and then, preferably when the action allows down, like between levels. Then delete them and work on getting fresh ones.

I'll need to check your version once I'm back on pc, but then again if an example is flawed because it assumes stated system functions act the way they are presented - are they really flawed?

Most of my questions are based on the assumption that one can use just the behaviours and basic events to get reliable results, yet almost every solution ends up with "use these custom events with variables" and so on.

There was another question about "sub tick" object creation and movement and it seems the answers are also "basically programming". Call me lazy, but I would prefer reliable solutions using the built in systems.

As for the precision - then why isn't Every X seconds precise if one can get that precision with events?

If you know that after x seconds your value should be 123.456, great, you can have a correction factor for your simulation ; but only you know that

OR... the behaviour should know that - if it's set to turn 90 degrees after a second I'd like that to happen. So it uses dt and isn't 100% reliable, but why then is the dt*90 sprite at a different angle than the behaviour one? Something somewhere seems a little off, you know.

Yeah, what puzzles me if the kind of error you get ; several degrees on just a single rotation, that's just plain weird and would not be explained by floating point error accumulation

What I mentioned before certainly doesn't explain the massive inaccuracy you're getting. You could be getting 90.00000001 instead of 90, but 93 or so, that's just odd

Which is why I built that demo - to show the rather big displacement in angles - so perhaps it isn't 3 degrees, but still plenty. And it doesn't just accumulate, but rather jumps back and forth, so in reality it's even bigger at times.

And why over 1 sec ? That's arbitrary, and in a different example we might prefer time consistency over 0.1 sec, or maybe 60 sec, etc. The definition of dt is not to accumulate exactly to 1.0 over 1 sec ; it is to represent the time elapsed since the last frame, and one doesn't guarantee the other.

Well, if I read Ashley's post on dt it certainly creates the impression that we can rely on it summing up to 1:

[quote:3s6uintr]Notice that if you add dt to a variable every tick, it adds 1 every second, because the time between all the ticks over a period of 1 second must add up to 1! Here's an example showing just that. (Adding dt to an object's instance variable is also a handy way to have a timer in an object.)

Also "that's arbitrary" - in that case dt might be any random number, but it just happens to be a fraction of a second.

I'm not necessarily arguing about definitions here - I'd like reasonable precision in things - if it's set to 90 degrees per second and then we get 88,91,92,89,90,88 etc - seems a little vague, that's all.

Which makes me feel like the dt should have this built in - like always make the closest end value a round 1.0 - wouldn't that make sense? If it's advertised as "1.0 every second" then some of these 0.01-0.05 errors can quickly mount up.