Jump to content

zaxcav

Members
  • Posts

    60
  • Joined

  • Last visited

Everything posted by zaxcav

  1. 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?
  2. It's always good to get such feedback. Makes the effort the devs and other volunteers put into fixing things worthwhile :-)
  3. @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.
  4. @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.
  5. What build of OpenRCT2 are you using? There have been several, separate improvements to the peep pathfinding in recent weeks, with some being merged a couple days ago and the latest fix submitted only today (not yet merged into the builds). Even so, the path finding still has limitations which won't be resolved until it's completely rewritten using a better approach. If you provide a savegame I can investigate to see if peeps are getting stuck where they shouldn't or if there is some other problem in the park causing problems for the peep pathfinding.
  6. Since station syncing was fixed (barring issues that have not been reported yet) dummy stations in between won't prevent stations from syncing anymore - i.e. it should work like in vanilla again. In the current implementation, adjacent stations don't actually need to have the station starts next to each other, but for stations facing the same direction this is required for correct synchronisation to always occur - the adjacent station search starts from one station and searches for stations adjacent to the station start in both directions. So if all station starts are not aligned, which stations are synced will depend on which station is checked first. For stations in opposite directions, as long as the station starts are next to part of the adjacent station, the rides will sync. Combinations of adjacent rides in same and different directions work as you'd expect once you understand the above. Whether this is how we want syncing to work is open for discussion. There are currently some aspects that could be refined/improved. For example, the rules related to the z height of adjacent stations requires all adjacent stations be equal height or height +/- 2 of each other. It might be nice if this height tolerance was applied from each adjacent station to the next so, for example, adjacent stations could be staggered down a mountain side. The z height variance allowed between adjacent stations also opens interesting questions about what should happen with stations stacked over one another?
  7. RCT2 (and consequently OpenRCT2) does include handling of wide paths, but in the current builds of OpenRCT2 it's a bit broken. Pull request #4221 fixes a couple of the current problems making it work more as intended.
  8. At the moment, the path finding works best with paths only 1 tile wide. So if you want the peeps to find their way around with less problems, avoid building wide paths. If you really can't live without building wide paths, then ensure your path layout doesn't require the peeps to first walk away from their goal. The lakeside food court area in your park is unfortunately trapping all the peeps who should ideally be walking up the path and going past the TopSpin ride to get to whatever lies beyond. If you are able to compile your own build have a look at pull request #4221.
  9. This sounds like peeps will take transport rides when heading for a specific goal. I don't think this is correct, but I'd love to get my hands on a save game demonstrating this if I'm wrong.
×
×
  • Create New...