JonDum

If you're wanting to make something REALLY red, blue, green, whatever use a colorMatrixFilter with colorize and amount. The higher the amount the more of that color it will add to the target. TweenMax.to(mc, 1, {colorMatrixFilter:{colorize:0xff0000, amount:3}}); You can also use a colorTransform (which may be destructive because it's not a filter). In this case running this will make the target completely red (tintAmount ranges from 0 to 1) TweenMax.to(mc, 1, {colorTransform:{tint:0xff0000, tintAmount:1}})

bump.

I can't conjecture why TimeLine is doing that (My best guess is that it's being reset every time you append a new tween). However, Jack thought of this and made it possible to do that sort of looping with the yoyo and repeat properties. var myTimeline:TimelineMax = new TimelineMax({repeat:0, yoyo:true, onUpdate:updateChildren}); (setting repeat to '0' will repeat infinitely).

Are you saying it's reporting the wrong getBounds after each frame? Or just when the tween is initialized? I tried delaying both the plugin being activated and the tween being called. Same results. Also, in TransformAroundPoint's onInitTween() I see no case logic for width/height, only x/y & scaleX/scaleY. So shouldn't setting width/height inside a transformAroundCenter:{} block act normally as if it wasn't in any plugin at all?

<?xml version="1.0" encoding="utf-8"?> creationComplete="application1_creationCompleteHandler(event)"> The button resizes from its flash registration point instead of its center.

Goal: Take a UIComponent and do this: TweenLite.to(bleh, 1, { transformAroundCenter:{width:800, height: 600} }) Possible? I tried hacking it in TransformAroundPoint, but I'm not really getting what the whole changeFactor(n:Number) does.

Maddening, to say the least. Flex drives me absolutely nuts sometimes. You'd think they'd fix Flex 3 before releasing Flex 4 I also noticed some really funny stuff with that same example where when the Elastic.easeOut was too strong for the animation and the bounds got negative, flipped, and it started drawing the thing as a circle! haha.

Ah, great points! I'm not entirely familiar with the architecture of the platform yet since I just started using it a few days ago; I didn't know about killTweensOf()! Those are definitely some good points, and I think I can live with it if it means less filesize AND better performance, however unintuitive that is haha! I guess in this case the extra simplicity is detrimental.

TweenMax instances have currentTime, currentProgress, totalTime, etc. properties (TweenLite has a few less). You can use onUpdateListener and a TweenEvent to get to the tween instance through e.currentTarget and then you have access to those currentTime properties.

Here you are. Thanks for taking a look. I left a few comments/instructions in the creationComplete handler in CustomThing.as. What's odd is that in the project I'm working on for work I got different results than this test project I made. The only difference between the two is the PopUpManager.centerPopUp() in this one, versus me manually centering the popup in updateDisplayList(), which is basically the what centerPopUp is doing.

I'm wondering why there is discrepancy in .all() methods and the .to(), .from(), and .fromTo() methods since all of the tweening classes have an emphasis on being light weight. For instance, consider: allTo(targets:Array, duration:Number, vars:Object, stagger:Number = 0, onCompleteAll:Function = null, onCompleteAllParams:Array = null):Array & to(target:Object, duration:Number, vars:Object):TweenMax Since Arrays and Objects are easily cast to one another, couldn't the .to syntax take an array of targets just like .allTo? The stagger, onCompleteAll, and onCompleteAllParams could be included in the vars paramater of the .to() method (the same for .from() and .fromTo() ) I was a little confused why .all() methods had these extra parameters in the first place when they could just be included in the vars object. Just a thought. Interested in hearing other's thoughts on this.

No easing is called "Linear" Tweenlite.to(target, 1, {param:value, ease:Linear.easeNone});

Using tranformAroundCenter inside of a popup created with mx.managers.PopUpManager doesn't seem to be working correctly. Maybe because the parent of a popup created with PopUpManager.createPopUp is mx.managers.SystemManager, and not stage. When tweened, the transformAroundCenter seems to tween normally, as if the calculated registration point was where the actual registration point is (importing, activating everything correctly; no error is thrown when transformAroundCenter:{} is used). Any thoughts?