In my use case, I need to support the concept of sub-node positioning for my actors-- that is, an actor can have a position that is somewhere along a connection, instead of on a node’s position. That in mind, there are 2 different scenarios that can occur when an actor follows a new path from it’s current position:
The new path would lead the actor to a point along a different connection (for possibly a different node) than the one it’s currently positioned on.
The new path would lead the actor to another point along the same connection it is currently positioned on. (This could potentially be a very small movement)
The first case works as expected with the current system.
However, the second case acts strangely, as the vectorPath in the returned Path effectively tells the actor to move from it’s current position, to the node’s position, and then back down the SAME connection to another position along it’s length-- I would expect it simply to move from it’s current position to the target position, without passing thru the node’s position.
I started looking into doing some pre-navigation logic to try and filter out the offending waypoints from the vectorPath when It occurred to me that this likely isn’t the desired behaviour in -any- case – at least, none that I could think of. Finding a path from a point on a connection to another point on the same connection should never provide a path that goes to the node position and back into the same connection, it should just go straight there.
After some research, I believe that StartEndModifier -should- be the solution to this issue I’m having, however there doesn’t seem to be a setting that will consistently work in all cases for what I need.
Here’s an illustration of the scenario I’m struggling with:
I’m testing using two scenarios: Finding a path from point “S” to point “E”, and finding a path for the reverse-- point “E” to point “S”.
Setting StartEndModifier.exactStartPoint to SnapToNode, and StartEndModifier.exactEndPoint to Interpolate makes the returned path come out correctly when finding a path from “S” to “E”. That is the path looks like this:
Point “S” -> Node “A” -> Point “E”
However those same settings when finding a path from “E” to “S” gives me a path that is incorrect. It looks like this:
Point “E” -> Node “B” -> Interpolate “1” -> Point “S”
The waypoint at node “B” is undesireable in this situation, and it’s cutting past node “A”.
I could fix the path from point “E” to point “S” by changing StartEndModifier.exactStartPoint to Interpolate, and StartEndModifier.exactEndPoint to SnapToNode. Then the path would look like this:
Point “E” -> Node “A” -> Point “S”
However, that makes my path from point “S” to point “E” come out wrong:
Point “S” -> Interpolate “1” -> Node “B” -> Point “E”
Again cutting node “A” out of the loop, and unnecessarily using node “B”.
I just can’t seem to win!
I think a lot of this comes down to whether a path is travelling -towards- or -away- from it’s first node, and whether it’s endPoint is -before- or -after- it’s last node. I don’t suspect this plugin handles that sort of directionality-like stuff…
After that, I wrote a custom Seeker that doesn’t have a hard-coded StartEndModifier, and wrote a custom modifier that would analyze the waypoints near the beginning of the path against the position of the “node being moved away from”, to potentially reposition the first waypoint to the startpoint. Likewise, I did a similar analysis of the waypoints near the end of the path against the position of the “node being moved towards” to potentially reposition the last waypoint to the endpoint.
With a little bit of edge-case handling, this gives me exactly the functionality I would expect, with a path that only has waypoints on node positions if the path actually needs to travel from that node to a different one, and never skips a node.
