Jump to content

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

RolandSoos last won the day on January 18 2019

RolandSoos had the most liked content!


  • Posts

  • Joined

  • Last visited

  • Days Won


RolandSoos last won the day on January 18 2019

RolandSoos had the most liked content!

About RolandSoos

Recent Profile Visitors

3,206 profile views

RolandSoos's Achievements

  1. You are right, it really works as expected with your suggested change.
  2. Thanks, but I do not see how your logic applies for this example: https://codepen.io/mm00/pen/jOmLgRd With this line tl.invalidate().progress(1, true).time(t, true);we are at the end of the animation as t is equal with the totalDuration of the timeline. Then we pause and seek back to 0 with the line tl.pause(0). Should I invalidate here again jump to progress(0) and progress(1) and back to progress(0) again? My problem is that the playhead is at the end and then I move the playhead back to the start and GSAP is not redering the changes.
  3. Jack, any suggestion for this case? It is similar to the original. The difference that I invalidate when the playhead is at the end of the timeline and then trying to seek back to the start point. My opinion is that the red box should be at x:600 when the last timeout ends, but it stucks at x:0 https://codepen.io/mm00/pen/jOmLgRd
  4. I see your point. I think there would be an optimized way to make my suggestion work: When invalidate({...}) called with my option: If playhead is inside a tween -> If start or end value is a function or arithmetic string ("+=100"), initialize the tween again and render its current state If playhead after a tween (tween is at progress === 1)-> If end value is a function or arithmetic string ("+=100"), initialize the tween again and render its current end state If playhead before a tween (tween is at progress === 0)-> If start value is a function or arithmetic string ("+=100"), initialize the tween again and render its current start state
  5. Thank you Jack! Maybe it would be great to have an option on invalidate method, like: .invalidate({ immediateRender: true // default is false }) When immediateRender would be set to true, GSAP would render all tweens on that timeline at the current playhead (even if that tweens come in the future).
  6. Well, my trick do not work, if the tween has a delay https://codepen.io/mm00/pen/jOmLXxQ?editors=1010
  7. In the following example, the x starting point a function which returns the value where should the tween start from. I use function as I have a variable which might change for some events and when this variable changes, I can inform the timeline with the .invalidate() to evaluate the function again for the new value. The problem is that when the timeline is paused, this invalidate is not working and the new values are not rendered. The expected behavior for me that the red box is jumping on the X axis when the random number changes. Using tl.time(0.000001); instead of tl.time(0); solves this issue, but maybe you have a better solution for this case.
  8. That's a good idea. The only problem what I see that if the playhead is exactly at that position and you seek back, your function is not called again, so you have no chance to reset. https://codepen.io/mm00/pen/zYoLXrX
  9. The problem is that I'm developing a software where a lot of things are possible and there is no way to know everything about the environment (normal/hover colors and such.) This is why I tried to use clearing properties with .set() on the timeline as it would guarantee in this case that the HOVER works as expected. Right now I feel the need for a feature like: tl.call(function(isSeekingBack){ if(isSeekingBack){ // remove background and style } else { // add background and style } })
  10. It's a 1 second duration timeline as the .set's position arguments is 1. I made a real world example which shows my problem: https://codepen.io/mm00/pen/xxRJMbR It's a typewriter effect with text selection and removal effect. Also it should change the background and color on HOVER when the animation is not in the selection part. The HOVER on the first part of the animation only works on the first run. The second run is not clearing the properties, instead is uses the cached values. You can emulate this by commenting "tl.play();" and uncommenting the two lines lines at the same time: tl.progress(1); tl.progress(0.3);
  11. Thanks @ZachSaucier! Your suggestion works with limitation: if you seek to progress 0.1, the color property is still RGBA(0,0,0,0) https://codepen.io/mm00/pen/eYBjLVw I let this case go, I think it is not possible currently what I really need.
  12. Thanks @ZachSaucier! I tried it, but your suggestion is not working: https://codepen.io/mm00/pen/VwmBjZR?editors=1010 There is no onUpdate call, when I'm seeking backward.
  13. My next idea is to try this with attributes. Unfortunately it is not working In this case the attribute value becomes "0" https://codepen.io/mm00/pen/yLVqOxV?editors=1010
  14. I tried this, but in this case instead of the empty string, it always resets to #ffffff; gsap.config().stringFilter = function(){ return false; };
  15. There is a timeline with a set. The set is changing a property in the object and the value of the property is empty string. When we jump to the end of the timeline, the color property set to #ffffff, but when we jump back to .progress(0), the value become RGBA(0,0,0,0). It seems like GSAP tries to interpret the target value as color and decides to use RGBA(0,0,0,0) as the original value. I think in this case GSAP should reset the value back to empty string on .progress(0).