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

Everything posted by Friebel

  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
  16. While creating a codepen thing of another issue with reverse() I am now experiencing while converting projects from gsap 2 to 3 I just bump into another issue which is there when putting a negative timescale value on an endless looping timeline (repeat: -1). What happens? When the timeline loops in normal direction it repeats endless as expected. But when setting a negative timescale to the timeline the timeline stops running after some repeats. Of course this is not what we might expect, as the loop should keep repeating endlessly, only in a different playhead direction. This
  17. The demo you supply now does work in Firefox. The Draggable file you posted before didn't solve the issue by replacing the Draggable on the codepen with the new Draggable, as I wrote above. I think it's a pitty you don't trust me in clearing cache. I'm only a senior developer with over 20 years of experience. But that feeling I'm getting more often here lately. To the point I'm starting to wonder why I still post these bug issues in gsap here.
  18. I just tried the new Draggable you posted by overwriting the Draggable in the codepen, but it still doesn't work in Firefox.
  19. So you want to proof something is running or not running in Internet Explorer and now you make a codepen as a demo? First, to come on this forum in IE11, the Greensock website throws an error in IE11, because it's using 'foreach' which IE11 doesn't support (no offense at all to greensock btw, maybe the site just doesn't support ie11). Than, when clicking through that to visit your demo on codepen, codepen doesn't even run in IE. Not from within this forum and not when we go directly to the site. It tells us it's an 'Unsupported browser' and doesn't show us anything more. Codepen just does
  20. Not sure if this is the problem, but I see at least one line in the Draggable code that doesn't look right: _isTouchDevice = "ontouchstart" in _docElement && "orientation" in _win; Recently browsers have changed. I had to convert all my projects because of that, so that's why I know. We can't do this anymore: if ('ontouchstart' in window) { // has touch } Because 'ontouchstart' is removed in some browsers. I believe that's in chromium, but it might be Firefox (as well?) where it was. Detecting if a browser supports touch events cannot be done
  21. Yes they do. Sorry, what you write just isn't true. Not sure why you really think that. All my interactives run perfectly fine in both IE11 as well as Edge with both touch as mouse, while not using 'pointer'-events. The latter (Edge) even is just Chromium nowadays, so that's not having any problems whatsoever in this area. Really, 'pointer'-events always have been the troublesome kid. Not touch. Nor mouse. BTW, the link you include in your post is from the year 2014... it's 2020 now, so that's 6 (!!) years ago. We all know that that's 99 years in front-end terms.
  22. @OSUblake That's part of the reason in all projects here I removed all 'pointer'-event listeners two weeks ago. I only use mouse events and touch events now. Support for pointer-events always have been troublesome across browsers. Reading the caniuse page, I'm glad I did that! 😀 BTW that was also important for event handling priority order; in all browsers touch comes first and than mouse. So when a user uses touch, we can preventDefault() to prevent the mouse handlers to trigger as well. But when using pointer events, they come even before touch, which messes things up in the fl
  23. I can also confirm that in Firefox for Android 68.5.0 it is still working. I don't know how version numbers go with Firefox cross devices, because on Windows Firefox the latest is 73.0.1 and on my Android device it's still at 68.5.0. I just looked for updates on Android, but Google Play store doesn't show me any updates. So for now this seems to be a Firefox for Windows (and mac?) or desktop only issue. Or maybe the issue is there on Android Firefox 73.0.1 too, but that version isn't released yet?! [edit] I've changed the title
  24. That's what I wrote in the post; Windows. Windows 10. Firefox 73.0.1
  25. Having problems with touch on some projects that are using Draggable I am now diving into this. I'm having problems with touch on both rotating draggables as well as translating draggables on several browsers, but Firefox seems to be the most problematic one. This thread though is about a particular draggable issue that only seem to affect Firefox, while other browsers seem to work fine: The codepen included here is, as you can see, as easy as it can get. A svg circle where Draggable is put on with inertia and rotation. Touch in this example is running fine in browsers like Chrome
×