Jump to content
Search Community

TweenMax - Overwrite Confusion

ukla test
Moderator Tag

Recommended Posts

TweenMax V11

 

If I call the "moveContent" function while the object (_holder.content_mc) is still tweening (x property) the onComplete function is called twice.

 

The TweenMax documentation states:

2 (AUTO): (used by default if OverwriteManager.init() has been called) Searches for and overwrites only individual overlapping properties in tweens that are active when the tween begins.

 

Why doesn't this work? I am tweening the x property of _holder.content_mc ... therefore the tweening of the x property is "overlapping" and should be overwritten.

 

If I substitute "overwrite:3" for "overwrite:2" it works perfectly.

 

OverwriteManager.init() 

private function moveContent(position:Number):void
{
    var currentx:Number = _holder.content_mc.x;
    var speed:Number = Math.abs(position - currentx)/500;
    TweenMax.to(_holder.content_mc,speed,{x:position,overwrite:2,ease:Quad.easeInOut,onComplete:moveTagDown});
}

Link to comment
Share on other sites

Are you sure the x property isn't getting overwritten? Keep in mind that in AUTO mode, entire tweens aren't overwritten - just individual overlapping tweening properties (like "x", "y", etc.). So the onComplete would still fire. Some developers rely on that functionality and don't want the callbacks to get killed just because a tween's properties get overwritten.

Link to comment
Share on other sites

The x property is getting overwritten visually on the stage. Meaning ... _holder.content_mc arrives in its proper x position.

 

But clearly something is running in the background because onComplete is being called twice at different intervals. Make sense?

Link to comment
Share on other sites

Are you sure the x property isn't getting overwritten? Keep in mind that in AUTO mode, entire tweens aren't overwritten - just individual overlapping tweening properties (like "x", "y", etc.). So the onComplete would still fire. Some developers rely on that functionality and don't want the callbacks to get killed just because a tween's properties get overwritten.

 

So are you saying that despite the "x" property being overwritten that the onComplete function isn't being overwritten?

 

The "x" property is the ONLY property I am tweening on this object ... ever.

Link to comment
Share on other sites

So are you saying that despite the "x" property being overwritten that the onComplete function isn't being overwritten?

 

Yes, exactly. AUTO mode only overwrites overlapping tweening properties, but the tween itself continues to run and fires any necessary callbacks/events. This is by design. Imagine if you had a tween that you want to run and then after it finishes, it must call another function to continue the flow of your application. If Another tween began for that object which is unrelated to that logic, it would break the flow of the application. I can actually see solid arguments on each side of this one (some would expect that if a tween doesn't have any properties that it's continuing to tween, it should be stopped and deleted), but seeing as how the additional logic necessary to inspect the tween would slow things down a bit and add a little kb, I have opted thus far to keep the current behavior. Either way I go I think there will be folks that disagree, so I go with the least expensive option in terms of performance and file size. I'm open to being convinced otherwise, though :)

Link to comment
Share on other sites

So what is my option then? Do I use "overwrite = 3" since that works?

 

And please explain WHY this works. I don't see any difference between "overwrite = 3" and using AUTO in my particular example.

 

It would be sweet to have something like: TweenMax.removeTweens(_holder.content_mc,{x}); ...

Link to comment
Share on other sites

CONCURRENT mode (3) will kill ALL tweens of the same object (regardless of whether or not properties overlap) that are running at the time the tween begins. AUTO will only overwrite individual properties of those tweens (and allow the tweens themselves to live).

 

 

So I take it that "kill" and "overwrite" are different things? In my example the object only has a single property being tweened and overwritten. So why would AUTO behave differently than CONCURRENT? They are both overwriting individual properties of the tween - a single x position tween. In AUTO, why would a tween continue to "live" when it is the tween that was just overwritten?

 

In your opinion, what should I use in this particular case?

Link to comment
Share on other sites

Yes, as I tried to explain above, there are reasons why the tween should be allowed to continue to "live" even if it doesn't have any tweening properties (like application logic depending on onCompletes/onUpdates firing, etc.). So AUTO only concerns itself with overwriting individual overlapping properties of tweens. It does NOT also look to see if there are no tweening properties left after overwriting the individual properties and then kill the whole tween if it doesn't find any. Think of it like this - AUTO only affects individual properties whereas CONCURRENT affects the entire tween.

 

It sounds like in your case CONCURRENT is working for you, so just use that. :)

Link to comment
Share on other sites

Sorry to continue probing you about this topic. But I still need further clarification on using the OverwriteManager class.

 

How do the secenarios below differ? According to the documentation 1 (ALL): (this is the default unless OverwriteManager.init() has been called)

 

Scenario 1

I initialize OverwriteManager >> OverwriteManager.init(1)

 

Scenario 2

I don't initialize OverwriteManager.

 

Wouldn't the above scenarios be exactly the same? By not initializing OverwriteManager I would be in default mode which is b]1 (ALL)[/b]. Correct?

Link to comment
Share on other sites

Nope, I think you read the documentation wrong - it says ALL (1) is the default mode for TweenLite but AUTO (2) is the default mode in TweenMax. TweenMax automatically inits OverwriteManager in AUTO mode (if you didn't already init it in a different mode). Make more sense now?

Link to comment
Share on other sites

Nope, I think you read the documentation wrong - it says ALL (1) is the default mode for TweenLite but AUTO (2) is the default mode in TweenMax. TweenMax automatically inits OverwriteManager in AUTO mode (if you didn't already init it in a different mode). Make more sense now?

 

Uh ... don't think so ... looks like your docs are wrong.

 

post-4939-133151999989_thumb.jpg

Link to comment
Share on other sites

Yes, exactly. AUTO mode only overwrites overlapping tweening properties, but the tween itself continues to run and fires any necessary callbacks/events. This is by design. Imagine if you had a tween that you want to run and then after it finishes, it must call another function to continue the flow of your application. If Another tween began for that object which is unrelated to that logic, it would break the flow of the application. I can actually see solid arguments on each side of this one (some would expect that if a tween doesn't have any properties that it's continuing to tween, it should be stopped and deleted), but seeing as how the additional logic necessary to inspect the tween would slow things down a bit and add a little kb, I have opted thus far to keep the current behavior. Either way I go I think there will be folks that disagree, so I go with the least expensive option in terms of performance and file size. I'm open to being convinced otherwise, though :)

 

Honestly, it would be much better if the onComplete function was terminated if the tween is overwritten. At the very least it should be optional.

 

For example, say I called "movePanel(100)" and then called "movePanel(300)" again after three seconds. The object (panel_mc) would still be tweening when "movePanel" was called the second time. That is fine because the object moves to the appropriate x position. However, the onComplete function is fired twice. There is absolutely NO way to stop this if the object has more than a single property being tweened simultaneously!

 

private function movePanel(position:Number):void
{
 TweenMax.to(panel_mc,6,{x:position,ease:Quad.easeInOut,onComplete:moveComplete});
}

 

Since the overlapping property (x) is overwritten, its onComplete call should be overwritten too. This is how Tweener works and for good reason.

 

There has to be some sort of solution here ... maybe I am just missing it.

Link to comment
Share on other sites

One possible solution is to use variables.

 

function moveContent(position:Number):void
{
var currentx:Number = panel_mc.x;
var speed:Number = Math.abs(position - currentx)/500;
if (_paneltween){
	_paneltween.removeEventListener(TweenEvent.COMPLETE, tweenFinished);
}

_paneltween = new TweenMax(panel_mc,speed,{x:position,ease:Quad.easeInOut});
_paneltween.addEventListener(TweenEvent.COMPLETE, tweenFinished); 
}

function tweenFinished(e:TweenEvent):void 
{
trace("tween finished!");
} 

 

At least this gives me more control than using onComplete. Sigh.

Link to comment
Share on other sites

Okay, I figured out a way to accommodate your request without adding much kb or processing requirements to OverwriteManager. After mulling it over and chatting with some folks, it seems to make sense to kill the tween if there aren't any more tweening properties, especially since the algorithm doesn't require as much processing power as originally anticipated. I'm sure I'll get a few complaints from folks who may be relying on their onCompletes to fire regardless, but hey, I can't make everyone happy, right? :) Please download the latest v11 and give it a shot. http://blog.greensock.com/v11beta/

Link to comment
Share on other sites

YOU ARE THE MAN.

 

I sincerely appreciate the fact that you took the time to address my concern ... and did so in a thorough, considerate manner.

 

I truly belive that you made the correct decision and that it will ultimately prove to be beneficial to all.

 

Many thanks,

Craig

Link to comment
Share on other sites

Glad to help, Craig. I really try to be open to the community's input on this stuff because a lot of great ideas come that way. As you can tell by the version number, it's a growing and evolving platform. I put a lot of effort into making it better. Thanks again for the suggestion.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...