LocalSpaceRichAI snapped to (0/0/0) at start

General
1

While working with the LocalSpaceRichAI component, I noticed that my agent is always snapped to (0/0/0) on start regardless of its initial position in the scene.

I have a simple “Map” game object containing 2x2 square road tiles as child game objects, each with a BoxCollider attached. The road tiles are arranged so that world (0/0/0) is in their center. This “Map” game object has a LocalSpaceGraph component attached.

I have a sibling “A*” game object with an AstarPath component and created a RecastGraph in there. Using the scene view gizmos and scan function at edit time, as well as the gizmos at runtime, I can see that the ground of “Map” is detected and a navmesh is generated.

I have a child game object “Agent” created under the “Map”. The game object is positioned so that its position is on the plane created by the ground tiles. I attached the LocalSpaceRichAI, and assigned the “Map” game object as the graph

When launching this setup, the “Agent” is always snapped to world origin even if the position is elsewhere and clearly on the navmesh.

While observing the call stack on launch, I noticed that LocalSpaceRichAI has overridden ClampPositionToGraph where it transforms the incoming position using the LocalSpaceGraph. The result of this calculation graph.transformation.InverseTransform(newPosition) is (0/0/0) )so that AstarPath.active.GetNearest(Vector3) receives this as an input and correctly returns NNInfo.position = (0, 0, 0).

Please advise.

While digging through the documentation, I also noticed that the page on movement scripts mentions that RichAI (from which LocalSpaceRichAI inherits) is kept “for compatibility only” and that FollowerEntity should be used, but the spaceship example with the LocalSpaceGraph is using the LocalSpaceRichAI so I’m confused which way to go. I’d love to read a comment on that, too.

Thanks in advance!

  • A* version: 5.3.4
  • Unity version: 6000.0.46f1
2

Maybe related, I’m seeing this debug output on start:

Look rotation viewing vector is zero
UnityEngine.Quaternion:LookRotation (UnityEngine.Vector3,UnityEngine.Vector3)
Pathfinding.Util.GraphTransform:Set (UnityEngine.Matrix4x4) (at ./Packages/com.arongranberg.astar/Graphs/Utilities/GraphTransform.cs:403)
Pathfinding.Util.MutableGraphTransform:SetMatrix (UnityEngine.Matrix4x4) (at ./Packages/com.arongranberg.astar/Graphs/Utilities/GraphTransform.cs:349)
Pathfinding.LocalSpaceGraph:Refresh () (at ./Packages/com.arongranberg.astar/Core/Misc/LocalSpaceGraph.cs:21)
Pathfinding.Examples.LocalSpaceRichAI:RefreshTransform () (at ./Packages/com.arongranberg.astar/Core/AI/LocalSpaceRichAI.cs:51)
Pathfinding.Examples.LocalSpaceRichAI:Start () (at ./Packages/com.arongranberg.astar/Core/AI/LocalSpaceRichAI.cs:57)
3

The findings led me down to research execution order. I first tried deactivating my agent GO and then manually activate it at runtime: this worked, the agent stayed at its original position. This indicated that the LocalSpaceGraph wasn’t properly initialized.

Then I checked the Script Execution Order in the project settings and found that there was indeed an entry for the agent base class, Pathfinding.AIBase, but not for the LocalSpaceRichAI class. I added this manually and it resolved the issue.

I couldn’t find documentation on the execution order particularly for this scenario, so I’d appreciate any feedback on whether this is a feasible approach or if there’s any better alternative, particularly for a scenario where all involved game objects start “active” in a scene.

1 Like
4

I’d say that solution is perfectly viable actually. Great find.

So I’m looking through it and LocalSpaceRichAI is a pretty old script it seems. The example was updated in 2024 or so, but it’s been around longer than that. Follower Entity was released at the same time as that example was updated. So TLDR, it’s just because the example is much older so it’s using an old movement script.

The documentation does note this, for future reference:

This functionality is only implemented for the RichAI script, however it should not be hard to use the same approach for other movement scripts.

And right above this is a pretty good breakdown of how it works-- not that you need to do any of this, just for future folks finding this thread! :smiley: