Another new feature I’ve added to GTween beta 5 is support for synchronizing timeline animations with scripted tweens. This lets you ensure that animations will remain synched even if you change the framerate of your FLA or if you pause, reverse, repeat, or otherwise manipulate your tweens.
Here’s a simple demo of it in action. The run cycle and fire are frame by frame animations, all other animation is done with GTween. Notice how the run cycle always lines up exactly the same with the motion tweens (despite everything being time based) and how it pauses along with the rest of the animation. The fire is not synchronized, so it will continue to play when the tween pauses, and is affected by framerate.
Also worth noting: the fire’s visibility is controlled through another new feature of beta 5, which improves on progress points. Best part, its only a few lines of fairly readable code for this whole demo.
Still working on crushing bugs, cleaning up documentation, polishing samples, and finalizing the feature set for beta 5, but I hope to release it early next week.
UPDATE:
Interesting… the animation works properly in the debug player (both 9r115 and 10r2), but in the regular player it starts the runner at box height when it loops. Looks like a player bug… I’ll try to isolate it.
UPDATE 2:
Fixed. Not a player bug. It was an issue with iterating a Dictionary, and the order was different in debug and regular players. Actually helped me improve on the reliability of the sequencing engine.
I’m seeing the running start on the same level as the box here.
Windows XP Professional, Google Chrome ( though is the same on firefox 3 and ie 7 ), Player 10,0,12,36
I see the bug too – runner starts at the height of the box – OS X 10.4.11 Safari 3.2.1 player 9.0.151.0
seeing the same thing:
Firefox 3.0.5
Windows Vista Home Premium 64bit
Flash Player 10,0,12,36
not happening in same system with IE 7.0.6001.18000 32 bit with player 10,0,2,54
no flash in 64 bit version of IE
Google Chrome, win xp, player version 10,0,12,36
I can see the bug.
Wish you luck on fixing the bugs.
Hope you’ll release GTween soon. Looks like complete solution for the most programmatic animation scenarios.
The first time he runs to that box it’s ok. All other times he will start running too high.
Opera 9.63
Player 10,0,12,36 Release
Same thing happens to me. It starts off just fine, but when it starts to loop, the runner is box-high.
Ubuntu 8.10, both Firefox 3.0.5 and Opera 9.51, with Player 10,0,15,3 installed
Runs perfect here:
Flash Debug 10,0,0,525
FF 3.0
Windows XP
same here with Firefox 3.0.5, OSX 10.5.6, FP 10,0,12,36
FP 10,0,12,36 debug is working fine.
The box bug doesn’t appear on my winbox with Vista in FireFox 3.0.5 with fp10,0,12,36 (debug)
but it does appear in IE 7.0.6001 with fp9,0,124,0(normal)
And I get another bug approximately 7 out of 10 times: if I click the animation to pause it, after the runner has passed the fire and then restart it, then the anim automatically pauses when the runner is at the edge of the screen. This happens in both players.
Updated to player 10.0.12.36. First, normal player (made the bug) and then debug player (worked alright).
… Hmm, guess that’s why they called it the “debugger” 😉
Happy hunting, Grant.
/ockley
FP 10,0,12,36 Mac (regular version) on WebKit => the runner starts at box height when it loops. Probably something related to the old asynchronous issue when calling gotoAndStop (which I think was solved on FP10).
creynders – that was actually expected behaviour. It was set to loop 3 times and then stop at the end. I’ve uploaded a new demo that loops continuously so that it’s a bit less confusing.
Great! Can’t wait till i can get my hands on the new beta 🙂
@grant: ok, makes sense, but was confusing.
Just tested it here at home on win XP in FF3.0.5 with fp9,0,124,0 (normal) and IE6.0.2900 with fp9,0,124,0 (normal) and both work great.