Add NavigationServer map_force_update() function #62300
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds
map_force_update()
function toNavigationServer
. This function immediately flushes the Navigationserver command queue and recalculates all navigationmeshes and region connections for a single, specific map.If used appropriately can be a very powerful tool to do crazy stuff with procedual navigation and path queries but can also cause a lot of misery for ppl that just want to use it because they do not like to wait for something without understanding the impact so I hope the warning is clear enough.
Can be used to make situations like in #57815 and #57022 or any situations where users want to do procedual levels more controllable. Sometimes it is very inconvenient to wait for a full physics frame to make (correct) path queries, e.g. if you use one map on the NavigationServer for AI queries and want to check this map under multiple different region constellations all in the same frame.
Actually the real bug potential of this function for now is very little. I just added some drama to get the warning across. It would create just more lag when a long command queue is updated by accident and some regions and avoidance agents would surprisingly be already placed on the new update map. Since everything would still process normally in the synchronisation phase nothing would break without recovering. With already disabled dirty flags on the updated objects it would also do no double processing if not required e.g. because other change commands were send later.