Mechanics ignoring their assigned area

[CharlieP]

The game I am enclosing has an odd problem. The mechanics ignore their assigned areas. They respond to calls out side their area, sometimes clear across the park when others are closer and not occupied. They also will not enter an entrance or exit that has been "turned" (such as Power Tower 2". Power Tower 2 is a good example it fails quite often (look at its stats). I have had this problem with any other scenarios in the past, just this one. It does the same thing in stable as well as development modes.

The handymen don't have this dereliction of duty problem. I have deleted all the mechanics and assigned new ones and set their areas while the game is paused so when resuming they were in the correct areas.

 

 

131B - Venice River Delta.sv6

Edited October 22, 2016 by CharlieP

[CharlieP]

Will someone download this park and tell me if they have the same issue?

[zaxcav]

@CharlieP Tried it out, and yes they are leaving the patrol areas.

The reason is that the pathfinding doesn't consider patrol areas (this is how it is in vanilla).

The problem in this park is that several of the ride exits aren't connected to the paths, so the pathfinding is leading them all over the park trying to get to the ride exits.  Connect the ride exits to the paths and things will work a lot better.

Edited October 24, 2016 by zaxcav

[imlegos]

@zaxcav Only the path directly infront of the ride exit is required to be zoned as patrol

Also, patrol zones are factored into the pathfinding, as if they weren't mechanics in one part of the map would be trying to go to a ride on the other.

[zaxcav]

@imlegos By "pathfinding" I only meant the specific part of the AI that controls how the chosen mechanic gets from his current location to the goal. I did not mean to include the game logic that chooses which mechanic will answer the call - this is a different part of the logic.  You are correct that the patrol zones are considered when choosing which mechanic answers the call.

[imlegos]

@zaxcav Patrol zones are still considered, as normally a mechanic would not pathfind to an area that isn't marked for him, same goes for the other 3 staff types.

I'll take a look at this save later and see if I can find anything. I can't right now as I do not have access to the most recent version.

[imlegos]

If there was a section of patrol that was missing a spot, the mechanic would just wonder on the edge, unable to reach his destination. They would not cross over.

[zaxcav]

Ok, this is straying way outside the scope of this thread and we're getting into the details here, but I'm pretty sure I'm right.  When you dig deep enough (src/peep/staff.c), mechanics with state PEEP_STATE_ANSWERING or PEEP_STATE_HEADING_TO_INSPECTION eventually call peep_pathfind_choose_direction() (src/peep/peep.c) which then utilises the same pathfinding heuristic search that all peeps use.  The validDirections that keep them in their patrol area when they are patrolling is not passed into this call and is not used in the heuristic search.

I could well be wrong about vanilla RCT2, but I know the current pathfinding code in OpenRCT2 fairly well and in the time I've been working on it the heuristic search has not included the patrol areas. Perhaps it should?

Edited October 24, 2016 by zaxcav

[zaxcav]

@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.

[imlegos]

So, I went and did a small test on v0.0.5-develop build 8187b4a, and I noticed that mechanics temporarily will leave the patrol area, but return to it immediately after, thus making the "patrol area" 6x6. However, during this test I noticed that the mechanic would walk OFF the single tile of path in it's patrol area.

I was originally intending to force a breakdown on a ride nearby in a seperate area of patrol, but this discovery stopped me.

Edited October 24, 2016 by imlegos

[imlegos]

Alright, I did the intended experiment, and for some reason the mechanic LEFT his area and walked down a path too the broken ride.

I feel that checking for patrol zones SHOULD be a think that it has too go through.

(Should mention, the path infront of the ride exit and the path he was placed at were both set as patrol zones, but the patrol zones were not connected.

Edited October 24, 2016 by imlegos

[zaxcav]

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

 

[imlegos]

@zaxcav Problem: I did not test this with the latest version as my _alt device does not have the latest version or launcher.

I'll do proper up-to-date testing when I can access Main.

[CharlieP]

I already opened a ticket as I have another park with the same problem. Both parks had their entrances and exits this ride rotated using the tile inspector. After doing so you MUST reconnect any path to the respective entrance or exit or the peeps won't enter. This problem didn't surface until the third ride had tile changes.

mechanics.zip

mechanics2.zip

Edited October 24, 2016 by CharlieP

[CharlieP]

Did some more experimenting and found something interesting. In the mechanics2 zip ride Purple Challenge was a saved ride which was placed with its exit exactly  on the pre-existing path. The connection was good because the ride functioned properly with peeps entering and exiting ok. After reading @zaxcav and @imlegos discussion, I placed a NEW path on top of the existing exit path and the mechanic found and fixed the ride. Somewhere in the last month there has been a change with something to cause this because I haven't played any games since September 28 and those worked just fine.

[zaxcav]

@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.

Edited October 25, 2016 by zaxcav

[CharlieP]

@zaxcav That explains the problem. I am not a programmer, but I do understand the process. My computer programming training in college was done using punch cards (70's). I am taking a class at our local Jr college on programming (I am older that any 3 people combined) and learning.