Openrct2: Heuristic search does not respect staff patrol areas.

[zaxcav]

The heuristic search in the pathfinding does not respect staff patrol areas, which means that staff heading for a ride could leave their set patrol area.

The question is whether they should?

This issue was briefly discussed between myself and imlegos in the OpenRCT2 forums. He thinks peeps heading to rides definitely should respect their patrol area boundaries and I tend to agree.

If there is general agreement on this I will add this to the heuristic search for staff.

[Gymnasiast]

It's probably better to keep them in their patrol area. That's what players expect, and it makes it easier to organise them. We already have one report about them taking strange routes and moving outside their area: #4682.

There could be made a case for only moving outside their area if the ride is unreachable, but I'm not sure whether we should.

[IntelOrca]

I suppose the problem is that if a ride exit is in the patrol area, the game doesn't know whether its possible to get to (without doing an entire search) from current mechanic position to the exit in order to take the call.

[zaxcav]

@Gymnasiast Yes I agree with this line of thought.

@IntelOrca A similar thought also occurred to me. We could argue that this is a part of managing the patrol areas - meaning that if a patrol area includes a ride, the player is responsible for ensuring the path layout makes that ride reachable from within the patrol area and places the mechanic appropriately in the patrol area.

It shouldn't be too hard to update the heuristic search to stay within the patrol areas - similar code is already in the staff pathfinding code for random patrol behaviour and just needs to be duplicated in the heuristic search algorithm. Checking the patrol area each iteration for staff in the heuristic search will slow down each iteration... but on the other hand, with a patrol area set the search space will usually be much smaller than without a patrol area, so overall the heuristic search should complete in less time when limited to a patrol area.

If there are otherwise no objections to doing this, I'll go ahead with it.

[IntelOrca]

A similar thought also occurred to me. We could argue that this is a part of managing the patrol areas - meaning that if a patrol area includes a ride, the player is responsible for ensuring the path layout makes that ride reachable from within the patrol area and places the mechanic appropriately in the patrol area.

Patrol areas are fixed to 4x4 so the player could be unlucky that they can't select path they want to patrol but not an exit.

[zaxcav]

@IntelOrca I think your point is that the 4x4 blocks might also cover a ride exit that isn't intended to be covered and isn't reachable with the covered paths. Absolutely correct.

If we constrain mechanics to their zones we would be forcing the player to manage the patrol zones so that this doesn't happen - i.e. they may be forced to move the ride exit to match the patrol zone grid to avoid the game calling a mechanic that cannot reach the ride exit.

[vijfhoek]

You could add a notification, e.g. Mechanic X can't reach [ride] due to his patrol area. Preferably clearer than that though.

[zaxcav]

@SijmenSchoon The problem is that the only way to tell if the ride exit is reachable is to perform a search as @IntelOrca noted a few posts above.
Fortunately we do already have a search - the heuristic search that guides the peeps to their destinations.

We could just call this when selecting a mechanic and check if it returns a score == 0, meaning the mechanic can reach the goal (it's not actually quite this simple - we'd have to call it for each valid direction of the mechanic, so up to 4 calls). But, this is only useful where the search area is small enough to reach the goal without exceeding the search limits. This is probably true in most cases since patrol areas are typically small, but may not be true for a large patrol area or a patrol area with complex path layouts. What should we do then?

The heuristic search will also signal failure when it absolutely cannot find the goal - that means it has searched the reachable paths as far as the search limits permit and neither found the goal nor any paths that continue beyond the search limits. We could use this result when selecting a mechanic and only accept the nearest mechanic for which the heuristic search doesn't fail. This doesn't guarantee that the ride exit is reachable, but the uncertainty only applies to mechanics with patrol areas that exceed the search limits (really large or really complex), so is probably an acceptable trade off.

[Charlieep]

I am a player not a programmer and I got this started. My thought is you can't make it idiot proof. You have to place some responsibility on the person setting up the patrol areas to include what rides they want covered by what mechanic. If they don't do it right then they will learn how, which will make them a better player.

[zaxcav]

@Charlieep All true.
For me, idiot proofing the game is not the issue here.
We should strive to make the game intuitive and natural to play if we can, according to the concepts that the game simulates.

The 4x4 zoning grid is an artificial construct that can disrupt this, in the sense that it could require the player to play in a manner dictated by programming and not the concepts of rides and paths and staff zones.

If patrol zones define the patrol paths and connected rides that staff patrolling in that zone should service, then when a ride exit is covered by a zoning grid it's appropriate for the game logic to choose a mechanic that can reach that ride exit using only the paths in the patrol zone. When a ride is incidentally covered, because the zone grid is 4x4, without covering the applicable paths, that ride is probably not intended to be serviced by the staff patrolling in that area.

Pointing out issues like this is a useful contribution that non-programmers can make.

[Gymnasiast]

4x4 grids don't seem to have caused too many problems in the past, even with the limited pathfinding of RCT1. I doubt they're really a problem, even though it might be worth considering using 2x2 grids once we switch to our own system.

[jamtraks]

I wonder if sometimes the staff's coverage plain is higher or lower than the ground, similar to when a stall is 10 feet too high, and unaccessable to peeps, but appears to be flat on the ground. I think i have noticed this to be true in a few cases where i have assigned handymen coverage and they do not comply with their coverage areas and appear to be lost. Would it be at all possible to make staff coverage raisable with control/shift or make it exist in x/y demensios (height and width)? It would also be nice if you could lessen the default coverage grid to a 1x1 or 2x2 size grid, because sometimes the grid overlaps with stairs or higher planes that the staff cannot, or that you would not want them to access.
---I just noticed the previous post mentioning this (i have not read all posts in this topic).
I have also noticed in vanilla that sometimes a mechanic needs to access the entrance, while usually they need to access the exit. It is not always clear which of these need to be covered.

[Charlieep]

@jamtraks commented about the mechanic needing both entrances and exits. If memory serves me right the mechanic goes to the exit first then the entrance to to the ride back on. If the ride is a coaster with a station the mechanic walks down the station to the entrance otherwise he walks out of the exit to the entrance. Doesn't this mean that BOTH entrances and exits need to be in the assigned area?
@Gymnasiast I like the idea of 2x2 squares, I think it would make thing less confusing and a tad bit easier on parks where the rides are close together.

[zaxcav]

The 4x4 grid size is presumably a mix of design vs performance trade off with the more limited computer resources of computers of the time taken into consideration (i.e. memory capacity, CPU speed). It's not clear to me that a smaller zone grid size would be worthwhile without going all the way down to 1x1 (possibly making the tool adjustable like the terraforming tool) or replacing it with something altogether new if it makes sense. Zoning I think makes sense for staff that work ON paths/land, like handymen, entertainers, security. Mechanics work on rides, so instead of zoning them to paths/land, you could assign them directly to rides. Or some other concept that I'd never think of that is brilliant!

[zaxcav]

Mechanics will indeed be sent to the ride entrance if the breakdown occurs on a station without an exit. It's in the code at least. I tried to test this once but, if I recall correctly, I couldn't work out the necessary conditions so wasn't successful in doing so.
Clearly you need a ride with split entrance and exit stations. I think I tried forcing every type of breakdown with an entrance only station selected in the viewport and the mechanic always went to an exit station. Maybe the mechanic was in the wrong location in my tests or my test ride/layout wasn't suitable? Maybe the force breakdown tool doesn't use the selected station? I haven't looked into this further since then.

I thought the mechanic always left the station via the exit (when available), but I honestly don't know. My knowledge of what the code does stops once the pathfinding has delivered the peep to the station entrance/exit.

[pizza2004]

If we can make more advanced zoning in general, having patrol areas for handymen who mow is fine, but everything else would be nice to have actual selected paths they control, because it's terrible when you have some paths up high and down low and have to work around that with zoning. Assigning handymen to rides and having the game work out how to keep them nearby could work. If they have nothing to do they can just go inspect the rides they're assigned to.

[Charlieep]

One other thing I might mention is mechanics covering rides whose entrance/exit is underground. Especially if there happens to be a ride directly overhead. The only way I know of now is set a mechanics' area over the entrance and exit and place him underground that way he stays there. The problem in doing this you must have a general path connecting the entrance and exit and having a coverage area not allowing him to the surface.

[zaxcav]

There have been several improvements to the pathfinding that should work better in areas where the park is built in layers, be it underground-overground or multiple story buildings, etc.

The path layout complexity in such situations is high, because it includes lots of intersections by necessity of including stairs/ramps between levels. As one of the search limits in the heuristic search is the number of intersections walked through, it's easier for pathfinding issues to arise in such layouts. Also "intersection" as used in the pathfinding has a very precise meaning which isn't as simple as what the player will think of as a path intersection, especially when wide paths are built. Quite often a wide path intersection will consist of multiple single tiles that are intersections, especially when paths are wider than 2 tiles*. Wide stairs/ramps will also produce as many intersections as they are tiles wide at each end (not all of which the peeps will necessarily need to walk through though). So you can get the best performance out of the current pathfinding by using paths at most 2 tiles wide and stairs/ramps only a single tile wide.

(*) Path intersections that are 3 tiles or wider can also be interpreted as through paths on the edges without any intersection, meaning that to walk through the intersection the peeps must detour around the side paths! If you see this you can "fix" it by placing obstacles (such as a flower beds or fences in the appropriate orientation) within the intersection to force the path to actually have intersection tiles.

Eventually the heuristic search will be replaced with a better algorithm that should resolve all of these problems.

[elcanadiano]

Does this count as a duplicate?

I am currently playing Katie's World, an RCT1 replica save, and I built a ride called, "In N' Out", which comes from the fan-made UCES. There's a mechanic who wants to fix it but it's stuck walking around the Log Flume that is nearby.

Katie's World.zip

[zaxcav]

@elcanadiano No, your problem is not a duplicate of this issue. It's a bug in the pathfinding that hasn't been reported before.

[elcanadiano]

Shall I move it into its own issue then? I can delete these comments.

[Gymnasiast]

Yes, move it into its own issue. You don't need to delete your comments here.

[zaxcav]

I'm just getting time to come back to this after being very busy with RL through November.

There seems to be agreement in the above discussion that mechanics should be constrained to their patrol areas when pathfinding, regardless of whether they are patrolling (random) or heading to a ride.

I've had a quick look at the current code logic. Rides only call a mechanic whose patrol area the exit/entrance lies in (which is always ok for mechanics without a patrol area). The mechanic pathfinding ignores directions that leave the patrol area when the mechanic is patrolling, but very explicitly relaxes this constraint when mechanics are heading for a ride, with the assumption being that the pathfinding will actually work...

Constraining the heuristic search to prevent mechanics leaving the patrol area when heading to a ride is fairly straight forward (the existing calls used for patrolling will work in this case too), but there is additional overhead for this check that applies to every single tile checked in the search space == performance hit. This could be why the constraint was relaxed in RCT2. On the other hand, the patrol area will (usually) limit the search space substantially, so overall I'd expect a nett performance benefit on average.

If any core developers read this, are you happy for me to make this change?

[Gymnasiast]

I would be, yes.