Support Forum

Can I get the final path at first calculation?

Hello there,
I was doing some testing drawing a path with a line renderer. The issue I noticed with Gizmos was of course worsen with the in-game path drawn.

What I mean is the non-straight line that you might be familiar with. The zig-zag effect:
image

Sometime it will recalculate the path fast enough that it turns in a straight line, but the path change is weird and I would like to know if I can have A* to calculate straight away the best path possible. In this scene nothing is moving in the way, I’m just asking the player to go from A to B in a static scene.

I’m using grid graph with AI Path + Seeker and moving the player with

m_Agent.destination = movePosition

These are the settings and modifiers used in this setup (AI Path is a custom derived class just to link it to game creator 2 controller, nothing was changed it’s only a bridge to speak with GC2)

I’m not quite sure what you are asking, could you elaborate?

Ok, so ignore the line renderer topic here.
In this project it is setup in point & click. You click on an area and the agent will move to that area when I unlock its movement. For the player I show him the visualization of that path (the same as what the Gizmo shows as I use the path callback vector array)

The gizmo show the path and in some case you have a very noisy line instead of a straight line (see the first screenshot)

The line will fix itself as the agent approach it and will become completely straight.

Is there a way to make sure the agent calculate the best quality path from the beginning to avoid showing this noisy path?
As I said the player is not moving the agent straight away, he click on an area, see the path ingame and then click on a button to release the agent. The noisy line is not a good look

If it’s not clear I can make a video explaining a bit more

Hi

It looks like the modifier has failed to simplify the path over there. I’m not sure why that would be the case. In the beta version, this modifier has been improved, and I cannot replicate the behavior you are seeing there. However, first, I would like to know if a hexagonal graph is required for your game? A hexagonal graph is much trickier for many algorithms, and you may get better results (higher quality + higher performance) if you use a regular grid.

Hi Aron, thanks for your reply. I can try the beta version, I wasn’t sure if it was stable enough (is that the one with Burst?)

I actually used the hexagonal grid because the wall cutting was not good otherwise, the agent would go way too close to the wall and get stuck and when rising the size it would be too far away :smiley:

But I can give it a shot + the beta version

1 Like

Hi Aron,
I updated to A* 4.3 beta latest version and it was quite a ride… took me some time to understand that Aline is included in the package (I’ve had it installed and was going crazy with error messages about missing assembly definition from my own scripts). So I deleted my Aline package and referenced the proper assembly.

The bug I’ve had seem to be gone, the lines are perfectly drawn and there is no more recalculation of the path at last seconds etc.

Now I will check to use grid graph that are not hexagonal and have to rewrite parts of my A* / Game Creator 2 integration to fit the new A* version better, but it works out of the box overall, so I guess the code change are deeper than I thought which is great.

Hi

That’s odd. It shouldn’t have given you any compilation errors. Unless… Do you remember which version of ALINE you used before the upgrade? ALINE did conflict with the A* Pathfinding Project before version 1.1.1.
The A* Pathfinding Project only contains a smaller and trimmed down version of ALINE to use for its internal drawing needs. So if you reference that you will not have access to all methods that ALINE has.