Share Posted January 31, 2019 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?! Link to comment Share on other sites More sharing options...
Share Posted January 31, 2019 // 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. Link to comment Share on other sites More sharing options...
Author Share Posted January 31, 2019 Yea, now i found out when i remove "-=0.5" the loop works fine then. But why? I don't understand. 1 Link to comment Share on other sites More sharing options...
Share Posted January 31, 2019 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. 1 1 Link to comment Share on other sites More sharing options...
Author Share Posted January 31, 2019 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 Link to comment Share on other sites More sharing options...
Share Posted January 31, 2019 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. 2 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now