Inconsistent Guard Navigation When Dynamic Movement Area Is Updated

General Issues and Bug Reporting
, , , ,
1

Summary

I’m experiencing inconsistent navigation behavior with guards when their movement area is updated dynamically. The guard moves perfectly inside the initial small “safe” zone, but once the stair is rotated and a new valid movement area is calculated, the guard sometimes reaches the new destination and sometimes fails, even though the position appears reachable. This inconsistency makes the system unreliable, and I haven’t been able to find a stable workaround.

In the attached videos, the issue never occurs when a Sleep(1.0) delay is added between navigation updates. However, this delay is too long and causes the guard to pause noticeably, which is not acceptable for constant movement. When using shorter delays such as Sleep(0.2) or Sleep(0.5), the inconsistent navigation still occurs. The only delay that avoids the issue is Sleep(1.0), which makes the behavior impractical for real-time use.

Please select what you are reporting on:

Creative

What Type of Bug are you experiencing?

AI

Steps to Reproduce

Place a Guard Spawner Device and allow the guard to move only inside a small, fixed “safe” area.

Rotate a stair (or any structure that affects navigation) so that certain positions around it become unreachable.

Use a script to detect the unreachable positions and recalculate a new, fully valid movement area for the guard.

Assign the guard a destination inside this newly calculated valid area.

Observe the guard’s navigation behavior after multiple tests.

Expected Result

The guard should always be able to navigate to any destination inside the newly calculated valid movement area, as long as the script identifies it as reachable.

Observed Result

Instead of moving toward the recalculated valid destination, the guard sometimes chooses to walk in the opposite direction or toward an unrelated location. This happens even though the assigned target is inside the new valid movement area and should be reachable.

Platform(s)

PC

Video

Test 1: Sleep(1.0) Between Each Navigation

Test 2: Sleep(1.0) Between Each Navigation

Test 1: Sleep(0.5) Between Each Navigation

Test 1: Sleep(0.2) Between Each Navigation

2

I want to clarify in more detail what is happening in the video, since the behavior can be a bit confusing at first glance.

In the video “Test 1: Sleep(0.5) Between Each Navigation”, at second 11, the stair is rotated. This rotation naturally breaks the previous navigation area, so my script detects that the old zone is no longer valid and recalculates a new movement area where the guard should be able to navigate properly.

At second 13, the navigation_result returns Reached, meaning that the guard successfully arrived at the destination inside the newly recalculated valid area. Then the system selects another random destination within that same area, and again the result is Reached, so everything is functioning as expected up to this point.

The issue begins with the next destination at second 14. Visually, this destination appears completely reachable and has no obstacles blocking it. However, the guard ignores the correct path and instead walks in the opposite direction. Due to this unexpected behavior, the system attempts to correct the navigation by sending the guard to the same destination again (which is why the purple arrow appears), but it fails once more.

After failing twice in a row, my script assumes that the stair may have been rotated again, which causes the system to become unstable.

The key point is that this behavior does not occur when the delay is set to 1.0 seconds, as shown in the other two tests. That delay completely avoids the issue, but it introduces noticeable pauses in the guard’s movement, making it unsuitable for real-time use.

3

The same issue occurs in the video using Sleep(0.2).

To clarify, when navigation is not going to return Reached, the guard begins to take a long time to produce a final result and starts moving in a different direction instead of following the assigned path. Because of this, in the videos shown, my system does not rely on the result returned by the NavigateTo() function from the IA API. Instead, my script quickly determines that the navigation will fail by detecting when the guard completely ignores the assigned path, which makes the bug much easier to identify.

However, I also tested a version where my script works entirely based on the result returned by NavigateTo(), without my system making any early assumptions. In other words, the script simply waits for the official result from the IA API before proceeding. The behavior is exactly the same: sometimes the guard walks backward, turns around, or moves in a different direction instead of heading to the target, and only after all of that does it finally return Blocked.

4

Here is also my Twitter post where I show a series of consecutive images (the logs appear on-screen, which is why they are blurred). In these images, you can see that instead of moving toward the destination, the guard takes a different direction or even walks backward before eventually returning Blocked. This serves as evidence that the behavior described in the second paragraph occurs even when the script relies solely on the result from the IA API’s NavigateTo() function.

5

FORT-1032930 has been created and its status is ‘Unconfirmed’. This is now in a queue to be reproduced and confirmed.