zaxcav

@saxman1089I took a quick look at the save game and have identified that the problem is in inconsistent path edge connections of the path tiles under and neighboring the avenue of trees on this path, particular where circled in the image (I didn't examine further areas). For the example tile shown in the tile inspector (the path under the tree next to the bench where the peeps are turning the corner) you can see all edges are connected. This is inconsistent with the neighboring tile with the bench (or the bench would not show. These inconsistent edge connections are causing the calculation of the wide path flags not to work as intended, which in turn is breaking the pathfinding. The edge connections also directly impact the pathfinding. Tidy up the edge connections in this area (either manually using the Tile Inspector or replace all the paths and use temporary fences to prevent connections where you want the benches to be) so they are consistent between neighboring tiles and things will start working again. If you need further help with this, just ask.

I've started working on replacing the parts of the path finding relevant to this discussion and what I've got planned will not require any changes to the save format. There are, of course, other ways to do it that would require a new format. IF I get it working, peep path finding will get better sooner rather than later.

I've submitted a PR to increase the limit to 16. See PR #5877. Once this PR is merged the new limit will be included in all new builds. I even tested it with a simple 10-way duelling coaster (I ran out of steam at that point - building that many coasters already took lots longer than changing the code). It was working as expected.

I didn't know that. That's insane! :-D The OpenRCT2 code I started from did not support this - at least it's not obvious that this would work.

Performance? Possibly, but the performance ovehead of searching a bare handful of locations for adjacent stations and searching through the vehicles of those rides encountered is negligible in comparison to, for example, the pathfinding heuristic search function (for each peep the search limit is 15000 tiles!). More likely 8 was considered more than enough "room to play". But that's only my opinion. I think it's great that @CoasterCrazy is working on a 10-way duelling coaster. Push the boundaries :-) We can trivially increase, but still leave a limit, by changing the #define to a larger value. Making it unlimited would be a much bigger change. The physical construction of the stations themselves (a classic such form is illustrated in the original post) implies a practical limit related to the max station length. The max station length of a sample coaster I tried was 32 platform pieces. With only an entrance and a couple of platforms gap for the track to connect to the platform from under the entrance (as in the original post), the max number of working adjacent stations you could physically construct is 22. Using a coaster with single tile 90° track turns you could increase this to 32 working adjacent stations. I can't think of a working layout that would allow more. I'd be happy to throw together a small PR to increase the limit to 16 sometime in the next few days.

The max number of synchronised vehicles is set by a #define (SYNCHRONISED_VEHICLE_COUNT) to 8. When I fixed up the logic in the above PR I left this limit as I found it. I honestly don't know if this is tied in any way to the SV6 savegame format - if it is not, increasing it is a trivial matter. Hopefully a developer with knowledge of the save/load code can confirm/deny this for us. What is described in the original post about which stations sync is expected behaviour. The logic is triggered by a single station which then searches in both directions for appropriate syncable stations until the limit is reached or no more stations are found. Closed stations (with the sync box checked) are considered syncable but won't block open/test rides from syncing and departing. When there are more than the max stations, which stations get synced and which get left out depends on which station triggers the check, which can vary.

Have you not yet noticed the reasonably new "Cut-away View" feature under the view options? It's useful for seeing inside buildings (and underground).

With respect to automatically raising land, it sounds to me like what you're interested in is enabling the "Disable Support Limits" cheat in OpenRCT2. Under the "Controls and interface" options turn on the Cheats toolbar button. After this, click (and hold) on the golden Shovel button that appears next to the Disk and Game options and you can enable this cheat. When the cheat is on you can build your rides as high above the ground as you like. With respect to automatic lowering land, how shall the game know the different between when you want to lower land vs build the ride underground?

It's an error in the localisation file for the Czech language. This can be edited yourself to correct the issue without recompiling the game. Edit the file <Openrct2>/data/language/cs-CZ.txt Find the line: STR_5151 : This is the line that defines the thousands separator in the money. Notice that there is nothing after the ":", not even a space - the separator is not defined. Assuming " " (space) is the thousands separator used in Czech (which is what wikipedia says), change this line to: STR_5151 : Note there is now a space after the ":". Save this change. Restart openrct2 and money will be displayed properly. Edit: I've created PR #983 in OpenRCT2/Localisation that fixes this.

Others will have different opinions, but for a well developed park I personally use a rule of thumb of around 10 zone quadrants per staff member. A little bigger in sparse or under-developed areas, smaller in "problem" areas.

I've looked at the updated save game under the other thread. It's a patrol zoning issue. See the more comprehensive reply I gave in the other thread here.

I watched Mechanic 4 and 5 for a little while and they seem to behave normally. They wander around until called and when called head to the ride. I did notice that both these mechanics have got patrol zones set that could block them, in which case they will wander back and forth as if stuck. One such patrol zoning that will block staff is as circled here: In this patrol zoning it should be clear that the staff will be blocked from walking around the corner. Here is another patrol zoning that may block staff: Staff NOT heading to a ride will be able to walk though the half selected path. However, staff heading to a ride might not be able to follow the half selected path. This is because when staff are heading to a ride they follow a "thinned" path layout (in which all paths are thinned to be 1 tile wide), and if the side of the path in the patrol zone is the side that got removed by the thinning, the staff will be blocked from walking around this corner. So make sure you zone all path sections the staff needs to walk through for the full path widths and you should have less problems with staff zones. I also personally think your patrol zones are way too big, but you are free to play your way and I'm free to play my way :-)

I tried to load the savegame but it does not have the custom content exported in it, so it won't load for me. Check the option to "Export plug-in objects with save game" under Options->Miscellenous. Since staff patrol areas were recently more rigidly enforced (staff won't leave their patrol areas when path finding anymore), I'd suggest checking the patrol areas of these two Mechanics.

I've been doing all of the fixes to improve the pathfinding in recent months and it definitely, absolutely does not consider transport rides. At some point it will. But in vanilla RCT2 it did not do this and in OpenRCT2 it has not yet been enhanced to do so. So, yes, you are correct that at the moment roller coasters are just as good at transporting peeps around the park as transport rides are.

@BroxzierI'll take a look to see what the heuristic search is doing here. Edit: Nah, I've changed my mind Debugging the pathfinding is excessively time consuming and I don't have much time lately, so I'm just going to follow my gut on this. This peep jam looks like a classic case of cyclic backtracking between multiple locations where at the turnaround points the reachable path tile on the search boundary that is closest to the peep's destination is back in the direction where the peep came from. I've tried a very simple enhancement (building on the previous improvements) to restrict the peeps from backtracking (as far as the pathfind_history permits this) and the peep jam clears up (though it takes some time because the peeps are just about sleep walking). I'll submit a PR for this soon. Update: I have submitted PR#4997 to fix this.

Stupider than normal mechanics is a bug in the pathfinding - my fault, but fixes are waiting to be merged. Mechanic patrol areas is something that was never respected when heading to a ride. Code changes to correct this are also waiting to be merged.

There are some known bugs in the pathfinding that are causing these problems with the mechanics. Fixes have already been submitted and are waiting to be merged.

The problem with maps like this is that the pathfinding AI that guides peeps to their destination only uses paths. It does not use transport rides (that still has to be added). You've built a path across the desert, but it only connects with the entrance of Monorail 1. It still needs to be connected to the dirt path in the oasis section connecting all the rides. As soon as that's done the peeps will walk across to their destination. So this is a poorly designed scenario given the capabilities of the original peep AI, as @imlegos pointed out.

The PR in question was merged yesterday I believe. Always good to hear that it's working a little better than before.

It could be that RCT2 and OpenRCT2 get more "It's too crowded here" thoughts because of how the pathfinding for peeps heading somewhere prefers peeps to walk on the non-wide path tiles which concentrates the peeps on those path tiles (as is clearly seen in any park with wide paths). Some of the tweaks I made to the pathfinding to prevent peeps getting stuck in certain situations in OpenRCT2 actually railroads the peeps even more onto the non-wide paths. Just another reason to look forward to a completely new peep pathfinding AI.

@rustyofcoSince the previous posts there were fixes made to coaster syncing. I haven't seen a problem since then but will look into your specific case. I downloaded your savegame but attempting to load it reports "Failed to load... File contains invalid data". Could you check the uploaded savegame if it works for you? Edit: The terminal tells me there are custom objects in the savegame that I don't have. In-game go to the Options and in the Miscellaneous tab (the one with the spanner) make sure you select "Export plug-in objects with saved games".

@giratyDouble check the sync option on Giga Coaster 2 (yellow coaster on blue track). When I opened the savegame you posted it has not got the sync option ticked. After I ticked it, all 4 coasters were syncing fine for the next few runs that I watched.

@CharlieP In the last month there have indeed been several changes to the heuristic search used by the pathfinding that relate directly to this. As of current builds every thing is working properly (as far as I am aware), however ride exits need to be properly connected to the path for mechanics to find them. BTW, the path connections are only relevant for leaving a path tile, which is why guests can leave the ride exit and enter a path tile regardless of whether the reverse connection from the path tile to the ride exit exists. Technical details follow regarding why paths now have to be connected to the ride exit ... if you are interested. The older OpenRCT2 pathfinding used a hack to allow mechanics to walk into the ride exits - I assume this hack comes from RCT2. In essence the way it used to work was that mechanics would head to the path tile next to the ride exit. Once they got there the hack would send them into the ride exit, regardless of the path connections. The old code always used the height of the ride exit as the height of the path tile to which the mechanics were sent. This is the correct height when the path is flat or slopes down to the ride exit, but is incorrect when the path slopes up to the ride exit. To eliminate other common causes of peeps getting stuck I had already changed the heuristic search so that the goal location (height included) has to exactly match a map element for the peeps to walk there (that's a longer explanation so I won't go into details, but in essence the heuristic search now ignores "dead end" paths that cannot be used to reach the goal). If the goal height is set wrong, peeps won't ever reach their goal... which broke mechanics heading for ride exits connected to a path sloping up to the ride exit. Now mechanics are sent to the ride exit itself and the hack has been removed. This means that the ride exit must now be connected to the path. @imlegos I opened issue #4699 regarding the heuristic search not respecting the patrol areas.

@imlegos I recommend opening an issue on this for discussion.

@imlegos Probably what I should clarify is that I use the term "pathfinding" to cover when the peep has a set goal. It is true that the pathfinding AI does also include patrolling and other random peep movement when the peep has no set goal, and this certainly does respect the patrol areas.