Jump to content
OpenRCT2

zaxcav

Members
  • Content Count

    44
  • Joined

  • Last visited

Community Reputation

40 Excellent

About zaxcav

  • Rank
    Apprentice

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The wiki page you refer to has a good description of the path finding under the section "Pathing Systems". It leaves out some details to keep the explanation simple. Junctions are indeed intersections of paths, such as a T or X. Other things that are considered junctions are listed on the wiki page. The main additional point to know is that the pathfinding searches through at most N junctions on a potential path before it stops. It chooses the direction of the various potential paths that ends closest to the destination. The value of N is around 10-15 if I remember correctly. Peeps that
  2. https://github.com/OpenRCT2/OpenRCT2/wiki/RCT1-Features-not-in-RCT2 The first item in the list appears to cover what you asked about.
  3. The code snippet taken out of context is confusing because it's not clear what "edx >> 8" means. Looking at the preceding code (the relevant bit is: "edx = get_num_of_sheltered_eighths(ride)"), we can see this is how much of the track is covered, in eighths. i.e. if 6/8ths or more of the track is covered, the ride excitement is halved. So driving in a tunnel is only half as exciting as driving in the open.
  4. zaxcav

    Group Park 7

    Well said. Haha. So what the heck is going on there? The pathfinding usually handles multiple tiles at the same location (zero clearance) fairly well. If I remember correctly though, there is an "optimisation" that culls edges from an intersection that are thin paths and also dead ends, which is what it thinks the paths under the shops are here. This make these shops effectively unreachable to the pathfinding, despite being otherwise properly connected to the path. This is something I never thought of and will have to fix at some point when I get some time again. In the meantime, a
  5. @BroxzierVery interesting observation regarding moved stalls. I'll have to look into that. Thanks for the tip. For ride entrances, the location data is essentially duplicated - the entrance tile itself is at a specific location, and the ride itself stores it's entrance and exit locations for each station (XY only - the pathfinding assumes the entrance height is the same as the platform height, so I plan to fix this so that disconnected entrances at different heights will also work). When the tile inspector is used to copy the entrance, only the entrance tile is copied. The data in the r
  6. I was investigating a path finding issue to a ride with a disconnected entrance in Belmont Shores (NE) - peeps heading to the ride were walking around aimlessly. I determined that the cause of the problem was that the ride entrance data reflected the original entrance, not the position of the disconnected entrance. This means that peeps interacting directly with the disconnected entrance/connected queue can decide to go on the ride and join the queue. However, peeps elsewhere in the park who decide to go on the ride will attempt to walk to the location of the original entrance (as i
  7. @saxman1089I'm glad you were able to fix the problem in your park so everything works properly again. The bad news with the exit parade is your guest numbers drop. The good news is that the average happiness of the remaining guests is much higher, so the park rating will shoot up :-)
  8. Sounds like the tile inspector needs to be improved slightly when used to delete a park entrance. Alternatively/additionally this problem could be checked for and corrected after loading a savegame. Both should be fairly easy changes - the difficult part is finding where to add the extra code.
  9. @saxman1089 The pathing looks fine. The wide path flags calculated from the edges look normal. I turned on the path finding debugging to see if there's something weird happening there. The peeps leaving the park are using the following location for their destination: x: 2, y: 75, height: 14. The exit location is however at x:2, y: 94, height: 14. This explains why they aren't leaving. I added some debugging to print out the entrance location in the map data. There are 2 park entrance locations in the map data: Entrance 0: 2, 94, 14 Entrance 2: 2, 75, 14
  10. @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 calcu
  11. 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.
  12. 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.
  13. 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.
  14. 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 lar
  15. 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
×
×
  • Create New...