Jump to content
GreenSock

Asored

Arguments in the MotionPathHelper function are ignored

Recommended Posts

Hi! As the documentation says, we can pass arguments to the `MotionPathHelper.create()` function. But all arguments are getting ignored for some reason. I've tried it also in your official example from the documentation page. Are there any breaking changes in the new MotionPathHelper version that require me to pass the arguments differently than what the documentation says?

See the Pen yLjpEwW by asored (@asored) on CodePen

Link to comment
Share on other sites

I'm not seeing anything broken - can you please provide a minimal demo that shows the problem very clearly? The one you provided appears to work correctly but maybe I'm missing something. 

Link to comment
Share on other sites

15 hours ago, GreenSock said:

I'm not seeing anything broken - can you please provide a minimal demo that shows the problem very clearly? The one you provided appears to work correctly but maybe I'm missing something. 

 

Hi GreenSock! I've simplified the example removing the astronaut :-)

See the Pen yLjpEwW by asored (@asored) on CodePen

 

But in general I talk about the following lines:

MotionPathHelper.create(".astronaut", {
  path: "#path",
  pathWidth: 5,
  pathColor: "red",
  pathOpacity: 0.6,
  selected: true,
  start: 0.1,
  end: 0.5,
  duration: 5,
  ease: "power2.inOut"
});

The documentation says: `You can optionally pass in a vars parameter to further configure the motion path helper. It's an object and can include any of the following properties:`. I've used the properties above and expect the following:

 

- The width of the displayed path should be 5

- The path color should be not blue, but red

- The path opacity should be 0.6

- The object should end on the half of the path

- ..... and so on

 

But all passed arguments seem to not have an affect. Just the basic blue path appears.

 

Do I missunderstand something here? Are the arguments perhaps doing something different than I understand?

Link to comment
Share on other sites

Ah, sorry about any confusion there - yes, you misunderstood. I just added some notes to the docs to clarify...

 

Those values only apply when MotionPathHelper is fabricating entirely new things. In your case, you defined a existing path, thus it just uses that one. So imagine if you passed in an Array-based set of values and MotionPathHelper had to create an entirely new <path> element to illustrate where it'll animate - THAT is when it applies a color. When you're using an existing path, the assumption is that you'd simply set those properties however you want (no need for MotionPathHelper to do that). 

 

Same for the "start" and "end" values - in your example, you've got an EXISTING animation, so it just uses that. It doesn't override the start/end of that animation. If, however, you feed in raw data like this, you'll see that it does what you're expecting: 

See the Pen yLjvxqX by GreenSock (@GreenSock) on CodePen

 

I don't mind updating MotionPathHelper to FORCE the path color, width, and opacity according to what you define. Is that what you're requesting? 

  • Like 2
Link to comment
Share on other sites

8 hours ago, GreenSock said:

I don't mind updating MotionPathHelper to FORCE the path color, width, and opacity according to what you define. Is that what you're requesting? 

 

Hi @GreenSock, understood. Thanks for the clarification! And yes, I think that would be the expected behavior – at least at the first thought. I think that would really make sense, also regarding the `start` and `end` arguments. Lets say the user defines a very small path. It is almost impossible to grab the end of the path to change it afterwards, because the animation is looping around the path. As workaround he can increase the duration to have the chance to grab the path dot. As solution we could just say: `end: 0.8` and as result, the end of the path will always be free for mouse interactions. Just to talk about a possible use case.

 

Is there a workaround for me to force the arguments to have an effect – also for existing paths?

  • Like 1
Link to comment
Share on other sites

7 hours ago, Asored said:

As solution we could just say: `end: 0.8` and as result, the end of the path will always be free for mouse interactions.

Are you saying that you'd want MotionPathHelper to ignore the original animation that it's displaying and force it to only go 80% along the path in this case? I'm struggling to understand the problem you're trying to resolve here - why would the user not be able to select the end of the path even if it's small? How would making the animation incorrectly reflect the animation by only going 80% help here? Is your element that's animating absorbing mouse events? If so, just set pointer-events: none on it. 

 

7 hours ago, Asored said:

Is there a workaround for me to force the arguments to have an effect – also for existing paths?

I suppose you could just gsap.set() whatever properties you want after you create the MotionPathHelper. 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×