NodeLink2 jump calculations

[bjjkdci]

• A* version: [5.1.1]
• Unity version: [2022.3.29]

Hello,

I’m having a bit of a time trying to figure out how to calculate a jump using NodeLink2 with a FollowerEntity, specifically when using a custom TraversalProvider.

For cases not using TraversalProvider (using my “jump action” to create a jump in real time) I can use my ballistics package to determine whether a jump will be blocked by an object using raycasts, create a link if viable, and cache the jump data on the node. However, as I have found, TraversalProvider runs on another thread so I can’t use the Unity Physics functions. It would be nice to use TraversableProvider as I have had success using it to determine whether a unit has a key required to open a door NodeLink2, but I’m not tied to it.

Now, before I go too far trying to figure out how to run a batch of RaycastCommands on the main thread and communicate that back to the TraversalProvider thread (if this is even a sane thing to do), is there a better way to go about this?

All units have their own “jump power” to calculate their trajectory so having each NodeLink2 calculate a single jump (say jump power 10) will potentially not work for a unit with a jump power of 5.

Me brainstorming solutions:

Can I know which NodeLink2s the unit has on its calculated path and run the calculations while the unit is en route, block links that wont work, and recalculate the path?

Could I do these calculations as the unit tries to traverse a link, abort if not viable, blacklist the node, and recalculate somehow? What would be a good way to blacklist them? Something similar to BlockManager?

My simple brute solution would be running a series of tests from the NodeLink2 every time it updates for a range of jump powers so a unit could know if its within an acceptable range. These links can update quite frequently as they are on dynamic moving platforms and each platform will have a minimum of 4 links. So it would be a waste to constantly recalculate these (twice per: a start jump and an end jump) when units aren’t trying to reach them. Then again, I am far away from having performance matter.

Any suggestions or affirmations of my proposed solutions would be helpful before I make this way more complicated than it should be or use bad practices.

Thank you.

[tealtxgr]

Interesting case So, I’ll answer your brainstorming solutions to the best of my ability but if none of these work out let me know!

@bjjkdci

Can I know which NodeLink2s the unit has on its calculated path and run the calculations while the unit is en route, block links that wont work, and recalculate the path?

You may get some mileage out of this thread, and this thread linked later in the first.

@bjjkdci

Could I do these calculations as the unit tries to traverse a link, abort if not viable, blacklist the node, and recalculate somehow? What would be a good way to blacklist them? Something similar to BlockManager?

Two options here methinks: Either turn off the NodeLink2 altogether if all your units share the same logic for off-mesh links (as in, your units are all the same in the sense that they can traverse the same links) or tag it appropriately for different units.

@bjjkdci

My simple brute solution would be running a series of tests from the NodeLink2 every time it updates for a range of jump powers so a unit could know if its within an acceptable range. These links can update quite frequently as they are on dynamic moving platforms and each platform will have a minimum of 4 links. So it would be a waste to constantly recalculate these (twice per: a start jump and an end jump) when units aren’t trying to reach them. Then again, I am far away from having performance matter.

I think this is where that logic about making something kinda… good enough is useful. You can maybe only update dynamically when they’re nearby a unit or something. That doesn’t work if your units can traverse the entire map, but you can also just lower the rate of how often it updates and have them be a little tiny bit jank every once in a while.

[aron_granberg]

Hi

Is a higher jump power always better? If so, you could tag the link with a discrete required jump power.

So for example if you have the tags:

JumpPowerAtLeast1
JumpPowerAtLeast2
JumpPowerAtLeast4
JumpPowerAtLeast8
JumpPowerAtLeast16

Then you could do your calculations up front, and see what jump power is minimally required to use the link (possibly using a binary search, to save on processing power). When the agent reaches the link, it would do the calculations for the unit’s exact jump power.

An agent with jump power 6 would then be allowed to traverse the tags: JumpPowerAtLeast1, JumpPowerAtLeast2, JumpPowerAtLeast4.

You can have more granularity in the tags you use, of course. You could even use a custom ITraversalProvider to check if the agent’s jump power is greater than the link’s required jump power.

[aron_granberg]

@bjjkdci

My simple brute solution would be running a series of tests from the NodeLink2 every time it updates for a range of jump powers so a unit could know if its within an acceptable range. These links can update quite frequently as they are on dynamic moving platforms and each platform will have a minimum of 4 links. So it would be a waste to constantly recalculate these (twice per: a start jump and an end jump) when units aren’t trying to reach them. Then again, I am far away from having performance matter.

Honestly, if this works, and performance is not a problem, then just go for the simple solution and move on to other areas of the game