[3.5RC2] NavigationAgent doesn't work (it works in beta5).

[viksl]

Godot version

3.5rc2

System information

Windows 10, Nvidia gtx 1660Ti, latest drivers, GLES3

Issue description

Tested in GDS build as well as Mono, 3.5RC2 (rc1 mono doesn't itself so I can't test there), backstepped to beta5 where everything works (apart from bugs in b5 ;)).

It seems that signals don't get triggered (if I put print statement into velocity_computed signal method it doesn't get called).

I'm using test scenes I previously made for a previous navigation bug report, I'm not sure what the rules are about uploading the same scenes so I'll link the bug report with test scenes (both gdscript and mono) for anyone who wants to test.

In rc2 build the agents never move while in b5 they move, agents are RigidBody capsules( I tested this with KinematicBody too but since the agent's signal don't go off I don't think it matters).

Previous bug report (also related to navigation but about something else, scenes are perfectly usable for this issue too): #60735

GDS scene: https://github.com/godotengine/godot/files/8624860/NavTestGDS.zip
Mono scene: https://github.com/godotengine/godot/files/8614394/NavTest.zip

Steps to reproduce

Using reproduction project:

1. Open the project in 3.5 beta5
2. Start it
3. Observe agents moving towards target
4. Open the project in 3.5 RC2
5. Start it
6. Observer agents don't move
7. Extra: Add print statements to methods connected to NavigationAgent's signals (OnVelocityComputerd <- yep there's a typo and OnTargetReached)
8. Extra: Observe prints only work in b5 not rc2.

From scratch:

1. Create a scene with a NavigationAgent as a child of a KinematicBody (or RigidBody)
2. Connect to NavigationAgent's signals
3. Add print stattements to the connected methods to see if the signal gets triggered
4. Start the scene

Minimal reproduction project

GDS scene: https://github.com/godotengine/godot/files/8624860/NavTestGDS.zip
Mono scene: https://github.com/godotengine/godot/files/8614394/NavTest.zip

[Chaosus]

cc @smix8 - Maybe you want to fix it :)

[smix8]

You are not alone with this issue but this is not a bug or regression.
In current Godot 4.0 and Godot 3.5.RC2+ NavigationAgents have a toggle to enable / disable avoidance processing by choice and I was sneaky enough to disable avoidance by default so ppl can save performance and other ppl could fall for it as well #61378.

[viksl]

So to understand this issue. If this is off then the only use NavigationAgent has is to obtain a simple path while with this enabled I can use the newer algorithm to move around and it will take in account dynamic objects to avoid them, please?

I'm lost in the new navigation, while I'm on the topic of these methods (velocity_computed), would you mind explaining one more thing if you don't mind. How do these signals work with physics and with threading?

For example move_and_slide (MAS) docs recommend to use from _physics_process but examples I've seen so far call MAS in the method connected to velocity_computed signal, when does this actually run? Is it frame behind, at the same frame, is this realated to some threading and how does that come into account here, please?
(same could be said about RigidBody's linear_velocity, docs talk about changing it in _integrated_forces or _physics_process but so far it seems everyone uses it in the method connected to the velocity_computed, should we work around this or is it safe to use it in the signal method and if so then when does it run?)

Sorry if this is too off-topic or out of scope, I'm just not sure how these actually plug into godot's pipeline? :)

Thank you very much!

[smix8]

Each _physics_frame() you calculate the velocity of the parent Node of the NavigationAgent with your delta. Then set this velocity on the NavigationAgent with set_velocity(). Now after a very short wait you will receive the safe_velocity with a Signal connection to velocity_computed. Use this safe_velocity vector now for movement e.g. with move_and_slide or linear_velocity. This is thread-safe as the entire reason for the Signal use and delay is that the NavigationServer is emitting the signals in the thread-safe sync phase of the physics_frame.

EDIT
The NavigationAgent is a helper Node. It is a mixed bag of NavigationServer function calls and internal pathmovement logic.
If you disable avoidance it is still good for normal pathmovement and auto repaths when the path gets blocked. Everything the NavigationAgent can do you can do yourself with an oldfashioned pathmovement script and some use of the NavigationServer API.

[viksl]

@smix8 That's about what I do yeah, I'm just wondering, currently I store the safe_velocity in a class level variable and in _physics_process(delta:float) I call move_and_slide(class_safe_velocity), I'm just wondering if I can move the entire MAS to the method connected to velocit_computed signal or should I keep it in _physics_process(delta:float)? The return signal which gives the safe_velocity is which I'm unsure about where it sits in, since calling MAS in _physics_process(delta:float) calls it every physics frame while the signal from NavAgent might come at different times?

Sorry if I'm confusing you with my question.

# Vector3 _safeVelocity is a class scope field

_physics_prcoess(delta):
  NavAgent.set_velocity(_someVelocity)
  move_and_slide(_safeVelocity)
  
onNavAgentVelocityComputed(safe_velocity):
  class_safe_velocity = safe_velocity

VS

_physics_prcoess(delta):
  NavAgen.set_velocity(_someVelocity)
  
onNavAgentVelocityComputed(safe_velocity):
  move_and_slide(safe_velocity)

This above is basically what I'm wondering about (for rigid bodies replace MAS with linear_velocity set up), since in the second example MAS is out of physics_process so I'm not sure if this isn't a potential problem (since for example move_and_slide would need the delta value directly if I used that instead)?

Thanks again and one more apology for asking. :-)

[smix8]

Keeping your final movement with move_and_slide or linear_velocity inside the callback function for safe_velocity is correct if you use avoidance. If you disable avoidance solve it inside the normal _physics_process() function.

It all happens in the same physics_frame, it just controls the order of execution due to threading and to not mess up the physics calculation.

• PhysicFrame starts.
• _physics_process(delta)
• set_velocity() on NavigationAgent Node
• Agent sends velocity and position to NavigationServer
• NavigationServer waits for sync phase
• NavigationServer syncronises and computes avoidance velocities for all registed avoidance agents
• NavigationServer sends safe_velocity vector with signals for each registered avoidance agents
• Agents receive the signal and move their parent e.g. with move_and_slide or linear_velocity.
• PhysicsServer synchronises
• PhysicsFrame ends.

[smix8]

@viksl
Something else or everything solved so this issue can be closed?

[viksl]

@smix8 it's great, thanks for answering these. I have nothing else. I really appreciate the info :-).
Have a nice day.