Search the Community

Dear GSAP community, I’ve a question about an ‘overwrite’ feature and some timeline time aspects. If I set an animated parameter without changing the time, it works pretty well! Example: https://codepen.io/belyanskii/pen/vYLBZQE But once I am trying not only to set (or change) an animated parameter but to set delay and duration, overwriting doesn’t seem to occur: https://codepen.io/belyanskii/pen/XWXrgQy Is there a way to overwrite the whole animation w/o clearing or deleting the tweens/timelines?

Hey Trapti. Thanks for the clear demo. The reason why the leave doesn't work is because of you're using a setTimeout to delay the parallax effect for 200 ms. So the mouseleave does happen, just before the last parallax tween. I'm not sure why you're using a setTimeout... That's because of your .in ease. Every time it updates it creates a new tween and .in eases are slow at the start, hence it appears slow. I'd just use the condensed string form and say ease: "sine" which defaults to an out ease. I also recommend using overwrite: "auto" for that tween to kill off old tweens. Another reason why it appeared slow is because of the setTimeout. Another side note is that you don't need quotation marks for numerical values like 0. Here's a fork with those changes: https://codepen.io/GreenSock/pen/oNbvYOM?editors=0010

If you have multiple animations affecting the same properties of the same elements at the same time, there is no working around it There simply will be conflict, likely causing issues. A value simply cannot be two different values at the same time. Ways to work around that are to Use overwrite: 'auto' so that tweens will kill off tweens that they conflict with. Apply animations to a container or child instead of the element it would conflict with. Rewrite the animations to combine their effects into one animation. It sounds like you're using the first approach I outlined above.

The biggest issue here is that you're using a .from() in the second timeline. Let's look at what happens when your pen initiates: createRowAnimation fires: All of the cubes are given width:0 and height:0 immediately due to the .from(). When the timeline is ran, it will animate each cube's width and height from 0 to the default value. createColAnimation fires: All of the cubes are given width:0 and height:0 (again) due to the .from(). When the timeline is ran, it will animate each cube's width and height from 0 to 0. This is because the value before the .from() is called is already 0 due to the first timeline! Thus to fix the issue, use .fromTo() like Craig said or (what you likely want in this case so that they can overwrite each other more easily) use a .set() and then a .to(). https://codepen.io/GreenSock/pen/abvKyVW?editors=0010

Hi! I'm sorry, but I have some issue with mouseleave, in demo as you can see image with overlay is not dissapearing, if I make tl.reverse() on mouseleave everything is fine, but I need my timeline to hide everything immediately. What am I doing wrong?

Are you on Windows and do you mean with a mousewheel? If so that makes sense because it's immediately setting the value. You could switch out the quickSetters for .to() tweens and it'd be smoother I'd bet. Make sure to set overwrite to 'auto' if you're going to do that. Glad I could answer it before it was even asked

Hey chevohin and welcome to the GreenSock forums! Good question. The answer is that each time you click, you're creating a new animation. And the tweens in that animation are relative, meaning that they go from the current value to the provided value. So when you click mid animation, it uses the current value (instead of the starting value) as the new starting point and thus it isn't what you're expecting. To fix that issue, there are several solutions. Potentially the best is to create an animation outside of the click event and use control methods inside of the click event to manipulate it. Here's an example of that: https://codepen.io/GreenSock/pen/mdeOMQJ?editors=0010 You could also use .isActive() and an if statement to prevent the jumping. if(!snowmanHandsUpTl.isActive()) { snowmanHandsUpTl.play(0); } Another alternative is to use .fromTo() tweens which enforce a particular start value with overwrite: 'auto' in order to kill off the previous tweens but that's less performant and not necessary here. Note that I'm using GSAP 3 formatting. I think you're really enjoy and benefit from my article on tips to animate efficiently. Let us know if you have more questions. I'd love to see the end result of what you make!

Hey Roman. By default, GSAP does not kill off tweens that affect the same properties of the same objects. If you want that to happen, you should set overwrite: 'auto' (or true) for the tweens that conflict. Alternatively, change the property globally: gsap.defaults({overwrite: 'auto'}); However, in your case it might make more sense to setup a timeline for the hover transition when the JS is initialized. Then on mouseenter you play it, on mouse leave you reverse it.

Thanks for the explanation. I think I understand what you're wanting to do. I think the key error is that your code above doesn't really handle overwriting well. What I mean by overwriting is when two animations are both trying to control the same properties of the same elements. There's conflict because you're telling it to be two values at the same time. The easiest way to handle this in your case is to change GSAP's default overwrite value from false to 'auto'. That will cause tweens to kill other tweens that it's in conflict with. You can change that setting globally by using gsap.defaults({overwrite: 'auto'}); Alternatively you could apply overwrite: 'auto' to just the tweens that could into conflict. Some other improvements you could make: Use GSAP 3's new syntax (no need for TimelineMax, TweenMax, etc.). Put the duration inside of the vars parameter so you can use defaults. Chain tweens on the timelines (I think it helps make it more clear that they are all on the same timeline). Just use scrollY for the scrolling position. All that put together: https://codepen.io/GreenSock/pen/XWbGavp?editors=0010

Thanks for the extra clarification. I had tried doing a similar tactic setting my animation to a variable but I didn't have any overwrite settings. I had tried so many things that I thought should work but didn't so I just started trying everything else I could think of. Alas... adding the overwrite parameter was not one of them. I am guessing I won't forget that little tidbit now. Sometimes the best way to learn is to get burned. #scalded

If you look in the docs for the gsap object, you will see that no method called .kill() exists for it. Only .killTweensOf() exists on the gsap object. However, if you look at the Tween docs or Timeline docs you will see that they have .kill() methods. So in order to use .kill(), it has to be used on a Tween or Timeline reference itself. Thus you could rewrite your first pen like so: https://codepen.io/GreenSock/pen/poJYgvY?editors=0010 Notice that I also set overwrite: 'auto' on each tween so that new tweens kill off previous tweens that conflict. Both can be used whenever you need to kill an animation. .kill() is more useful if you have a direct reference to the animation. .killTweensOf() is useful when you don't have that.

I wasn't sure if you just wanted a very simple "jump to the speed" effect or something more advanced like gradually changing speeds, but here's the simplest approach: https://codepen.io/GreenSock/pen/50f4d16dcbb7acd8f85e540e8a4e2011?editors=0010 Notice we're just reusing the same tween instance and just altering its timeScale. You could certainly do it other ways too. Rodrigo is using a more advanced thing for the "off", but I think there's an easier way even for that. But before I dive into that, I want to confirm that's what you want. Oh, and @Rodrigo I wouldn't recommend accessing the _gsap stuff directly like that. Just use the built-in getProperty() which automatically returns a number anyway (unless you declare a unit): // OLD (bad) currentAngle = parseFloat(box._gsap.rotation.replace("deg", "")); const finalAngle = endAngles[Math.floor(currentAngle / 90)]; // NEW (good) currentAngle = gsap.getProperty(box, "rotation"); const finalAngle = gsap.utils.snap(90, currentAngle); Oh, and @Greg Stager remember that the default overwrite mode is "false", so tweens won't automatically overwrite each other. You were creating infinitely repeating tweens on every click on the same property of the same object. That's probably why you weren't seeing it stop - you had a bunch of tweens running on that same object. You can set overwrite: true on your tweens or even set gsap.defaults({overwrite: "auto"}) to have the engine auto-sense conflicts like that and kill just the parts that overlap. Also, if you want to kill all the tweens of a particular object, check out gsap.killTweensOf(). In your case, gsap.killTweensOf("#box"). Oh, and @Rodrigo here's a fork of yours with InertiaPlugin doing the magic of stopping the spin: https://codepen.io/GreenSock/pen/25d4fed9370f27e03a0f5627be73ae5d?editors=0010

Ah, DynamicProps was way back from the ActionScript days Typically you could just recreate the tween each time the "target" object moves to a new position (and don't forget to set overwrite: true or overwrite: "auto" so that the previous one is killed). But if you need a single tween instance so that it definitely ends after a certain amount of time and the ease gets adjusted on-the-fly, I whipped together a helper function that you can feed into a modifier, as demonstrated here: https://codepen.io/GreenSock/pen/1ed6118d993bac95e12d3236cc836f9e?editors=0010 Notice when you drag the red dot, the blue will start animating there no matter where you move it, and it'll always end up exactly on top of it after 5 seconds (the duration of the tween). Of course when the tween ends, it doesn't keep following it. Helper function: // the "getter" can be a function with your own logic OR you can pass in another target whose property should be copied. function getDynamicProp(prop, getter) { let ratio = 0, result, initted, copy, unit; if (typeof(getter) !== "function") { copy = (typeof(getter) === "string") ? document.querySelector(getter) : getter; getter = () => gsap.getProperty(copy, prop); } return function(value, target) { if (this.ratio !== ratio || !initted) { let end = parseFloat(getter()), factor = (this.ratio == 1 || ratio == 1) ? 0 : 1 - ((this.ratio - ratio) / (1 - ratio)); if (!initted) { unit = typeof(value) === "string" ? gsap.utils.getUnit(value) : 0; initted = true; } result = (end - ((end - gsap.getProperty(target, prop)) * factor)) + unit; ratio = this.ratio; } return result; }; } Usage example: gsap.to("#box", { x: "+=1", // these values don't matter - we'll override them with modifiers. These are placeholders. y: "+=1", duration: 5, modifiers: { x: getDynamicProp("x", this.target), y: getDynamicProp("y", this.target) } }); You can define your own getter functions if you want. This isn't an "official" plugin or solution or anything, but hopefully it gets you what you need. Thanks for being a Club GreenSock member! 🙌 Does that help?

If I understand your question correctly, there are many ways to do this... 1) gsap.isTweening(CONTAINER) - that's an easy test to see if GSAP is currently animating a particular object. 2) Store the tween in a variable, and then check its isActive() value. There are several others, but I don't want to overwhelm you. My bigger question is WHY do you want to know if it's tweening? If your goal is to have the new tween overwrite the old one, all you need to do is set overwrite: true on the new tween. That'll immediately kill all other tweens of that same target.

@GreenSock Hi, Jack! I forgot about overwrite mode. Can you tell me is there a big difference fromTo between GSAP v2 and GSAP v3? I created exactly the same code using gsap v2 and there fromTo not working like in your code. https://codepen.io/ChicagoJostik/pen/MWwGepr

The main problem is that in your mouseleave, you did a clearProps tween but you did NOT stop the other tween that was affecting the same element (from the mouseenter). The default overwrite mode in GSAP 3 is false. So all you need to do is set overwrite: true on that tween and it'll find any other tweens of that same element and immediately kill them. As for your timeline not working, you had the values inverted (you were going from height: "auto" to height: 0). And instead of doing a separate set() call and then a to(), you could just combine those into a fromTo(). Your way wasn't "wrong", it's just more verbose. Here's a fork with the corrections: https://codepen.io/GreenSock/pen/89082759e2f311dce8bb350cf740e939?editors=0010 Does that clear things up?

Hey aok. I think you're overcomplicating things. I'd just use some tweens and make sure the tween for the hovered link has overwrite applied to it: https://codepen.io/GreenSock/pen/jOPabqd?editors=0010

Hell yeah! Thanks for the ultra fast (and spot on!) response. I hope you don't mind me asking, as I don't want to just straight paste your code and I'd love to understand it better: What is the overwrite parameter used for? I couldn't see any changes after setting it to false. (line 29 spinningWheel.js) Is the (!rotation.current) (line 14 spinningWheel.js) check the solution for the animation not pausing? As in, every time I was pausing before, I was actually starting a new animation? Why does a change like this break timeScale?

A few things: You loaded GSAP 3.2 but Draggable 3.1. I definitely recommend loading the latest of both. Your old GSAP one loads a SUUUPER old version. CDNJS stopped supporting "latest" many years ago. You've got throwProps/inertia enabled which means it'll create a tween onRelease but you ALSO created a [conflicting] tween at the same time. The default overwrite mode in GSAP 3 is false. You have to opt-in to overwriting. If you want it to automatically find (and kill) conflicting tweens, just set overwrite:"auto" on your tween(s) or do it globally like: gsap.defaults({overwrite:"auto"}); Does that clear things up?

I tried it with setting the gsap.defaults({ overwrite: 'auto' }) (and also setting it to overwrite: false, just to have tested that, but both don't make any difference. [edit] I have just narrowed the issue to the real issue here as it looks like: using transformOrigin on the original svg element (a circle) still needs the same calculation in v3 as in v2, so is unchanged. But after cloning that element with cloneNode(false) and setting transformOrigin on the clone (even when cloning before setting the transformOrigin to the original) has a different behaviour in v3 vs in v2. So for the original element needs to be set with const pointOriginTransform = wheelCenterY - pointCenterY + pointHeight * 0.5; But the clones of that element (which I created before setting this transformOrigin) behave differently, eventhough they are appended to the same <g> and need to be set with: const pointOriginTransform = wheelCenterY - pointCenterY; (So without adding the element's circle radius). So for some reason there is a difference between the original element and the cloned element.

Most of what you said didn't make much sense to me (not that you didn't write clearly - I'm just saying that GSAP 3 didn't suddenly change to using the center of SVGs as the default transformOrigin or any of the other "changes" you noticed). Like Zach said, the only thing that sounds like it MAY be the cause of some confusion in your project is just the shift from overwrite: "auto" to overwrite: false but that'd only come into play if you wrote conflicting tweens originally. Plus it's easily "fixed" with gsap.defaults({overwrite: "auto"}). Does that resolve things in your project? And yes, transformOrigin is always supposed to have two values separated by a space. And no, GSAP doesn't do any cloning of nodes internally, nor does it do anything "destructive" that I can think of. I'm super curious to see a demo of this. Can you please provide one that shows the different behavior in v2 vs v3? I can't reproduce any of this in GSAP 3, so I'm really struggling to figure out why you're experiencing that and I suspect there's something else at play in your app that's causing the problems but it's super difficult to troubleshoot blind. I know you said you'd work on a reduced test case. I sure appreciate your efforts in that regard, as I realize it takes some time. We can be patient.

GSAP 3 stripped out a little bit of complex string parsing but most of it has been added back. I think this might be case where support should be added back? @GreenSock can give us his thoughts. I don't see this in testing. GSAP 3: https://codepen.io/GreenSock/pen/KKpNVQw?editors=0010 GSAP 2: https://codepen.io/GreenSock/pen/rNVWxJM?editors=0010 Can you please try to make a reduced test case of this? That doesn't make much sense - GSAP doesn't have a cloning method so I'm not sure how it could be related. Are you sure that it works differently than v2? Again, a minimal demo would be incredibly useful. Cloning an element with properties set via GSAP seems to work fine in my tests. My only guess given the lack of details is that it could possibly be related to the change in the default overwrite value and the tweens are in conflict. The new default is false while the old one was "auto". I hope you can get these issues sorted soon! We'd love to fix any bugs that exist, the sooner the better

Using the smoothOrigin parameter in the gsap.defaults method (gsap v3.1.1) throws an error in the console: gsap-core.js:83 Invalid property smoothOrigin set to false Missing plugin? gsap.registerPlugin() These are my defaults: gsap.defaults({ overwrite: 'auto', smoothOrigin: false, }); I tried this with and without importing and registering the CSSPlugin, but there's no difference. Inside both the migration guide as well as the docs on CSSPlugin I see 'smoothOrigin' written like that. And I even copied the exact property just to be sure I didn't have a typo. But it doesn't matter, the error persist. I also tested the defaultSmoothOrigin property of the CSSPlugin directly. Setting the defaultSmoothOrigin property directly in the CSSPlugin doesn't throw an error, so at first glance it looks like that works, but that's because Javascript is just adding defaultSmoothOrigin as a new property to the CSSPlugin object there, as I can't find any 'defaultSmoothOrigin' property inside the CSSPlugin code and when printing CSSPlugin.defaultSmoothOrigin to the console without setting it the console shows 'undefined'. So this doesn't seem to work either: CSSPlugin.defaultSmoothOrigin = false; So somehow the gsap defaults() method doesn't seem to recognise the smoothOrigin property and the CSSPlugin.defaultSmoothOrigin property seems to be unavailable. Is this perhaps a known issue of the latest version, or inside the documentation and migration guide? or am I missing something here? https://greensock.com/docs/v3/GSAP/CorePlugins/CSSPlugin

Oh, I see. He didn't technically overwrite them. If the previous animation lasted longer than the new animation, it might look a little funky like here. Notice how the box goes left, then right, and then left at the very end. That is because both tweens are running at the same time. https://codepen.io/osublake/pen/0fe81acc740a083c2ddd79564e193d03 You can fix that by setting overwrite to "auto" or true. https://codepen.io/osublake/pen/68b5c9b50e61179474629f74f680c605 Or kill the first animation. https://codepen.io/osublake/pen/e02f232f003a8e2fc26b27a31003bd2f The same technique would work for timelines. Tweens and timelines are interchangeable for the most part.

For projects I was working with a pretty old version of Draggable (with Throwpropsplugin), so I decided to upgrade these to the latest v3 ones from the latest Club Greensock. I found out I had to rename ThrowPropsPlugin to IntertiaPlugin and so now I use inertia: true inside a rotating draggable config. But both morphing and draggable (rotation) are somehow not working as before. What I'm experiencing now is that in whatever browser I use (Firefox / Chromium type browsers) the interaction (both mouse and touch) with the rotating draggable is not working right anymore, which was working fine in v2 with the old pluginversions; when rotating the disc it's rotating all over the place. Sometimes it suddenly reverses direction and even moves the other side in an instant. BTW I replaced the full gsap folder inside node_modules by the one from the Club Greensock zip (v3.1.1) This is how I initialize: import { gsap, CSSPlugin, Draggable, InertiaPlugin, Linear, Sine, Back, } from 'gsap/all'; gsap.registerPlugin(CSSPlugin, Draggable, InertiaPlugin, MorphSVGPlugin); gsap.defaults({ overwrite: 'auto' }); This is how I config the disc: gsap.set(this.wheel, { transformOrigin: '50% 50%' }); Draggable.create(this.wheel, { type: 'rotation', inertia: true, dragResistance: 0.005, edgeResistance: 0.01, }); So it seems like the new plugins (of coarse I also switched to gsap v3 and its new syntax, using npm and webpack btw) for some reason need a different approuch, have different value-ranges or something like that. Reading through the migration page on Greensock I don't see anything so far about this and looking at the parameters of the new plugins on the Greensock website on v3, I don't see much difference either. The methods and parameters I use still seem to be the same. Also things are wrong now with the locations of elements inside the svg. These elements are animating still, but seem to have a much smaller position-delta (scale) then before. I thought maybe this was about the transformOrigin, but it doesn't seem to be changed in v3. Weird. BTW I'm working with SVG here and all other code and the graphics (svg) are not changed. [edit] the draggable direction change (and suddenly moving in reverse direction) seems to be happening on a quart of the wheel only, the other 3 quarts seem to work as expected while dragging, but this quart moves in reverse. As if there is a problem with the angle-calculation there. I thought replacing gsap and the plugins to the new v3 would be effortless and would almost be compatible in terms of API, but I seem to be missing something here. Before spending a lot of time in creating a smaller project with this, could anybody perhaps tell me if there is something I need to know according to the migration to v3 and Draggable and why this is not working as before? Are perhaps things changed like value-ranges?