GreenSock

There's nothing fancy inside of TweenLite that would cause skewing - it just sets the rotationX property over and over again (a new value on each frame during the tween). It's normal for there to be perspective skew, though - did you want to eliminate that? If so, why not just tween the scaleY property or something?

Are you absolutely POSITIVE that the actual class files are AS3? It definitely sounds like you've got AS2 classes instead of the AS3 ones. Try deleting your ASO files too. Check to see if your classpath points to an AS2 directory as well.

I bet you used the wrong AS version in your project. In other words, if your FLA is set up to publish to AS3 but you use the AS2 GreenSock classes, it'll spit out that error. Make sure you download the appropriate classes. I'd recommend v11: http://www.tweenmax.com

Glad to hear TweenMax has been helpful. Always gratifying to hear of fellow designers putting it to good use. I'd recommend Kieth Peters' book "ActionScript Animation" if you want to learn some really nifty stuff for animating things in ActionScript. Best book I've read by far. He's great at explaining things in an easy-to-understand way. There's an AS2 book as well as an AS3 one.

If you want to scale it proportionally so that the _width is 620, you could do: var ratio:Number = 620 / mc._width; TweenLite.to(mc, 1, {_width:620, _height:mc._height * ratio}); Is that what you were looking for?

Absolutely.

I suspect the problem lies in the fact that you are using a TweenLite.from() call to tween the current MovieClip from an _alpha of 100 to whatever it currently is when that function is called. According to your code, the _alpha would probably already by 100, so you'd be tweening from 100 to 100 (no tween really). The old Adobe Tween was tweening from 100 to 0. Don't worry - you can easily fix this. It looks to me like all you'd have to do is change this: BAD: TweenLite.from(current_mc, 1, {_alpha:100, ease:Cubic.easeOut}); GOOD: TweenLite.to(current_mc, 1, {_alpha:0, ease:Cubic.easeOut}); If you want to be able to control the starting and ending values in the future (not that you need to in this case, but I wanted to point it out anyway) just like the Adobe Tween class, you have 2 options: 1) Set the starting value immediately before you do a TweenLite.to(), like: mc._alpha = 100; TweenLite.to(mc, 1, {_alpha:0}); 2) Use TweenMax's fromTo() call (new in v11): TweenMax.fromTo(mc, 1, {_alpha:100}, {_alpha:0}); Also, you might want to consider looking into the new TimelineMax class in v11 (http://blog.greensock.com/v11beta/). It allows you to set up a sequence of tweens and set a "repeat" parameter that will repeat the whole sequence a certain number of times or infinitely (by setting repeat to -1). You don't NEED to use TimelineMax at all in this case - I just wanted to make you aware of it because you might really like it.

Did you import the TimelineLite class? Sounds like you forgot to. Either do this: import com.greensock.TimelineLite; or import all the classes in the com.greensock package (don't worry - Flash will only embed the ones you actually use) like this: import com.greensock.*; And of course make sure you have the "com" folder with all the GreenSock code in the same folder as your FLA file (or set up a custom class path).

You'd be surprised how many people wonder the same thing. The answer is: 1) Yes, you must import it in every class where it's referenced 2) NO, importing it multiple times (in various classes or on various frames) does NOT increase the file size exponentially. Flash is smart enough to only embed the code ONCE. The import statements are like "pointers" that tell Flash which class you're talking about when you type "TweenLite". Import it as many times as you want - it will only embed it once.

Ha ha. I like the thread title. Anyway, no I'm not aware of any issues with TransformManager rotation causing size changes. Sorry. Wish I had a magic bullet to give you. You are using the AS3 version, right?

Sure, you can use the "frame" plugin to have TweenLite or TweenMax tween the playhead of ANY MovieClip's timeline. TweenMax.to(this, 2, {frame:1}); //assumes "this" is the main timeline. It'll tween to frame 1 over the course of 2 seconds.

Sure, TweenLite.to(mc, 1, {x:100, delay:0.5, onStart:bringToFront, onStartParams:[mc]}); function bringToFront(object:DisplayObject):void { object.parent.addChild(object); } onStart allows you to define a function to call when the tween starts. In this case, after the delay of 0.5 seconds, the tween will begin and call the onStart which is pointed to bringToFront. Make sense?

No, but you could use an onStart callback to do that sort of thing. It wouldn't force it on every frame to the top, but it would do so at the beginning of the tween which is probably all you need. Right?

No no, I think you misunderstood. You can definitely get the effect you're after. I was just saying that you must EITHER tween the saturation of the Loader OR the content of the Loader. Currently, you desaturate the Loader and then try saturating/desaturating the content. The tweening is working fine, but you can't see it because you're looking through the "lens" of the Loader which is completely desaturated. My recommendation would be to always tween the Loader. Attach your listeners to the Loader and use the event.target in your handlers (which will resolve to the Loaders). Make more sense?

Yeah, I can't seem to reproduce this problem either. A sample would be great.

Yep, I needed to add one conditional statement to the code. Sorry about that - I just posted an update. Let me know if that resolves things for you.

I noticed several problems: 1) You desaturation the Loader immediately, but your rollOver/rollOut handlers try to saturation/desaturate the content of the loader. So you've desaturated the container which means that even if the contents of that container are fully saturated, you'll never see it because the container itself is desaturated. You should make your tweens affect either the loader or the contents consistently. 2) You've got conflicting tweens: TweenMax.to(mc, 3, {colorMatrixFilter:{saturation:0}, delay:1, overwrite:0}); TweenMax.to(mc, 3, {colorMatrixFilter:{saturation:1}, delay:0, overwrite:0}); After the delay expires (1 second), you've got two tweens that both control the same property of the same object for 2 seconds. Not good. Be careful about setting overwrite:0. Usually the AUTO mode does a very good job. In any case, I'm not sure what you were trying to accomplish with these tweens, but they definitely shouldn't be run together. Hope that helps.

Glad to hear the code has been so helpful. Yeah, v11 is structured quite differently than v10 and uses another level of inheritance. Maybe the encryption software was having a hard time with that. Not sure. But hopefully the encryption software will fix the bug in their software soon. Let me know if there's anything I can do on my end to get around the issue.

Well, I'm not generally a fan of that style of creating tweens because it's a bit clunky and slow. Iterating through the properties of an object and copying them to a new object is...well...slow. If you want to create some general styles that can be overridden when necessary, you could just set up some functions that accept parameters for stuff that might change, kinda like: function navOver(target:Object, duration:Number, delay:Number=0, overwrite:uint=1):TweenLite { return new TweenLite(target, duration, {alpha:0.6, scaleX:1.1, scaleY:1.1, ease:Sine.easeOut, delay:delay, overwrite:overwrite}); } function navOut(target:Object, duration:Number, delay:Number=0, overwrite:uint=1):TweenLite { return new TweenLite(target, duration, {alpha:1, scaleX:1, scaleY:1, ease:Sine.easeIn, delay:delay, overwrite:overwrite}); } Or if you want more flexibility and are willing to give up some speed, you could set up defaults like: public static const NAV_OVER:Object = {alpha:0.6, scaleX:1.1, scaleY:1.1, ease:Sine.easeOut, delay:0, overwrite:1}; function tween(target:Object, duration:Number, style:Object, vars:Object=null):TweenLite { if (vars == null) { vars = {}; } for (var p:String in style) { if (!(p in vars)) { vars[p] = style[p]; } } return new TweenLite(target, duration, vars); } Then you could simply pass in the style, like: tween(mc, 1, NAV_OVER); //uses all defaults tween(mc2, 1, NAV_OVER, {delay:1, onComplete:myFunction}); //overrides the delay and adds an onComplete Just a few ideas. Hope it helps.

Yep, I see the problem. You set up 2 vars objects and then you reuse them. That's fine, but you keep changing the "delay" property of each one. So you changed it to a non-zero value, and then when you used that same vars object again and didn't alter the delay property, you probably thought it was zero, but it wasn't - you had set it to something else previously. That's why it worked fine when you made sure to specifically set it to zero. Also, you said you're not initing OverwriteManager but you used an overwrite mode of 3 on one of the tweens - that won't work unless OverwriteManager is initted. Make sense now? If something isn't working as expected, feel free ask. There's no voodoo magic going on in there that would cause strange behavior, requiring you to set overwrite values in strange places . It should prove to be rock solid. No known bugs whatsoever. And I know a lot of people that kick the snot out of this little engine and rely on it heavily with zero problems. (not to imply there are never bugs - just saying you can generally trust it to do its job very well even under tons of stress) Happy tweening!

Could you post an example of the broken version? I think there must be something else going on - the delay never carries over from one tween to another, and you're right - the overwrite:true will definitely kill all existing tweens of that object. However, you mentioned a timer that you set up that triggers a new pulse every so often - I wonder if that's causing the problems? TweenLite cannot know that your Timer is going to call a function that triggers new TweenLite instances (preemptively overwriting tweens that don't exist yet). Oh, and for the pulse effect, you might want to try using combining the new "repeat", "repeatDelay", and "yoyo" properties of TweenMax v11 because you could get a similar effect with one line of code that'd replace all your timer stuff and the two other tweens. Like: TweenMax.to(mc, 1, {scaleX:1.5, scaleY:1.5, repeat:-1, repeatDelay:0.5, yoyo:true}); http://blog.greensock.com/v11beta/

Just to clarify, since TweenMax extends TweenLite, the total file size incurred by using TweenLite AND TweenMax together is exactly the same as if you only used TweenMax. But there is a small benefit to using TweenLite even if you use TweenMax elsewhere in your project - since there's less conditional logic in the rendering routines, TweenLite tweens can run SLIGHTLY faster than TweenMax tweens. You'd never notice unless you're tweening hundreds or thousands of tweens simultaneously, though, so it shouldn't be a major concern either way. Since I'm an efficiency freak, I tend to use TweenLite for all tweens that don't specifically require a TweenMax feature. Speed test: http://blog.greensock.com/tweening-speed-test/ So yeah, using just TweenMax would be a bit more clear I suppose and there isn't a compelling reason to mix & match, but if you're a fellow efficiency freak, it's fine to do.

Of course. Why, are you running into trouble? If you turn on OverwriteManager in AUTO mode, you don't even have to add overwrite:false. OverwriteManager.init(2); TweenLite.to(square, 2, {z:1000, ease:Back.easeIn}); TweenLite.to(square, 2, {x:400, ease:Sine.easeOut});

Sure, TweenMax has a static killAllTweens() method. TweenLite doesn't, though (to minimize file size).

If you want to set up a sequence, just use the "delay" special property or look into using the brand new TimelineLite or TimelineMax classes in v11 (http://blog.greensock.com/v11beta/). Also, I noticed that you're putting "()" after your onComplete functions which will force them to get called immediately. BAD: onComplete:myFunction() GOOD: onComplete:myFunction