Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

38 Excellent

About zaxcav

  • Rank

Recent Profile Visitors

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

  1. 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.
  2. 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, avoid placing shops/entrances/exits on top of paths with zero clearance turned on.
  3. @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 ride itself is not changed. I've started working on extensions to the tile inspector to address this. The pathfinding determines the peep's goal based on the entrance location stored in the ride. Since the peep chooses which ride to head to, this information is easier to retrieve. If there is a queue connected to the original entrance location, the start of the queue is where the peep heads for, otherwise the entrance location itself is used. If the original entrance is not there anymore (deleted or moved underground to hide it) the pathfinding will typically fail and the peep falls back to "aimless" wandering behaviour.
  4. 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 in the ride entrance data). The path finding will FAIL in this case. I wonder if this is also the reason that the normal path tool cannot be used to connect paths/queues to the disconnected entrance?
  5. @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 :-)
  6. 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.
  7. @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 At what ever location the currently stuck peeps were when they decided to leave, they were closer to the entrance 2 location. How you get rid of this obsolete entrance location data I do not know. Maybe someone else can help you out there.
  8. @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 calculation of the wide path flags not to work as intended, which in turn is breaking the pathfinding. The edge connections also directly impact the pathfinding. Tidy up the edge connections in this area (either manually using the Tile Inspector or replace all the paths and use temporary fences to prevent connections where you want the benches to be) so they are consistent between neighboring tiles and things will start working again. If you need further help with this, just ask.
  9. 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.
  10. 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.
  11. 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.
  12. 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 larger value. Making it unlimited would be a much bigger change. The physical construction of the stations themselves (a classic such form is illustrated in the original post) implies a practical limit related to the max station length. The max station length of a sample coaster I tried was 32 platform pieces. With only an entrance and a couple of platforms gap for the track to connect to the platform from under the entrance (as in the original post), the max number of working adjacent stations you could physically construct is 22. Using a coaster with single tile 90° track turns you could increase this to 32 working adjacent stations. I can't think of a working layout that would allow more. I'd be happy to throw together a small PR to increase the limit to 16 sometime in the next few days.
  13. 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 syncable stations until the limit is reached or no more stations are found. Closed stations (with the sync box checked) are considered syncable but won't block open/test rides from syncing and departing. When there are more than the max stations, which stations get synced and which get left out depends on which station triggers the check, which can vary.
  14. Have you not yet noticed the reasonably new "Cut-away View" feature under the view options? It's useful for seeing inside buildings (and underground).
  15. With respect to automatically raising land, it sounds to me like what you're interested in is enabling the "Disable Support Limits" cheat in OpenRCT2. Under the "Controls and interface" options turn on the Cheats toolbar button. After this, click (and hold) on the golden Shovel button that appears next to the Disk and Game options and you can enable this cheat. When the cheat is on you can build your rides as high above the ground as you like. With respect to automatic lowering land, how shall the game know the different between when you want to lower land vs build the ride underground?
  • Create New...