Jump to content
OpenRCT2

Mechanics ignoring their assigned area


Recommended Posts

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 by CharlieP
  • Like 1
Link to post

@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 by zaxcav
  • Like 1
Link to post

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

Link to post

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

Link to post

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 by zaxcav
Link to post

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

Link to post

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 by imlegos
  • Like 1
Link to post

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 by imlegos
Link to post

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 by CharlieP
Link to post

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.

Link to post

@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 by zaxcav
Link to post

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

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...