After extensive testing, valuable feedback, and further improvements, we’re excited to announce that the production opt-in for the Improving Pathfinding Quality With New Algorithm will now be re-enabled.
Initially, we introduced improved pathfinding (PathfindingUseImprovedSearch) as an opt-in feature. However, after identifying a few sporadic crashes and listening to your feedback, we temporarily disabled it on production games while we investigated, keeping it available in Studio for testing. We have resolved these issues and are now ready to relaunch to production. We will continue to refine the feature based on your input.
Next Steps
If you have already opted in to PathfindingUseImprovedSearch, please opt out now to avoid any unexpected production changes. Tomorrow, on March 11, we will officially re-enable the production opt-in. We will update this post once re-enabled, and you can opt in again at that time to take advantage of these improvements.
Further Improvements
With this relaunch, we have made improvements to boost overall stability and performance. Specifically, we have allocated a 40ms time budget for A* search to avoid unnecessary search attempts when a path cannot be found. We will continue monitoring performance statistics.
Thank you for your continued support and feedback. We look forward to your ongoing collaboration as we enhance the game experience for everyone.
UseImprovedSearch has resolved the majority of the wall and platform cheese issues. We know it’s not perfect yet, and we’re continuously working on improvements. If you encounter any specific cases, please report them to us—it will help us further refine pathfinding.
a while back i made a report on faulty pathfinding modifier behavior (on both the old and new version) would that be fixed here or has it not been adressed yet?
Just a question from our chats earlier, does it use node-based timeouts (where it times out after exploring too many points) or does it just cancel pathfinding based on an internally set time?
From the testing data you sent me, the node-based limitation was better!
With the time budget: (WORSE)
Max Computation Time: 8s
Average: 3.12s
Success to Fail: 976 vs 3272 (23%)
Without the time budget: (BETTER)
Max Computation Time: 11s
Average: 3.39
Success to Fail: 1567 vs 1281 (55%)
For only about an added 0.25 seconds on average, the success rate went from 23% to 55%. Really hoping you stick with the node-based limit instead of an automatic timeout system, especially since I (and likely others) don’t always allow partial paths to be computed.
EDIT
Specifically, we have allocated a 40ms time budget for A* search to avoid unnecessary search attempts when a path cannot be found. We will continue monitoring performance statistics.
Please add a way to turn this off. There is no chance that most of my paths will finish computing in only 0.04 seconds!!!
Yeah, it’s a mouthful, like “PreciseConvexDecomposition” and “GetUserSubscriptionPaymentHistoryAsync”. I know Roblox is just trying to avoid any confusion in what a Property or Method does. But there’s such thing as “too specific”. Thankfully in most cases we can just assign a variable with fewer syllables.
wait is this fixed right now? i have noticed that my enemies are still hugging the walls
(in studio i mean)
edit: they are still trying to go thru the wall WHY
Thank you for your feedback. Currently, if the A* search takes too long, it delays all subsequent findpath calls. For very long paths (e.g., over 1000), we recommend using a partial path approach and breaking the path into segments. For example, you could set your target to be the midpoint between your current position and the final destination, then re-run findpath after one or a few seconds until you reach the final destination. This strategy helps avoid long waits while still progressing towards your goal.
