I understand the need for exposing a navmesh or navmesh API. Exposing a navmesh API, given that Roblox calculates the navmesh dynamically, is challenging. We also need to consider performance if we want to expose it as an API at runtime. Another option is to expose a static navmesh, allowing developers to edit it and then stream it in at runtime (this would mostly work for games where the navmesh is static).
I apologize if I gave the impression that a decision has been made. The team is having internal discussions, but at this point, we cannot provide a timeline. As mentioned in my above post, we are also exploring the option of exposing some useful APIs to query the navmesh. We need to ensure that whatever we expose (if we decide to) works at scale.
Could we have another agent parameter for setting the agent’s JumpHeight?
So the path will generate with the jump height in mind, This way. we can have NPCs use the path to jump on really high areas that it normally wouldn’t have since the JumpHeight for the path is fixed at the moment.
The Dummy has a Modifier Welded to it’s Root Part, that removes any pathfinding collision in that area, allowing the path to go straight through the yellow spinner, which also has a Modifier attached to it.
YES!! Please!! This would be so incredibly useful for my game as the map is mostly static and it would benefit me FAR more from having a static NavMesh. Adding and modifying the NavMesh manually instead of placing invisible parts with collision groups as a “workaround” to make areas unwalkable by NPCs would save me so much time and probably result in far better stability in my game. (Yes I’m aware of PathFindingModifier with costs, but these don’t always work for my use case, very rarely do they work for my specific game).
A static navmesh would not only help my game performance wise, but also just for stability, as I have frequent issues with AI’s being stuck or walking to weird areas or paths just failing all together.
Until yesterday, everything worked fine.
Yesterday, when I wanted to make new changes to my map, I noticed that it all stopped working.
From my observations:
The Touch event itself works correctly on single objects. But in my game, there are quite a lot of objects on the map, only more than 100 Parts are controlled by one script. There is also a second script that controls other Parts, of which there are more than 200. It was on these that everything stopped working. Perhaps this is due to the number of Parts.
Since I have a fairly large map, I always had “StreamingEnabled” enabled in the Workspace properties. And the Parts themselves, which react to touch and are controlled by the script, are nested in “Model”, and in order for them to all load at once, “ModelStreamingMode = Persistent” is enabled in the Model properties
Everything worked correctly and then stopped yesterday.
Will the improvements to the Pathfinding Quality with the new algorithm also apply to include other forms of NPCs beside characters to include things like pathfinding for vehicles (even if they don’t have anyone in them).
These changes to the quality of pathfinding are very very welcome! Thank you for the hard work.
Are there any future plans, once these features are fully rolled out, for pathfinding to receive performance boosts? Pathfinding works incredibly well when there’s a limited amount of characters using it but when there’s 100+ NPC’s, it can create some problems
Do path modifiers still work? The humanoids won’t use my lovely doors and are trying to path find through the wall unless I delete the doors that used to work fine with the passthrough property.
