Great timing! I was just about to begin remaking my enemy AI 
12 Likes
Thank you so much! I am happy that improvements are coming.
(I saw this topic appear within 1 minute loll.)
8 Likes
Perfect stuff! Good to hear that it is coming back into prod environments.
10 Likes
will the wall and platform cheese be finally fixed?
7 Likes
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.
11 Likes
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?
7 Likes
Unfortunately it wont get fixed with this. We are aware of this issue and will get back to you on this once we have a solution for it.
9 Likes
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!!!
12 Likes
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.
7 Likes
IMO this makes it way more confusing lol.
7 Likes
amazing! love to see more love for stuff that helps with AI and whatnot; super fun to make
5 Likes
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
5 Likes
Do you have the repo place that can sent to us?
3 Likes
What 
PathfindingUseImprovedSearch. “Pathfinding: Use Improved Search”. Sometimes you gotta thug it out and read a little
5 Likes
Not for this, but it’s still pretty long.
5 Likes
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.
7 Likes
This doesn’t work for all map geometry though. In the case of the repro I sent you guys, the NPCs just pile up at the end-islands (red) instead of making their way down and around (blue path) as shown below.
(This map is about 2800 studs across)
Have you considered adding an agent parameter under PathSettings that would restore the old Brute Force behavior? Could be something like BruteForceCalculations? My game relies on the previous method because it needs accuracy over speed in terms of calculations, so adding a PathSetting for it would allow games like mine to continue functioning while also allowing developers to trade accuracy for speed if that suits their use cases more.
For example, you could set your target to be the midpoint between your current position and the final destination
This wouldn’t work in this example because the middle point between the two ends of the map is in the void, so the NPC wouldn’t be able to calculate any sort of path there.
It’s really frustrating as a developer to have the expected behavior of the service change like this, as core parts of my experience (NPC combatants) relies on the service heavily, and the game was built with the previous system in mind (that being higher computation times in exchange for higher accuracy/success rates)
11 Likes
Yes, check your dms, i have dmed you the source place
6 Likes
I agree with Marioman73. The tradeoff of over doubling the accuracy far outweighs shaving off a few milliseconds of computation time. Because if the NPCs don’t even go where they’re supposed to, what is the point of being faster…? The entire service would be useless with that high of a failure rate. Please provide an alternative method for node-based brute force calculations for the games that need consistency over expedience.
4 Likes
Hi @XenoSynthesis ,
Thanks for the feedback. I would request you to try this algorithm out. It should not have any higher rates of failure. If it has please report to us and we will provide a solution/fix . Our intention is not to break any existing games or functionality. I would like to also clarify this 40 msec is based on our internal analysis. This is the time it takes for our A* algorithm to find a path which is not to be confused with time it takes for findPath to return the result. The only reason to highlight that we have put a time limit was to make sure developers are aware and incase they see any regressions they can report to us. We will fix all the concerns before going out of opt in phase.
4 Likes