X7123M3-256 Posted February 5, 2017 Share Posted February 5, 2017 It was recently pointed out to me (by @Broxzier) that it is now possible to create disconnected entrances entirely within OpenRCT2. I'm sure most of you were already aware of this (or saw it in the other thread), but it was useful to me, so I thought I'd put together this guide in case anyone else hasn't been paying attention to the new capabilities of the tile inspector. The goal is to move the entrance and exit from their current locations to the purple and yellow tiles: The first step is to select the existing entrance, and copy it: Then select the destination tile, and click on paste: If the station platform is on a different level to the path, then adjust the base height until they line up. When the entrance and station platform are on different levels like this, the level that the guests will walk on is that of the entrance, not the platform. This works out well for this skycoaster, and also for the SCAD tower nearby, whose loading platform is at the bottom of the drop, but guests board at the top because that's where the entrance is placed. Without this behaviour that ride would have needed a shoestring. Then repeat the process for the exit. Now build a queue line in front of the original entrance, and copy the path tiles tothe new location (again, the base height may need adjusting). This is required because paths do not connect properly to the new entrance (I'm not sure exactly why). The tile inspector doesn't let you edit the path's associated ride directly, but you can connect a suitable path to the old entrance and then copy and paste it, so that's what I'll do here. It's not necessary to copy each tile individually - if you have a long run of straight path you can just copy one tile and then paste it multiple times. Do not, however, edit queue tiles connected to the new entrance with the path tool - this will disassociate the queue from the ride. If this happens, delete the affected path and try again. Now you can delete the original entrances: The last step is to make sure the queue is connected. Because it was placed using the tile inspector, it won't connect automatically, so check the final queue tile and the path tile it joins onto, and connect them if they aren't already. This is done by checking the boxes corresponding to the sides on which there should be a connection (again, don't use the path tool to do this). Now open the ride and ensure guests can board. If they don't, check the sign on the queue line - if it is not present or does not display the ride name, something has gone wrong. If the sign is there but guests don't seem to be boarding, the paths may still be disconnected. You can now proceed to make the rest of the ride invisible: This hack took most of the day to set up when I made this park originally, so I think it's great that it can be done with the tile inspector alone now. I'm sure most people will have noticed this already, but maybe this will save someone the effort of doing this the long way round. 6 Link to comment
SpiffyJack Posted February 6, 2017 Share Posted February 6, 2017 (edited) Thanks for the Tip, time and effort on this post! @X7123M3-256 and @Broxzier although my TI has been crashing me a lot lately Edited February 6, 2017 by SpiffyJack 1 Link to comment
IceKnight366 Posted July 28, 2017 Share Posted July 28, 2017 Thanks X7123M3-256, this is huge. Quick question: I'm assuming this will still work with invisible queue paths. Will zero clearancing objects on top of an invisible queue path that has been adjusted like this mess with the functionality? Thanks! 1 Link to comment
jensj12 Posted July 28, 2017 Share Posted July 28, 2017 As a rule of thumb, never build paths with zero clearance on, it will mess with other paths. It is of course safe to build other objects (scenery, track) on top of it. 1 Link to comment
zaxcav Posted October 17, 2017 Share Posted October 17, 2017 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? 2 Link to comment
Broxzier Posted October 24, 2017 Share Posted October 24, 2017 The exact same issue occurs when moving a stall from one spot to another. Peeps that want to go to one aim for its original location, instead of the new one. For ride entrances I'm guessing that the location that peeps aim for is the original ride entrance location,and that paths will not change this. The pathfinder will figure out the location of the queue. 1 Link to comment
zaxcav Posted October 25, 2017 Share Posted October 25, 2017 (edited) @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. Edited October 25, 2017 by zaxcav Link to comment
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now