Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

Friebel last won the day on December 24 2018

Friebel had the most liked content!

Friebel

Members
  • Content Count

    168
  • Joined

  • Last visited

  • Days Won

    1

Friebel last won the day on December 24 2018

Friebel had the most liked content!

Community Reputation

88 Contributor

About Friebel

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male

Recent Profile Visitors

4,591 profile views
  1. @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-ins
  2. 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.
  3. 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' projec
  4. 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 do
  5. 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 sa
  6. 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
  7. @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?
  8. @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 thin
  9. @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.
  10. 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
  11. @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 dissapoin
  12. 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 neg
  13. 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 th
  14. 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 t
  15. 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
×