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.

Comments (14)
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
Posted by: aA at January 28, 2009 10:37 PMURL: http://moads.wordpress.com
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
Posted by: Lex at January 28, 2009 10:46 PMURL:
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
Posted by: mauricio giraldo at January 28, 2009 10:52 PMURL: http://www.mauriciogiraldo.com/blog
Google Chrome, win xp, player version 10,0,12,36
I can see the bug.
Wish you luck on fixing the bugs.
Posted by: Nikita at January 29, 2009 12:20 AMHope you'll release GTween soon. Looks like complete solution for the most programmatic animation scenarios.
URL: http://nikitadudnik.com/blog
The first time he runs to that box it's ok. All other times he will start running too high.
Opera 9.63
Posted by: Erik at January 29, 2009 12:41 AMPlayer 10,0,12,36 Release
URL:
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
Posted by: Alex at January 29, 2009 01:06 AMURL:
Runs perfect here:
Flash Debug 10,0,0,525
Posted by: ockley at January 29, 2009 01:10 AMFF 3.0
Windows XP
URL: http://www.hjaelpmignu.dk
same here with Firefox 3.0.5, OSX 10.5.6, FP 10,0,12,36
Posted by: Martin at January 29, 2009 01:11 AMFP 10,0,12,36 debug is working fine.
URL: http://www.formatlos.de
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.
Posted by: creynders at January 29, 2009 01:22 AMURL:
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
Posted by: ockley at January 29, 2009 01:24 AMURL: http://www.hjaelpmignu.dk
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).
Posted by: Gabriel Laet at January 29, 2009 05:40 AMURL: http://gabriellaet.com
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.
Posted by: Grant Skinner at January 29, 2009 09:38 AMURL: http://gskinner.com/blog/
Great! Can't wait till i can get my hands on the new beta :)
Posted by: DataGreed at January 29, 2009 01:42 PMURL: http://blog.datagreed.ru
@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.
Posted by: creynders at January 30, 2009 02:58 AMURL: