Drawing a red line either the way they want to go - Pic 1
Or draw a red line where they want to go over a path - Pic 2
Why: Easier for people to de-bug why their peeps are stuck / de-bugging purpose for the AI when re-making it
Note; Not too sure if it will even be possible with how they act right now
Inspiration from
Prison Architect & PR #4175
Pic 1:
Pic 2: 
Nubbie
All 6 comments
that would not be easy with the way the current ai works. It only calculates where the next decision point will be. So instead of a red line going the whole way you would only get a short red line to the next junction. When it evaluates a route it will do something similar to this but that knowledge is lost as soon as it works out the route.
duncanspumpkin
on 2 Aug 2016
So, I've been digging into the path finding AI over the last week or two to get back into programming after a couple decades away. AI and path finding is not something I know much about ... I think it was briefly covered in one of the courses I took about 25 years ago :-) So, starting with the path finding AI was probably an odd choice... anyway, back to the topic.
Peeps with a destination walk from junction to junction using a path finding heuristic to choose the "best" direction to take each time (simplistically, it searches down the paths as far as the search limits allow to see which direction gets it closest to the destination in the least number of steps), exactly as duncanspumpkin explains.
Warning, some technical explanations of the path finding algorithm follow!
The main difference between the OpenRCT2 path finding and the classic A* algorithm is that in OpenRCT2 a single best score is tracked vs in A* the best score is tracked on each tile. This still works quite well on thin paths (1 tile wide). To handle wide paths, the path layout is processed into a thin layout (it's essentially a morphological thinning operation, but being done in 1 pass means it thins to the path edges rather than to the center of the path) - this is why peeps prefer to walk along the edge tiles of wide paths rather than being spread out across wide paths more evenly. Unfortunately every tile in the resulting thinned path is still treated as a junction, and since one of the main search limits is the number of junctions, the search limit is reached very quickly, i.e. the search doesn't get very far on wide paths. Another major deficiency is that there is no loop detection so the search can go around and around in circles.
End of technical explanations.
The good news is that I've made some optimisations to the search algorithm code, fixed the problem with thinned paths being treated as junctions, and added loop detection. The few tests I've run show it performs MUCH better now.
The changes need to be tested much more thoroughly to determine whether there are remaining issues in the original algorithm, or (gasp!) new issues introduced by the changes.
The OpenRCT2 community in general can do this far more thoroughly and effectively than I can :-)
As soon as I can figure out the correct GitHub process needed to get the changes online, the improved code will be available for the devs to review. Input on this is happily accepted, otherwise I'll attempt to follow the GitHub help :-)
zaxcav
on 5 Aug 2016
@zaxcav Great to hear! If you need help, please join our Gitter channel and we'll help you create a pull request.
Gymnasiast
on 5 Aug 2016
I made a wiki page that has a description of how the current function works. I never found that loops caused that many problems it was always the double width paths expending junction points that I felt messed it up. I'm not sure if you noticed it but the thinning function can actually block off paths if you make a wide non right angled turn. This also causes the ai to have multiple issues.
duncanspumpkin
on 5 Aug 2016
Loops start causing problems as soon as the problem with wide paths expending junction points is resolved. I haven't experimented with the thinning function with many different wide path shapes so I haven't seen this myself, but paths getting blocked off will absolutely cause path finding issues! I've got a test build which shows path tiles with the wide flag set with a different height marker colour, so I'll have a look to see if I can identify when this problem with wide paths getting blocked off occurs.
zaxcav
on 5 Aug 2016
I've been testing the thinning function on wide paths with all sorts of non-right-angle turns and intersections of varying numbers of wide paths at non-right-angles, but I haven't yet managed to build a layout in which parts of the paths get blocked off. Similarly, connecting stalls/ride entrances on such paths in different places and orientations has always resulted in connected thin paths, so far.
zaxcav
on 8 Aug 2016
Related issues
qwertychouskie
路
3Comments
Nubbie
路
3Comments
deurklink
路
3Comments
Wirlie
路
3Comments
telk5093
路
3Comments
Most helpful comment
So, I've been digging into the path finding AI over the last week or two to get back into programming after a couple decades away. AI and path finding is not something I know much about ... I think it was briefly covered in one of the courses I took about 25 years ago :-) So, starting with the path finding AI was probably an odd choice... anyway, back to the topic.
Peeps with a destination walk from junction to junction using a path finding heuristic to choose the "best" direction to take each time (simplistically, it searches down the paths as far as the search limits allow to see which direction gets it closest to the destination in the least number of steps), exactly as duncanspumpkin explains.
Warning, some technical explanations of the path finding algorithm follow!
The main difference between the OpenRCT2 path finding and the classic A* algorithm is that in OpenRCT2 a single best score is tracked vs in A* the best score is tracked on each tile. This still works quite well on thin paths (1 tile wide). To handle wide paths, the path layout is processed into a thin layout (it's essentially a morphological thinning operation, but being done in 1 pass means it thins to the path edges rather than to the center of the path) - this is why peeps prefer to walk along the edge tiles of wide paths rather than being spread out across wide paths more evenly. Unfortunately every tile in the resulting thinned path is still treated as a junction, and since one of the main search limits is the number of junctions, the search limit is reached very quickly, i.e. the search doesn't get very far on wide paths. Another major deficiency is that there is no loop detection so the search can go around and around in circles.
End of technical explanations.
The good news is that I've made some optimisations to the search algorithm code, fixed the problem with thinned paths being treated as junctions, and added loop detection. The few tests I've run show it performs MUCH better now.
The changes need to be tested much more thoroughly to determine whether there are remaining issues in the original algorithm, or (gasp!) new issues introduced by the changes.
The OpenRCT2 community in general can do this far more thoroughly and effectively than I can :-)
As soon as I can figure out the correct GitHub process needed to get the changes online, the improved code will be available for the devs to review. Input on this is happily accepted, otherwise I'll attempt to follow the GitHub help :-)