Search the Community

Hi, Despite what the title says, I'm fairly sure I can't do that, and I'll have to overwrite the tween. But, I'm using a PowerN.easeIn, so the element looks like it's dropping into place, and I've not been able to work out a way of interrupting the tween in a smooth way, it's very noticable... So, can anyone recommend a way to stop a PowerN tween at an arbitrary point, and to create a new tween which would effectively continue the original from where it left off (I can get the remaining duration, but, I'm unable to match the easeIn.) Thanks, Charlie

I don't really understand this: You want to animate something that isn't in view? The warning you posted is if you animate the same properties. That's when an overwrite will occur. If you simply want the first scene to scale and then fade out, a second scene with a new trigger would work fine. They aren't animating the same properties. https://codepen.io/PointC/pen/RzLZyr Happy tweening.

Hello guys, 1st of, I want to say that I did alot of research on this one, and the solutions I found weren't the best, so I was hoping somebody could help me here. I'm also aware that ScrollMagic is not made by Greensock, and that people try to keep forum focused on GSAP, but I had no better place to ask, since scrollmagic issue page is very inactive. I hope you wont mind my question. I use GSAP(TimelineLite) and ScrollMagic to animate element once it gets triggered by ScrollMagic's TriggerElement. And that works fine, if I keep scrolling, element will stay in animated state, unless I scroll up again, way about trigger element, and then the animation will reverse (usually not visible because of tiggerElement position). And then it plays again once i scroll down to triggerElement, this also works fine, just as I wanted. But another thing that I want, is also, when I scroll down past the animated element, I want it to do reverse animation (or just fades out, doesnt matter as it wont be visible since we scrolled out of viewport). And then i want animation to run again once I scroll up. TL;DR: I want animation to play on both, scroll down and scroll up ways, once it is in triggerElement. The solutions I have found: The solutions I found were the make 2 scenes one for animate in and other to overwrite it, however, Jan Paepke said this can be glitchy and not working properly depending how fast user scrolls, and here is his look at this problem: https://github.com/janpaepke/ScrollMagic/wiki/WARNING:-tween-was-overwritten-by-another (My CodePen doesn't have this solution included) Now, this solution is from 2014, and I dont think it's very clean one, so I was hoping that someone can help me find better solution. PS Im also aware that Blake has solution without ScrollMagic, but Im JS noob so I would rather not. Thanks in advance for your time

You'll need to set() it after your resizeBounds function is called because that's where you set the bounds. resizeBounds(true); TweenMax.set(".draggable", {x: 125}); As you have it coded now, that will have no effect because you have this tween in that resize function: TweenLite.from(draggable.target, 0.3, {x:x, y:y}); That would immediately overwrite the set() tween. I just commented out that tween in the resize function so you can see that everything works. https://codepen.io/PointC/pen/LKyraJ You could also used a delayed call for the initial set() if you need to keep that tween in the resize function. (I'm assuming you do, but didn't have time to look through everything in your code.) https://greensock.com/docs/TweenMax/static.delayedCall() Hopefully that helps. Happy tweening.

You have a conflict between two tweens. The second scale tween is starting before the first finishes so you can't get all the way back to the original value because of the overwrite. The easiest solution is to remove the position parameter from the last tween or make it 1.5 so it starts after the first scale finishes. https://codepen.io/PointC/pen/EzBjWq Happy tweening.

No problems! I tried setting the overwrite... overwrite but the problem still seems to be there, i also tried double setting in the begging to be sure that the properties are set video: http://luckyde.com/bugB_1.mp4 I tried setting it to "none" too or having all of the tweens to have overwrite:false with no luck But it still does this bug, as soon as you introduce a second thing to animate it says its value is not a number/freezes Any ideas would be really really appreciated thank you!

First of all, thanks for being an advocate for GreenSock at Zynga! ? And yes, I'm pretty sure that it's an overwrite issue. Try setting overwrite:false on your tween(s) or you could just set TweenLite.defaultOverwrite = false. The plugin you're using doesn't look like it handles the overwrites properly. So every "transform" tween, when it renders for the first time, will kill any other "transform" tweens that are running at that time. See what I mean?

They kind of have to come up with their own transform solution because React Native does not work with actual HTML/CSS. It uses JavaScript to control views of actual native applications i.e. iOS and Android, so there is nothing like getComputedStyle. https://facebook.github.io/react-native/docs/transforms I was just thinking that there might have been an overwrite issue with the way the plugins are written. I remember a 3rd party Pixi plugin having the same issues that Luckyde described. My next guess for the issue would be that the .setNativeProps() calls are overwriting the style/transform objects. But that's just a guess. I've never used React Native. https://facebook.github.io/react-native/docs/direct-manipulation

Yeah, I suspect it could be an overwrite thing or (more likely) mishandling of transforms. We had to do a bunch of work to ensure that all the transform components can be independently animated, plus a whole bunch of other transform-specific challenges. See https://greensock.com/transforms for details. I don't see them handling all that stuff in the "transform" plugin they created, but I'm not very familiar with exactly what they're doing, what constraints there are with native, etc. I must admit it feels a little weird to be spending time troubleshooting a 3rd party plugin that's "borrowing" GSAP's API/code (ineffectively). ?

Ah you were totally right! That is so obvious now that I think about it It's good to know that tweens just overwrite the old ones. I've got the animation working and can keep on tinkering. Thanks a bunch!

I'm not a React guy (@Rodrigo is our resident expert, and he authored that article you linked to), but my guess is that your problem is that you're creating the tween in the componentDidMount(), but then you're playing that same tween again and again in the componentDidUpdate() method. Remember, the first time a tween renders, it internally records the starting/ending values so that it can very efficiently interpolate on each "tick". Your updates are having no effect. Instead of just play()-ing that same tween instance in your componentDidUpdate(), I'd create a new one and feed in the new x/y values. The new tween will overwrite the old one anyway. Does that help at all? If you're still having trouble, it'd help a lot if you provide a reduced test case in codepen or stackblitz or something like that. Happy tweening!

Yeah, I doubt that anyone would notice a performance difference in the real world. I'd slightly favor the clear() approach, though, because it keeps the instances to a minimum and doesn't have to worry about overwrite logic internally. ?

I have a followup question for this: Pedros more elegant solution sets the timeline once and clears it to add new methods. Mine just writes a new timeline on the variable. Is there any difference between the two as far as garbage collection goes, i.e. if you just overwrite the timeline on the variable is the original timeline and it's children wiped out or are they still kicking around hogging resources? // Define timeline once and clear timeline each time var timeline = new TimelineMax(); //set timeline properties timeline.addMethods //reset timeline properties timeline .clear() .addNewMethods // Define New timeline each time //set timeline properties section1MTl = new TimelineMax() .addMethods //reset timeline properties section1MTl = new TimelineMax() .addMethods

Since you have no intrinsic representation of you binary nomenclature, I shall baptize you here as Nine, it will be far easier to type that than 100101110. You'll have to content yourself with a denomination bellow ten as you have not displayed any psionic abilities so far. Firstly well done on solving your own issue. But I have to say: working on a problem while others sleep is cheating. My two cents on you setup are as follows: I think you might be over engineering it a little here. I don't see the need of you having timelines and nesting them onto another timeline. A much simpler setup is to fire out single tweens that callback at their completion a method to line up a fresh new tween. [...] After nearly two hours tinkering with your example pen, it turns out that the issue of the colour not animating back to its original value was a very subtle but annoying overwrite conflict. I'm not sure I will make a good job of explaining here so, forgive me if it causes more confusion than it helps. The issue stems from you adding a tween to an element while it is still being tweened. GSAP will calculate the overwriting values and normally does a great job. Issues arise when the overwritting is happening when not intended - which was your case. As you had a random selector to pick the elements. To simplify your code, I removed the timelines and made all animations run as single tweens. That brought in a new set of issues with the overwriting because of the delay you want these tweens to have. The usual thing to do is to check if the element .isTweening() and do things from there. But! If you have a tween that is delayed, is paused or completed, it reports as not tweening. Sometimes the random nature of this setup meant that you would have a tween that was delayed but the random choice would pick this element again and set a new tween on it with another delay. Eventually, those two delayed tweens would end up matching up and the previously described unintended partial override would occur. The solution I came up with was to not have a delay on the Tween itself but delay the call to the creation of the tween instead, then have the tween play immediately. This way, the tween is either active or not existing at all. See here a fork of your pen with my changes: https://codepen.io/dipscom/pen/OYWQOa?editors=0010 (I changed the animation to make it easier to spot inconsistencier) Now I shall try and get some work done... Else I'll get in trouble.

First of all, welcome to the forums @AnSVG. Looks like a pretty cool animation! It's difficult to pull everything apart and decipher all that code and I don't even really know what I'm supposed to see in that animation, but from your description it kinda sounds like it could be an overwrite issue. If a tween begins that affects a property on an object that's already being controlled by a different tween (so they're fighting over the same property), it kills the other one. Perhaps that's happening here? You can, of course, set overwrite:false on any tween or even TweenLite.defaultOverwrite = false to do it globally, but just beware that'll allow conflicting tweens to persist (and fight). Does setting TweenLite.defaultOverwrite = false resolve things for you?

Correct - one callback for each event type. You can have onStart, onComplete, onUpdate, etc. But if you create a second one for an event, it will overwrite the first.

It's very difficult to troubleshoot blind, but it sure sounds like you've got an overwriting problem. You're probably creating tweens that overlap and fight each other for controlling the same property of the same object at the same time. By default, that kills the overlapping piece of that tween. You could set overwrite:false in any of your tweens, or event TweenLite.defaultOverwrite = false, but be very careful about that because it's generally a bad idea to create competing tweens like that to begin with. Actually, even the code snippet you provided shows that you've got competing tweens. For example: .to('#wheel2', 0.4, { y: -6 }, 0.5) .to('#wheel2', 0.1, { y: 0 }, 0.7) //<- this starts halfway through the previous tween! Notice the duration of that first tween is 0.4 seconds, but it's positioned at an absolute time of 0.5 in the timeline. Then, you position ANOTHER tween of the same property of the same object at 0.7 seconds into the timeline...which is overlapping the other tween by 0.2 seconds. That will cause the 2nd tween to overwrite (kill) the previous one. If you still need help, please provide a reduced test case in a codepen so we can see what's going on and we'd be happy to help.

Thanks for taking the time to reply. I'll do some more testing and look into the overwrite and sandbox options.

Hm, I'm not sure what to say for that first issue. I wonder if it's maybe an overwriting thing(?). Have you tried setting overwrite:false on those tweens? I'm totally guessing. It's super difficult to troubleshoot blind like this, but I can't think of anything that's specific to those plugins that'd be causing issues. I'd also be curious to see what happens if you make sure you're loading/embedding DirectionalRotationPlugin and FramePlugin in ALL sub-loaded swfs. Like, perhaps sub-loaded ones are hijacking the com.greensock.* namespace. I think there are ActionScript settings you can toggle to ensure that each SWF is sandboxed to avoid anything like that, though I can't quite remember the details. Nah, there's no limit on durations. 1800 should be fine. Happy tweening!

hi, so no one has an idea? how to fix the choppy animation on an iMac 27" (chrome and firefox, safari is supersmooth)? I have taken a screenshot where you can see that it goes down to 8fps... the related code snippets this.el_inner.addEventListener('wheel', e => this.wheel(e), { passive: false }) deltaY(e) { let deltaY = 0 if (e.wheelDelta) { deltaY = -e.wheelDelta } if (e.deltaY) { deltaY = e.deltaY } if (e.deltaMode === 1) { deltaY *= 40 } return Math.round(deltaY) }, wheel(e) { e.preventDefault() const scrollTo = this.scrollTo + this.deltaY(e) this.raf('move', scrollTo) }, move(scrollTo) { // remove over and under scrolling this.scrollTo = Math.max(0, Math.min(scrollTo, this.maxScroll)) if (this.innerTweenID) { this.innerTweenID.kill() } this.innerTweenID = TweenMax.to(this.el_body, 1, { y: -this.scrollTo, ease: Power4.easeOut, overwrite: 5, force3D: 'auto', onUpdateParams: ['{self}'], roundProps: 'y' }) }, //raf is a mixin raf(cb, e) { if (this.rafID) { window.cancelAnimationFrame(this.rafID) } this.rafID = window.requestAnimationFrame(() => this[cb](e)) demo there code -> https://codesandbox.io/s/1z86xjl6q3 full window -> https://1z86xjl6q3.codesandbox.io/ I also tried to animate a nullObject und set the transform onUpdate, but doesn't solved the problem this.innerTweenID = TweenMax.to(this.nullYObject, 1.2, { y: this.scrollTo, ease: Power4.easeOut, overwrite: 5, force3D: 'auto', onUpdateParams: ['{self}'], onUpdate: tween => { const scrollTop = Math.round(tween.target.y) this.el_body.style.transform = 'translateY(' + -scrollTop + 'px) translateZ(0)' } }) gregor

it's smooth on my imac though I don't have a retina display. Maybe in the full code you've got some kind of throttling added that I'm not seeing but if I'm interpreting it correctly your code appears to create a new tween and overwrite the previous every time the event listener sees a delatY change. Maybe you could refactor it to throttle the number of tween calls and pass the dynamically changing deltaY to the tween in a modifiers function? Not sure if that would work better but it seemed logical to me. Also you're doing a lot of console logging and writing the changing deltaY to a data item, these would also probably be slowing down execution.

Hi, I've created a smooth page scroll. That is the shortened code this.el_body.addEventListener('wheel', e => this.wheel(e)) scrolling() { console.log('--- scrooolling') }, wheel(e) { e.preventDefault() let deltaY = e.deltaY // firefox if (e.deltaMode === 1) deltaY = 40 * e.deltaY this.raf('move', deltaY) }, move(delta) { TweenMax.to(this.el_body, 1, { y: -this.scrollTop, ease: Power2.easeOut, overwrite: true, force3D: true, }) } Sometimes on macOS Chrome the animation becomes choppy, I played a little bit around and figured out that if I add onUpdate: () => this.scrolling() it becomes much more smoother. The function only outputs a log. My Question ist does onUpdate something more behind the scenes? Or am I just imagining it?

I see, I understand and thank you for providing the information on the overwrite field!

Ah yes, that's just because I added a 1 second delay (because I thought it looked better) to that handle appearing, so if you click too fast, it's possible to have the fade-out tween start BEFORE the fade-in one starts. It's just a timing thing. But it's very easy to fix - you just add overwrite:true and that basically tells the engine to find any other tweens of that element and kill them. I adjusted the codepen accordingly. Better?

In that case you could try forcing he images elements to a opacity of 0 using the config object available in the .tween methods of TimelineMax. The sweet part of it is that GSAP has a killer overwrite manager that will detect any other lingering GSAP instance that affects the images, kill them and send them to garbage collection. You could try something like this: tl.tweenFromTo(t, "b", { onStart: function() { TweenMax.to(images, 0.1, {opacity: 0}); } }); That will tween the opacity to 0 very quickly on all the images when the timeline playhead starts moving to the "b" label. Happy Tweening!!