Friebel

@GreenSock Jack, I'm very dissapointed right now. The beta version where you had fixed this issue was working fine, but in the released 3.2.5 version (both the standard npm version as well as the bonus package) there are new bugs again which are even worse: making the reverse not doing anything anymore and even crashing the full animation with stutters and flahses and all. I cannot even describe it. This is definitely not a caching issue of pnpm or any other issue here besides gsap. I removed all the pnpm cache, removed the node_modules folder, removed the pnpm lock-file and re-installed everything. But still the released gsap 3.2.5 is having issues that weren't there in the beta version. I even stepped away from pnpm for this project completely just to be sure this is not an issue of pnpm or windows, and went back to npm, which is reliable for years and never let me down. So removed the full node_modules folder of the project and re-installed everything from scratch in this project with `npm install`. With this I am absolutely sure the new gsap package is installed inside the project and this isn't some cache thing. After switching back to the beta everything works again. So it's definitely an issue in the released 3.2.5 version. What's the use of supplying a beta version to test if things are changed for the worse in the release?? Last weeks I found a lot of nasty bugs in the lib to a point I really wonder if you even test the lib as these issues are so on the surface. You call these rare cases every time I report one, but I highly doubt these are rare cases. To be honest I am really getting tired of debugging gsap now and I am done with it. I reverted to the beta version and go look for alternatives. Maybe build a lib myself. That cost me way less time than continues debugging a library I even pay for and by people expecting me to debug issues in the lib they created. Sorry to say, but I pay for gsap to not having to build it myself and don't need to do this myself so I have time to focus on other things, but this costs me so much time and money now to a point I would have created an animation-lib myself for the things I need. I have other things to do and I'm debugging these issues for weeks now. Sorry to say, but it seems like quality control is not what I was used to with greensock. Which is a shame. I feel very dissapointed and I already know how you would react to this. Which makes it even worse. I'm done

Hi @GreenSock Jack, I ran this code to view the gsap.version and it stated 3.2.4. Which is weird and makes me worried a little bit, because I definitely installed the latest beta version you sent me with success (the console also ended with 3.2.5 installed) and even tested the installed version number afterwards by running `pnpm list gsap`, which showed 3.2.5. Crazy. I now removed the full node_modules folder and did a install from the package.json again. Now it works with no problem. So this was indeed some crazy pnpm cache problem. You say you are confused, but I am as well now. This makes no sense to me. Last week I switched from npm to pnpm (and also than removed the node_modules folder and re-installed everything, but with pnpm), which is not copying the same modules to every project, but uses things like symlinks for optimization and re-use of modules so it doesn't have to download the same modules everywhere. I wonder if we can fully rely on pnpm and/or if it has something to do with some nasty explorer/win10 issues I'm facing like freezing and sometimes not refreshing explorer-windows since the 2 latest windows 10 updates. My system is clean, secure and fully up to date for sure. Hope that Microsoft will fix these issues soon, as I'm not the only one having these or that I can find a way to somehow solve this or work around myself. But not sure if that's related to this caching issue. Guess I can at least not trust the pnpm install to always work. And not even the pnpm list command obviously. Crazy. On the other hand, a week or two ago I had also a caching problem with npm and gsap, as we found out in these forums. Before that I never experienced any caching issues with npm or yarn and I'm using these for years now. So I'm confused. So I guess I need to always remove the full node_modules folder now and than running an install, just to install something new to upgrade, which is definitely not the way it should be obviously. Not sure what's causing this. Sorry for this inconvenience. Obviously the 3.2.5 beta fixes the original issue. Thanks for your time and pointing me to gsap.version. That's a nice one to know. Glad it is fixed now in 3.2.5 and guess it's safe to release.

You already have it. It's in this thread already. I even created both an example using gsap v2 as well as an example using gsap v3. This already IS the demo. What else do you need? As said, in my project I'm doing the exact same thing as done in the example here. The only thing I changed is the update eventhandler, as you did in the changed codepen. But I've checked everything several times now and can't get it to work with the tgz-file you supplied. Eventhough the code should be exactly the same as in the codepen. But, as said, the only difference is that in the 'real' project I'm using a position in the play() and reverse() methods to play from. Are you sure that should also work with the latest beta? I see the minified javascript file (gsap.min.js) inside the tgz package you've sent is the same as the one you use in the codepen. But are you sure also the tgz package contains exactly the same individual module files as well as used in the minified js you use in the codepen? As I'm importing via webpack imports and don't use the minified file. Also please keep in mind this project worked for years with all gsap v2 versions. I see you only changed one thing (the ctrl update function) in the example. So that should also be the only thing I need to change in the real project to make it work in v3 as per logic, I'd think.

Thanks for the tgz file. Unfortunately this is not fixing the issue in the project here. Still weird things happen with the reverse. The first time reversing is okay, so something has changed, but all next times I press the button to reverse it moves forward again. There is a difference between the simplified codepen I posted and the code I'm using in the actual project though; and that is that in the codepen I just use play() on the animTl without parameters, but in the actual project I add a position to play from. [edit] This was just a quick test. At the moment I don't have much time to dive into this further. So I'm not sure if I'm missing something that I need to check or change in my code or that the new gsap is still having an issue in reverse when using a position parameter in the play() and reverse() methods. But wanted to give you already this information above.

So if I get what you're saying there's only one timeline of one second in your example. And when the totalTime progresses internally the totalTime gets recalculated to a position on the one second timeline, either by moving forward or moving backward, depending on the current state of the yoyo repeat: forward or backward. Do I get that right? If so, why wouldn't that be possible with an endless loop (repeat: -1) where yoyo is false and the timeline is playing in reverse? Isn't that the same as repeating the backwards part of a yoyo loop? So to explain this in your example, let's say we're setting the one second timeline now to { repeat: -1, yoyo: false } and playing it in reverse with reverse() or timeScale(-1). I don't really understand why the inner workings of a timeline progression would be handled differently for non-yoyo loops vs yoyo-loops. Wouldn't it be possible to calculate the totalTime internally to a position on the reversed timeline as well? So like the yoyo internal re-calculation, but now running in backwards state when timescale is below 0 and forward state when timescale is above 0?

Ah, that clears things up Great extra catch! Thanks a lot for this! ? That really helps! I'm sure it won't affect many peoples code in a negative way, because when someone found and uses timeScale I think they also know what they're doing and will understand and be glad with this decision! I'm using gsap via npm and webpack, so to test the minified version in the actual project I have to change the structure too much. So as I've seen it working in the codepen, I just wait for the upcoming release and use it via npm. Looking forward to this next version! Thanks again for the quick action!

@GreenSock Thanks a lot for this great in depth explanation Jack. I understand your challenges. Out of curiosity: how do you do it with yoyo than? Or does yoyo work because when it is reversing it always have played once?

@GreenSock I created two codepens. One where I use gsap v2 and one in which I use gsap v3. These simplified demos show the issue I'm facing right now after upgrading. As you can see the animation is perfectly working in version 2, but the expected reverse when hitting the 'OUT' button is not working in version 3 with the exact same code. As you can see in the second demo (using gsap 3) the box is not moving back, but forward when hitting the 'OUT' button. BTW, I wasn't talking about right or wrong or smart/stupid, but about consistent logic vs inconsisant logic and thinking for a developer that uses the lib vs trusting developers and giving them freedom. Seems like my point didn't come across. Demo with gsap 2: https://codepen.io/Friksel/pen/oNXqdKp Same demo with gsap 3: https://codepen.io/Friksel/pen/bGdvYrR

@GreenSock Alright, just looked inside the project and unfortunately resume() isn't a solution here, as I need to play from a labels position with play('label'). So unfortunately the issue persists. [edit] Would it be possible to ad an optional function parameter to resume() to be able to set the timeline position to resume from? Just like in the play() method? So without that parameter resume() works as it does now (as I understand it is like play, but except from the logic to reset the timescale/direction), but can be used with a resume-position (like a label) as well.

Alright, just looked inside the project and unfortunately resume() isn't a solution here, as I need to play from a labels position with play('label'). So unfortunately the issue persists

@ZachSaucier Thanks for pointing to that thread. Also here, as written in another thread I just reacted, I think the same; I am a little dissapointed that the same logic doesn't apply everywhere and that the libs obviously thinks for itself and makes the decission for us developers in that something is 'wrong' and corrects it automatically. I don't really like that as we might not be wrong in doing something, but do it on purpose. As in this case. The use case I use this in I described above. And I think that's a pretty great reason to make a zero timescale work. So I am dissapointed about these decisions. [edit] BTW, if there are people that on purpose wet a timeScale to 0 and than expect the playhead to move when setting play() and complain if it doesn't move then those are not great developers to begin with. On the other hand I do think that if you set a timescale to 0 you might expect the playhead to stay still when using play() and are allowed to complain if it changed the timescale by itself and moves the playhead, eventhough the developer set the timescale on purpose to zero. That said, like I wrote in the other timeline, I will try if resume() is a solution for the issue I'm having in this project now.

Thanks for your response @GreenSock Jack. Reason I'm coming with these issues is because things related to reverse a timeline direction as made on gsap v2 don't work anymore in v3 (it doesn't reverse). So now I'm figure out why and find these sub issues. I don't really like it when a lib thinks for me on what should happen, to prevent a 'mistake' for me and therefore gets out of the way of other logic as how it is build. I would say that if play() respects the height of the timeScale value, what it does rightnow, than it would be logical to also respect it if a value is zero or negative. When that's not the case I understand it could prevent some problems for other people, but it can also cause issues when things are not working as expected, because it's not using the same logic in every case. So now that's error prone to people understanding the logic, because the logic is not the same everywhere. I would in these cases chose for the same logic everywhere and trust developers on their responsibility a little more. That said; resume() could be a nice alternative though in this case. I will try that out

When timescale is set to 2 and we call play() directly after that, play() respects the value of timescale and plays twice the speed. When timeScale() is set to 0 and we call play() directly after that, play() doesn't respect the value of timescale and resets timescale to 1 and plays. To me this is not logical and inconsistant behaviour. I would expect the play() method to always respect the timeScale() value and never change it. So if we set a timeScale to zero, we do that on purpose. If we than call play() after that we do that on purpose also, because we would like to put the animation in play-mode, but for example like to tween the timeScale in to go gradually from 0 to 1.

When setting a negative timescale to let play() play in the reverse direction, the play() method resets the direction and always plays forward. I understand the difference between play() and reverse() and that play() is there to normally play forward and reverse() to do play in the reverse direction, but when setting a negative timescale the whole thing should reverse in my opinion. So if we set a negative timescale and run play() I would expect the play head to play from the current position backwards and reverse() from the current position forwards. The way I would expect this to work: - set the timescale to a negative value to run the thing backwards when play() is called: - on a call of play() just play the direction that is currently set; so backwards - on a call of reverse() play the animation in the reversed direction, which is forwards in this case, as the timescale is set to a negative value

I just edited my post and see your reaction now telling what I just saw, so that was a crosspost You state this is expected. But it's not expected at all to me and doesn't make sense to me either, so I don't agree with you. We tell a timeline to repeat endlessly, so it should repeat endlessly. No matter the direction it's running in. In my world an endless loop means endless loop. Independent of a direction. Just look at how yoyo loops work. Also endless yoyo loops, runing back and forth, run in two directions and never stop. To me this is really an issue in the lib the way it is now.