jamiejefferson

Currently your functions are really 'updateAllChannels' and 'stopAllSounds'. The click is just a side effect of stopping a sound, and since you are stopping 37 sounds at once, the click is probably even more noticeable. TweenLite.to (soundTransforms[i], 1, {volume:0, onUpdate:updateChannel, onUpdateParams:[i], onComplete:stopSound, onCompleteParams:[i]}); function updateChannel(index:int=-1):void { if (index >= 0) { soundChannels[index].soundTransform = soundTransforms[index]; } else { for (var i:uint = 0; i < soundChannels.length; i++) { soundChannels[i].soundTransform = soundTransforms[i]; } } } function stopSound(index:int=-1):void if (index >= 0) { soundChannels[index].stop(); theButtons[index].mouseEnabled=true; soundTransforms[index] = new SoundTransform(1); } else { for (var j:uint = 0; j < soundChannels.length; j++) { soundChannels[j].stop(); theButtons[j].mouseEnabled=true; soundTransforms[j] = new SoundTransform(1); } } } index is also an optional parameter, which won't break any 'updateAllChannels' / 'stopAllSounds' functionality if you were using that. Good luck with your program, it sounds pretty interesting.

onUpdate needs to be passed a function reference, so that it can store said reference and call the function on every update. If you invoke a function by using () parentheses, what gets passed instead is the function's return value. Think of onUpdate being defined the same way as the callback for addEventListener. TweenMax.to (object, 3, { x:200, onUpdate:trace("x: " + object.x + " y:" + object.y) } ); // trace doesn't return any value, so the onUpdate function doesn't get set. // Only one trace. TweenMax.to (object, 3, { x:200, onUpdate:trace } ); // trace is a function reference, so the onUpdate will call trace(). // Multiple empty traces. TweenMax.to (object, 3, { x:200, onUpdate:trace, onUpdateParams:["x: " + object.x + " y:" + object.y] } ); // trace() is called with the same parameters each time as the parameter is evaluated immediately and stored for repeat use. // Multiple identical traces. Solution: function tracePosition(obj:DisplayObject):void { trace("x: " + obj.x + " y:" + obj.y); } TweenMax.to (object, 3, { x:200, onUpdate:tracePosition, onUpdateParams:[object] } ); // desired functionality. tracePosition is called on each update, the parameter 'object' is passed each time, and the function reevaluates the position to trace each time it is called. // Multiple unique traces. Solution 2: TweenMax.to (object, 3, { x:200, onUpdate:function() { trace("x: " + object.x + " y:" + object.y); } } ); // an anonymous function could be used instead

This is a very simple tween: TweenLite.to(target, duration, { z:value } ); If you need to scale the object with more than just z positioning, you can just add the required properties to the tween properties object. TweenLite.to(target, duration, { z:value, scalex:value2, scaleY:value2 } ); I suggest you have a look at this to get a good basis for how Greensock tweening works.

This is one of those situations where you might consider whether it would be easier to create a class for 'cards' that could store their initial x position, and perhaps functions for mouseevent animations. You can always use name to store an index if necessary. var allCards:Array = [ [card1, card1.x], [card2, card2.x], [card3, card3.x] ]; // index 0 is the card, index 1 is that card's "initial x" for (var i:Number = 0; i < allCards.length; i++) { allCards[i][0].addEventListener(MouseEvent.MOUSE_OVER, overhandler, false, 0, true); allCards[i][0].name == "card" + i; // card1 will get the name card0, etc, but this is the index in allCards we want later. You can +1 the value if you'd prefer } function overhandler(e:MouseEvent):void { if (accordionAnimating == false) { var i:int = int(e.target.name.substr(4)); // (-1 if you added 1 to the index in the card names) var _posX:Number = allCards[i][1] - 8; TweenMax.to(e.target, .5, { x:_posX, ease:Linear.easeNone, yoyo:true, repeat:1 } ); } }

Ok all your tweens are doing exactly what they are supposed to do. The items are moving at a uniform rate, and so is the road. The reason the road appears to move at different speeds is because it has a 3D rotation on it. When you rotate the road around the x axis, part of the road extends away from the 'camera' into the distance, and this area will appear to 'squash' the road above the rotation point. The further away a point is from the camera, the more the road is 'squashed'. This is what gives the linear motion of the road the appearance of changing speed. I'm not an expert at flash's 3D transforms, so unfortunately I don't have a direct solution. You could try positioning the items in '3D' space ( object.z ) and tweening the z value to bring the item closer to the screen. Your road seems to have an odd rotation point though, so you might need to refactor it to get the whole thing working that way.

Glad you figured it out. That solution still uses relative values though, which means if you rollover the clip multiple times a second, it's going to animate off the left of the stage. I don't know what your project entails but is that desired? If you want to keep card1 from running away you should put var _posX:Number = card1.x; outside the function and animate to x:_posX - 10. Also, instead of using an oncomplete function just to reverse the tween, you could use yoyo and repeat with a TweenMax to do the same thing. TweenMax.to(card1, .5,{x:_posX, ease:Linear.easeNone, yoyo:true, repeat:1}); // this will reverse 'onComplete'

Are the start y and end y values always the same? I guess we would need to see some code. A sample .fla would also be a great help, especially if the road animation is in a MovieClip's timeline animation.

import com.greensock.*; right.addEventListener(MouseEvent.CLICK, fl_ClickToGoToNextFrame); function fl_ClickToGoToNextFrame(event:MouseEvent):void { nextFrame(); TweenLite.to(square_mc, 1, { y:String(-10) } ); // OR TweenLite.to(square_mc, 1, { y:"-10" } ); } When tweening to a value with type 'String', the value will be calculated relative to the target's current position. If square_mc is currently at y:100, then tweening to y:"-10" will be calculated as y:90. Then when square_mc is at y:90, tweening to y:"-10" will be calculated as y:80 etc. However, this will have a small problem if the user clicks quickly, as square_mc could be in the middle of tweening, eg y is currently at 94, in which case the next tween will be calculated to y:84. I'm assuming this is not desired? In this case, store the y value in a variable, so that absolute y values can be used. import com.greensock.*; right.addEventListener(MouseEvent.CLICK, fl_ClickToGoToNextFrame); var square_mc_Y:int = square_mc.y; function fl_ClickToGoToNextFrame(event:MouseEvent):void { nextFrame(); square_mc_Y -= 10; TweenLite.to(square_mc, 1, { y:square_mc_Y } ); }

That maths give the following results: xAngle = 233.68645203778343 yAngle = 89.99999999999999 So all your code will do is move fireBallCrashed from its current (x,y) position to (233.7, 90). No matter how you work out these angles, that is always going to be a direct line between the two positions. If you are after a z-axis transform, ie animate from smaller to larger, there are a few different transforms you can use for this. scaleX, scaleY fireBallCrashed.scaleX = 0.5; // default = 1 fireBallCrashed.scaleY = 0.5; // default = 1 timeLineFireBall.insert(TweenMax.to (fireBallCrashed, 4, { x:xAngle, y:yAngle, scaleX:1, scaleY:1 } )); This will give the appearance of fireBallCrashed zooming towards the screen, and in most cases should be pretty performance efficient, assuming fireBallCrashed is a reasonably optimised DisplayObject. z fireBallCrashed.z = -100; // default = 0 timeLineFireBall.insert(TweenMax.to (fireBallCrashed, 4, { x:xAngle, y:yAngle, z:0 } )); This will apply a Matrix3D transformation to the object, which uses a 'camera' to work out perspective giving the illusion of a 3D space. This tween will look different to a scale tween as the position of fireBallCrashed is relative to the 'camera' and the 'vanishing point'. A DisplayObject with a Matrix3D transform applied will also affect some filters and Greensock plugins. This will probably perform worse than a 2D scale as well.

import com.greensock.easing.*; card1.addEventListener(MouseEvent.ROLL_OVER, overhandler); card1.addEventListener(MouseEvent.ROLL_OUT, outhandler); var _posX:Number = card1.x; var _posY:Number = card1.y; function overhandler(e:MouseEvent):void { if(accordionAnimating == false){ TweenLite.to(card1, .5, { x:_posX - 10, ease:Cubic.easeOut } ); } } function outhandler(e:MouseEvent):void { if(accordionAnimating == false){ TweenLite.to(card1, .5, { x:_posX, ease:Cubic.easeOut } ); } } Don't define variables at the function level if you want to access them in other places. Any variable defined inside a function is only accessible within the life of that function (as soon as the function has completed, all of it's local variables are destroyed). If you want card1 to just shift 10 pixels back and forth, then you will need to store its original location outside of a function so it can be referred to. You can definitely have a rollover and rollout with card1 staying where it is supposed to, and no glitches. var _posX:Number = card1.x -10; // function level variable - defined every time the tween is created TweenLite.to(card1, .5,{x:_posX, ease:Cubic.easeOut}); } This tween uses what is essentially a 'relative' value. Wherever card1 is currently located, it will move 10 pixels left from that position. If you call this code multiple times, card1 will eventually animate off the left of the stage. // _posX defined as a class or global variable - defined at runtime and never changed TweenLite.to(card1, .5,{x:_posX - 10, ease:Cubic.easeOut}); } This tween uses an 'absolute' value. As long as _posx isn't changed, card1 will always move to 10 pixels left of its original position. Even if you call this code multiple times, card1 will never move further than 10 pixels left of its original position.

Removes tint from all other buttons: function tint(event:MouseEvent):void { for (var i =0; i < buttonArr.length; i++) { TweenLite.to(buttonArr[i], 1, {removeTint:true, ease:Expo.easeIn}); } TweenLite.to(event.currentTarget, 1, {tint:0xff0000, ease:Expo.easeIn}); // overrides the tween from the loop that would remove this tint. } OR to just remove tint from the home_btn: function tint(event:MouseEvent):void { TweenLite.to(home_btn, 1, {removeTint:true, ease:Expo.easeIn}); // there's no harm in calling removeTint when no tint is applied TweenLite.to(event.currentTarget, 1, {tint:0xff0000, ease:Expo.easeIn}); }

Since you've provided no example of either code or the HTML, there is no way to understand what is happening, or even if this problem relates to TweenLite. Please provide any relevant sample code and HTML that could illustrate why this behavior would occur. A sample .fla file would be even better.

Simple. Don't useFrames=true if you want your tween to run over a precise duration. If useFrames=true, and you define a tween with a duration of 72 frames, it will finish in 72 frames regardless of the time that takes. If Flash runs at 1fps during this tween, it will reach frame 72 in 72 seconds. Every frame of your animation will play, but it's timing is reliant on Flash's frame rate. If useFrames=false (the default), and you define a tween with a duration of 3 seconds, it should finish in precisely 3 seconds regardless of frame rate. TweenPlugin.activate([FrameLabelPlugin]); TweenLite.to(mc, 1, {frameLabel:"myLabel"}); // tweens from the currentFrame to myLabel in 1 second Look in the API for more information about the frame plugins: http://www.greensock.com/as/docs/tween/ It's trivial to calculate the distance from the current frame to another frame and convert that to seconds yourself var labelFrame:int = getFrameByLabel("end"); var duration:Number = Math.abs(mc.currentFrame - labelFrame) / 25; Look here for a getFrameByLabel function: http://stackoverflow.com/questions/4846858/as3-simple-way-to-get-the-frame-number-of-a-frame-label

Ok I've had a look over your sample, and you were right, the *first problem is related to where the 'point' is calculated from. Creating a point from mc.mouseX is going to be an x position on the stage (I think, or it may be the tween target's parent?) and not to the actual x position of the mouse within 'mc', etc. eg. Let's say mc is a square of 200 x 200 and the stage is also 200 x 200. To center the clicked point, that point needs to be moved to (100,100) on the stage. What your code is currently doing: * mc is at (0,0) on the stage and is clicked at (50,50) within mc. * The tween will transform around the point (50,50) on the stage, which is (50,50) on mc, which will give the desired result. * mc should now be at (50,50) on the stage which would put mc's (50,50) point at (100,100) on the stage. Centered! * mc is clicked at point (100,100) within mc, which we want to move mc back to (0,0). However, the tween will transform around the point (100,100) on the stage, which is only (50,50) on mc at this point. mc will stay put, since (50,50) is already centered. There is an extra setting in transformAroundPoint, pointIsLocal:true, which takes the position of the target into account when transforming. * Now, when mc is at (50,50) and is clicked at point (100,100) within mc, the tween will transform around the point (150,150) on the stage. This is (100,100) on mc, which will now move to (0,0) on the stage. Centered! However, there is still a problem using stage.width and stage.height. These values are dynamic, and are essentially a bounding box for all content of the stage. When mc is moved such that it hangs off the edges of the window, stage.width and stage.height change to accommodate this, throwing the values off. If you want to use the visible stage width and height, use stage.stageWidth and stage.stageHeight. The third problem is that stage.stageWidth and stage.stageHeight also change if the window is resized. Store these values in a variable rather than access them directly. var sw = stage.stageWidth; var sh = stage.stageHeight; function zoomIn(event:MouseEvent):void { //center on click TweenMax.to(mc, .25, {transformAroundPoint:{point:new Point(mc.mouseX, mc.mouseY), pointIsLocal:true, x:sw/2, y:sh/2}}); } Finally, good luck with adding zooming as well. I just finished a project where I had to create exactly this functionality, and I thought it was quite challenging, especially using a resizable stage. Unfortunately, I can't give away all my secrets

I too had this problem recently. As soon as you edit an object's 3d properties (z, scaleZ, rotationX, rotationY, rotationZ), a matrix3d is created for that object. Unfortunately, the motionBlur plugin does not work on objects with a matrix3d. You need to remove any 3d transformations from an object every time you run a 2d transformation with motionBlur: tl.append(TweenMax.from(firstWord.red, 0.4, { x: -450, motionBlur:enabled, ease:Back.easeOut, onStart:remove3d, onStartParams:[firstword.red] } ), 1.0); tl.append(TweenMax.to(firstWord.red, 0.3, { rotationY:90, visible:false, ease:Linear.easeNone, onComplete:remove3d, onCompleteParams:[firstword.red] } ), 0.5); function remove3d(object) { object.transform.matrix3D = null; } If you are running this timeline other than just with .restart(), you will need to remove the matrix3d anytime you jump to a position within the first tween. I'll leave this to you how to implement. * Edit var tl:TimelineMax = new TimelineMax({paused:true, repeat:-1}); Thought I'd mention that repeat:-1 will have the same effect as your onComplete callback.

I don't really have the time to optimize 300+ lines of code, but in flash, most bottlenecks for fullscreen/higher resolution performance are a result of the flash renderer, and not your actionscript code anyway. Since you are sliding a large graphic around the screen, this is going to force flash to redraw the entire screen every frame (you can see what is being redrawn if you load the swf in Flash Player Debugger and press CTRL+E [show redraw regions]). My thoughts: * Check out '2) Speed tips' at http://www.greensock.com/tweening-tips/ * You should do some profiling and determine if significant slowdown is actually caused by the time your actionscript computations are taking. * Since you only seem to be adjusting z position to get a slight zoom effect, have you considered just using scaleX and Y for this effect? the z property introduces a matrix3d into the object, and from my experience, working with the '3d' (z, scaleZ, rotationX, rotationY, rotationZ) properties is slower to render than simple 2d transformations. * The effect runs very smoothly on my computer. Perhaps the real performance bottleneck has more to do with the extra features (bg music and rollover etc) rather than this animation? The frame rate will drop if there are multiple objects with filters/alpha/3d properties etc added; especially if they are animated and/or placed inside the masked object... Your effect is looking nice at the moment, good luck with your optimisation.

Without an example, your blurry images could be caused by placing the image on sub-pixel co-ordinates or using smoothing when the image is scaled. myimage.smoothing = false; myimage.pixelSnapping = "auto" // only applies when image is at 100% scale // or myimage.pixelSnapping = "always" http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/Bitmap.html#pixelSnapping Other than that I guess an example is needed.

If the volume is not tweening, have you made sure to include the line: TweenPlugin.activate([VolumePlugin]); Other than that suggestion I'll have to leave it to someone more familiar with LoaderMax. * Edit: Just realised that volume is activated by default for TweenMax. Ignore me...

TweenLite.from(bubble, 1, {delay:1.5}); You have not actually defined any properties to animate here, so this line will do nothing. And, if you have indeed already animated this bubble on the timeline in Flash Pro, then you are first going to want to stop it's animation from playing at the beginning. bubble.parent.gotoAndStop(1); and instead of TweenLite.from(bubble, 1, {delay:1.5}); TweenPlugin.activate([FramePlugin]); function onFinishTween3():void { //bubble.visible=true; TweenLite.to(bubble, 1, {frame:bubble.parent.totalFrames, delay:1.5}); // tweens the pre-existing animation over 1 second } or, you could just use regular timeline animation without the need for a tweenlite: function onFinishTween3():void { //bubble.visible=true; TweenLite.delayedCall(1.5, animateBubble); } function animateBubble() { bubble.parent.gotoAndPlay(1); }

Here's a test file I created for you to consider. http://www.2shared.com/file/R2gmUZq7/test.html As far as I can tell your new code will have the same problem with relative values as before, as right_arrow.x+50 will be relative to the position right_arrow is at when either ROLL_OVER or ROLL_OUT is triggered. You can see this demonstrated in the first arrow in the attached file. The second arrow uses this same method but stores the original position of the right_arrow so it can be animated with absolute values. There was a problem with my previous 'Timeline' code, as I was confused about how you wanted the animations to look (kinda wrote it on the spot without any testing). Having the -0.3 offset in the timeline was causing some problems. The third arrow in the example has a fixed version representing this method. Hopefully some of this will apply to your project. If you follow the chain of event adding / removing you had for hovering buttons: addListener(ROLL_OVER), // 1 event listener active trigger ROLL_OVER event, // 1 event listener active removeListener(ROLL_OVER), // 0 event listeners active wait for animation to finish, // 0 event listeners active addListener(ROLL_OUT), // 1 event listeners active trigger ROLL_OUT event, // 1 event listeners active removeListener(ROLL_OUT), // 0 event listeners active back to start. If any of the ROLL_OVER / ROLL_OUT events that you would like to respond to occurred during times when there were no listeners active, or when only the alternate listener was active, then you're going to see effects like that. Dynamically changing event listeners, especially for MouseEvents, is always going to cause trouble from my experience. I would definitely recommend setting up event listeners once and leaving them active until the buttons they are attached to are no longer required. In fact, you might even consider using a single set of event listeners on the stage, and basing any further action on the target of that event.

I would follow Carl's advice to use an invisible hit box if there is a chance the button will move out from underneath the mouse. You may also find the following code works easier than trying to add/remove event listeners on every event. right_arrow.buttonMode = true; right_arrow.mouseChildren = false; right_arrow.addEventListener(MouseEvent.ROLL_OVER, btn_over); right_arrow.addEventListener(MouseEvent.ROLL_OUT, btn_out); var tl:TimelineLite = new TimelineLite({paused:true}); tl.append(TweenLite.to(right_arrow, 0.8, { x:right_arrow.x+50, scaleX:2.5, scaleY:2.5, ease:Elastic.easeOut }) ); tl.append(TweenLite.to(right_arrow, 0.5, { x:right_arrow.x, scaleX:2, scaleY:2, ease:Elastic.easeOut }),-0.3 ); function btn_over(e:MouseEvent):void { tl.play(); } function btn_out(e:MouseEvent):void { tl.reverse(); }

Same error here. For the time being, the following should run a 'from' tween without error var tvar:TweenLiteVars = new TweenLiteVars(); tvar.prop("x", 300).runBackwards(true); TweenLite.to(mc, 1, tvar); **EDIT** I thought I'd have a look into the greensock code; see what was going on. The static .from() method is throwing the error at: vars.runBackwards = true; because it's returning the runBackwards() method of the TweenLiteVars object, instead of the runBackwards property of the TweenLiteVars property _vars. Any references to vars in the .from() function will not access vars' properties correctly if vars is not a generic object public static function from(target:Object, duration:Number, vars:Object):TweenLite { vars.runBackwards = true; // fails here with TweenLiteVars if (!("immediateRender" in vars)) { vars.immediateRender = true; } return new TweenLite(target, duration, vars); } Changing the from() function in com\greensock\TweenLite.as [line 605] to the following will fix the problem (also present in TweenMax.as [line 821]). public static function from(target:Object, duration:Number, vars:Object):TweenLite { if (vars.isGSVars) { vars = vars.vars; } vars.runBackwards = true; if (!("immediateRender" in vars)) { vars.immediateRender = true; } return new TweenLite(target, duration, vars); } Anyone please feel free to tell me if this is not the most ideal way to fix this. I've been using greensock for a few years now, but this was the first time I've actually looked into this amazing code.

Assuming you have your eventListeners sorted, you should have no problem using the following: TweenLite.to(list_mc, 0.75, {x:"15"}); // right TweenLite.to(list_mc, 0.75, {x:"-15"}); // left (you may or may not want to set an 'overwrite' value if you are allowing list_mc to be moved multiple times) Hope that helps

This works perfectly, thanks a bunch.

If title_mc is interfering with your event, you may want to try one or more of the following settings: btn_mc.mouseChildren = false; title_mc.mouseEnabled = false; This will prevent both title_mc and any interior movieclips of btn-mc from firing events, which should hopefully leave just the actual ROLL_OVER and ROLL_OUT events for btn_mc. When I create button transitions, I find it's easier to add the event listener to a parent movieclip of the buttons, or even the stage, and use functions similar to these: function mouseover(e:MouseEvent):void { if ( e.target.name == "button1" || e.target.name == "button2" || e.target == btn_mc || ) { TweenMax.to(e.target, 0.25, {alpha:1}); // rollover animation } } function mouseout(e:MouseEvent):void { if ( e.target.name == "button1" || e.target.name == "button2" || e.target == btn_mc ) { TweenMax.to(e.target, 0.25, {alpha:0.5}); // rollout animation } } This way you can have a consistent transition effect on multiple buttons, and only 1 place to make any changes.