nicmare

Seems not to restart properly

Recommended Posts

Hi Guys!

I built a sitebar ad and it looks fine except when it restarts. for some reason one animation in Line 142 will be skipped and i really don't know why?!

 

Here is a previewlink: http://tvim.de/as/bwtarif/sitebar.html

 

see source code with comment

// following animation does not restart

source What is wrong here?!

Share this post


Link to post
Share on other sites
 // following animation does not restart
tl.to(heroimage, 3, { x:"+=400",y: "-=100",ease: Power3.easeOut });
tl.to(heroimage, 4, { x:"+=20",y: "-=20",ease: Power0.easeNone },"-=0.5");

Hi,

These two tweens are colliding. Try to put the heroimage into a <div> and tween that container with the second line.

Share this post


Link to post
Share on other sites

Yea, now i found out when i remove "-=0.5" the loop works fine then. But why? I don't understand. 

  • Like 1

Share this post


Link to post
Share on other sites

Because the two tweens trying to move the hero cocurrently. This is why I adviced to put the image into a container. This way You can tween the x: and y: of the image and it's container at the same time.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

i have to admit i don't really understand but thank you very much for the fast response! glad it is fixed. thought it might be a deeper kind of bug… hehe

Share this post


Link to post
Share on other sites

As Oliver pointed out, If two tweens are trying to control the same property of the same object at the same time they will literally be fighting for control and one tween must win.

 

The engine by default kills the pre-existing tween. Once it's killed it can not play again.

 

You can set overwrite:"none" on the second tween to prevent the first tween from being killed.

 

tl.to(heroimage, 3, { x:"+=400",y: "-=100",ease: Power3.easeOut });
tl.to(heroimage, 4, { x:"+=20",y: "-=20",ease: Power0.easeNone, overwrite:"none" },"-=0.5");

 

 

More info on overwrite settings from the TweenLite docs

 

overwrite String (or integer)  - Controls how (and if) other tweens of the same target are overwritten. There are several modes to choose from, but "auto" is the default (although you can change the default mode using theTweenLite.defaultOverwrite property):

  • "none" (0) (or false) - no overwriting will occur.
  • "all" (1) (or true) - immediately overwrites all existing tweens of the same target even if they haven't started yet or don't have conflicting properties.
  • "auto" (2) - when the tween renders for the first time, it will analyze tweens of the same target that are currently active/running and only overwrite individual tweening properties that overlap/conflict. Tweens that haven't begun yet are ignored. For example, if another active tween is found that is tweening 3 properties, only 1 of which it shares in common with the new tween, the other 2 properties will be left alone. Only the conflicting property gets overwritten/killed. This is the default mode and typically the most intuitive for developers.
  • "concurrent" (3) - when the tween renders for the first time, it kills only the active (in-progress) tweens of the same target regardless of whether or not they contain conflicting properties. Like a mix of "all" and "auto". Good for situations where you only want one tween controling the target at a time.
  • "allOnStart" (4) - Identical to "all" but waits to run the overwrite logic until the tween begins (after any delay). Kills tweens of the same target even if they don't contain conflicting properties or haven't started yet.
  • "preexisting" (5) - when the tween renders for the first time, it kills only the tweens of the same target that existed BEFORE this tween was created regardless of their scheduled start times. So, for example, if you create a tween with a delay of 10 and then a tween with a delay of 1 and then a tween with a delay of 2 (all of the same target), the 2nd tween would overwrite the first but not the second even though scheduling might seem to dictate otherwise. "preexisting" only cares about the order in which the instances were actually created. This can be useful when the order in which your code runs plays a critical role.
  • Like 2
  • Thanks 1

Share this post


Link to post
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.