no timed animations?!

smurfted

If i drop a sound effect in a timer object to play every 3 seconds it works just fine.

But if i say animate the actor every 3 seconds it doesn't work?!

Any ideas?

Hopscotch

@smurfted

The animate behavior has never worked inside an "every x" timer. It does work with "for x" and "after x" timers though.

Roll your own timer to solve this:

Change Attribute self.LastTime = game.Time

Rule: If game.Time >= self.Time + 3

         Animate Behavior

         Timer: After (length of animation)

                  Change Attribute self.LastTime = game.Time

         End Timer

End Rule

In 1.25.x you can use the Current Frame Attribute from the Animation Behavior to know when the animation is done, and then reset the self.LastTime.

Socks

@Hopscotch said:
@smurfted

The animate behavior has never worked inside an "every x" timer. It does work with "for x" and "after x" timers though.

You can also cheat it like this:

Every 3 seconds
--After 0 seconds
----Animate

Hopscotch

@Socks said:
You can also cheat it like this:

Yep, then remember to set "Run to Completion On" in the "After 0s" Timer.

However, timers are wildly inaccurate now, always being up to a few tenths of a second off the mark.

Timing with rules as per my suggestion solves this.

smurfted

You are both beautiful people who deserve wildly more than this thank you.

Thank you.

Socks

@Hopscotch said:
However, timers are wildly inaccurate now, always being up to a few tenths of a second off the mark.

Is that to do with the code cycle now being locked to 1/60th of a second ?

Hopscotch

My pleasure @smurfted

@Socks said:
Is that to do with the code cycle now being locked to 1/60th of a second ?

Beats me.

Just to show how variable the timer is, the following shows ticks created with identical interval timers, spawned from a moving actor. The top uses the Rule method, the bottom uses a standard timer.

Another thought, considering the educational focus, it may be a good thing to address these unintuitive inconsistencies, like animations working in some timers and not in others? @ForumNinja

Socks

@Hopscotch said:
Beats me.

Just to show how variable the timer is, the following shows ticks created with identical interval timers, spawned from a moving actor. The top uses the Rule method, the bottom uses a standard timer.

I suspect it is related to the quantization of the code cycle, when this was first implemented a few months back I talked to Codewizard about how a fixed frame rate would effect the animate behaviour - some animate frame rates cannot evenly divide into a 1/60th" 'grid' . . . for example whereas a 1/60th" 'grid' can happily accommodate a 30fps frame rate (2 code cycles for every 1 animation frame), a frame rate of 29fps would have to be spread across the 1/60th" 'grid' something like this:

frame 1 - held for 2/60th"
frame 2 - held for 2/60th"
frame 3 - held for 2/60th"
frame 4 - held for 2/60th"
frame 5 - held for 3/60th"
frame 6 - held for 2/60th"

. . . . etc . . . I expect the same is true for Timers under this new scheme as they are subject to the same 1/60th" 'grid', I expect you could get your Rule / Timer methods to both produce consistent results if the spawn rate is evenly divisible by 60.

*The rate at which the spawner actor is moving will also be a factor.

EDIT: quick example attached of a consistent timer example:

Hopscotch

@Socks

That is leading the witness, spawning every 0 seconds with a timer, off a move'd actor, where both are tied to the frame timer, WILL give a smooth result.

Change your timer to every 1s, 0.5s, etc, anything that fits the 1/60th frame rate, and you will again see the variable nature.

Socks

@Hopscotch said:
That is leading the witness . . . .

I suspect the witness' testimony is unreliable, and he's possibly been drinking.

@Hopscotch said:
spawning every 0 seconds with a timer, off a move'd actor, where both are tied to the frame timer, WILL give a smooth result.

Yes ! That's my point, with the new locked / quantized code cycles you need to calculate things like timers and animation frame rates so that they sit on whole frame (code cycle) values.

@Hopscotch said:
Change your timer to every 1s, 0.5s, etc, anything that fits the 1/60th frame rate, and you will again see the variable nature.

You just need to lower the time value so it's just below the divisible value . . . . so whereas with 0.05 you'll give the variable result, 0.0499 will give you a smooth result.

Basically, I think the timers are fine, they are firing at a consistent rate, but the changes to the code cycle (now locked to 1/60) causes issues if you don't get every synced.

Hopscotch

@Socks said:
You just need to lower the time value so it's just below the divisible value . . . . so whereas with 0.05 you'll give the variable result, 0.0499 will give you a smooth result.

I guess this will make the difference between an A and an A+ score in entry level educational courses.

Socks

@Hopscotch said:
I guess this will make the difference between an A and an A+ score in entry level educational courses.

I will sell these secrets to the students.