chamberlainpi

Oh and thanks for the compliment Jack! (regarding "quick study"). I really love Greensock's TweenMax / TimelineMax. I don't think there's any reason at all for developers to consider any other tweening engine, you guys excel at what you do, and you provide great forum help (That's including you too Carl! Thanks!)

Ah ok. So I guess since most of my game animation "may" be affected by the slow-motion timeline (like.. 99.9% of it) when it is activated, I will have to setup some static variable that holds a TimelineLite instance (probably TimelineMax, for some advance features) that I could adjust the timeScale to taste. It kinda sucks to go through and find & replace all the TweenMax and TimelineLite I've already used for character animations so that it will use the global static TimelineLite I'll create, but c'est la vie! I'm just worried now that since I'll create one TimelineLite to control the majority of my child tweens, that Garbage Collection may be an issue. Do I have to clear or empty the TimelineLite instance (and if so, how do I do that?) periodically when old objects are no longer animated?

Hey Jack, I started using what you suggested before you mentioned it. The 1/globalTimeScale trick works well for initializing the tween, but it would change things if I tweened the slow-down and then tweened the normal-speed back again (like some sort of Matrix bullet-time effect). The thing that I get confused with using the exportRoot() TimelineLite is that... wouldn't the generated TimelineLite stop once it reaches the end of the last tween / child timline it process? If it completes the last tween, and then I add more tweens to it (at the tl.time() as you demonstrated), wouldn't that be in incorrect timing / not play at all since I would have to call play on the TimlineLite again?

Well, it doesn't exactly solve what I'm trying to do... I understand exportRoot() wraps things up in it's own TimelineLite, and that any other delay or tween calls afterwards are appended back to the rootTimeline, but if I have other objects that require to run in slow-motion after the timeline is exported, then how can I insert those newer delays and tweens on that slow timeline? Cuz if I understand correctly: If the rootTimeline is (A) and the exported TimelineLite is (B): (A) set globalTimeScale(0.5) -- all current animations are slowed down Some delays require real timescale of 1.0, so: - exportRoot() to get B timeline. - TweenMax.delayedCall( 1.0, myFunc, myParams ); But any other entities in the game should be spawn and animated under the same slow-motion Timline with the globalTimeScale of 1.5. How can I have any new TweenMax calls at this point still be running in the same engine / timeline / clock / whatever-you-call-it as the one just before I exported the root? It seems to me, exporting the root causes more problems / headaches in this situation. Can I just use another TimelineLite and have it run continually at a constant rate like the root timeline? Do I just start it at the beginning of my game and add tweens to it? Any point in time? and they'll basically execute as soon as they're added (depending if I pass it a delay or not)?

Ok so, I'm not sure I understand that example very well (in the documentation link you provided). Basically, should I start off my Application by creating an exported TimelineLite so that it becomes my global TweenLite to use for delays (not affected by globalTimeScale) ? I'm a bit confused between TimelineLite and TweenLite here, I understand one is for creating timelines of animations, the other is just to initiate the tweens, but if I'm just using delay calls, why would I need to exportRoot() on a TimelineLite? Is that the only class that has this exporting method? Is there a way to tell a TweenLite or TweenMax tween instance to be it's own root? Like, some way to indicate that in the vars parameters or a chained method after the TweenMax.delayedCall(...) call?

I was curious if there is a way to "overwrite" the globalTimeScale with the one assigned to a given TweenMax instance. For example: - I set the entire playback to slow-motion by setting globalTimeScale( 0.25 ); - Then, whenever I shoot enemies, I want to delay the SFX call with TweenMax.delayedCall in realtime timeScale, so I use: TweenMax.delayedCall( pTime, playSFX, [pSoundClass, pLoop]).timeScale(1); But this still animates according to the globalTimeScale (I'm assuming it does timeScale x globalTimeScale = 1 x 0.25 = 0.25). This DOES seem like the correct typical behavior (one timeline governing them all), but is there a way to overwrite this behavior? The only way I could get around it was by dividing 1 / TweenMax.globalTimeScale(), which gives the "inverted" time-scale value for the delay to catch-up to realtime durations. Is there any other approach to overwrite the timeScale of a given TweenMax instance? A boolean or a binary flag?

Ah beautiful! Yes that's much more elegant than I thought. I was so focused on looking for a parameter called "delay" that I forgot offset is basically the same thing (except it can go negative as well). Sounds like the labels can be even more useful too with the offsets. Thanks Carl! I'll read the documentation more closely next time!

hmm, but with your examples it doesn't really do exactly what I'm referring to. Your 1st (with addCallback) example actually requires knowing exactly how many seconds into the animation you need to trigger the method and parameters. What I meant was to add a callback with a certain delay from the last entry added / appended to the animation, similar to how multiple consecutive *.to(...) calls organizes the animation in sequence. Your 2nd example tells the animation to make a call (trigger) a method and some parameters at the current point in time (typically, the end I assume?) of the timeline. BUT, you can't specify the delay time to space it out from any previous calls before that! I've tried animation.delay(1) but that sets the global delay apparently. I was a bit confused by this. So not too sure how to add a delay just before, but doing so in the same call would be much more like delayedCall(...). The 3rd example, unless there's extra arguments I'm not aware of in that usage, falls into the same issues as the 2nd one. No way to specify the delay time before the method gets called. Basically, I'm looking for a way to do something like: var animation:TimelineMax = new TimelineMax(); animation.to(mc1, 0.5, {x: 2, y: 2, ease: Linear.easeNone}); animation.to(mc2, 0.5, {x: 2, y: 2, ease: Linear.easeNone}); animation.to(mc3, 0.5, {x: 2, y: 2, ease: Linear.easeNone}); animation.delayedCall( 0.5, this.addChild, [label1] ); animation.delayedCall( 0.5, this.addChild, [label2] ); animation.delayedCall( 0.5, this.addChild, [label3] ); animation.play(); //Animation plays in sequence: // mc1 moves 1st // mc2 moves 2nd // mc3 moves 3rd // after all MovieClips moved, the labels start being added // label1 is added .5 seconds later // label2 ... // label3 // THE END! Does it make more sense now? If *.addCallback(...) is the closest thing I can use for this, I guess then I would have to use animation.time() (EDIT: or totalDuration rather) within that call to tell it exactly where to trigger the callback function + parameters. Still... any chance to make the delay duration part of that method (instead of the specific timeline time), or possibly add that to v13?

I couldn't find this in the documentation, so I figured I should make a request here! Could TimelineMax be added the same funtionality as TweenMax where you can delay method calls? I realize it couldn't "reverse" the actions caused by those methods (unless a respective reversible callback method was supplied for each delayed callbacks... but nah!), but this would be very handy instead of using dummy [TimelineMax instance].to(...) calls, like the following: var animation:TimelineMax = new TimelineMax(); //Delay the next object's to be added to the displaylist later: animation.to( dummy, 1.5, {onComplete: addChild, onCompleteParams: [someSprite]} ); //INSTEAD, this would be nice! animation.delayedCall( 1.5, addChild, [someSprite] ); It would be SHORTER, sweeter, and ~loved~ by many I'm sure (me first!) Is there any internal complications that prevents this from being implemented?