Jump to content

Disconnected entrances - the quick and easy way


Recommended Posts

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:

iSVNcat.png
 

The first step is to select the existing entrance, and copy it:

anBPgr3.png

Then select the destination tile, and click on paste:

NgVhwx7.png

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.


QoroPjU.png

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.


2oroGSf.png


Now you can delete the original entrances:

CHzS6ed.png

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

GU2883x.png

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.

wVqPo5k.png

You can now proceed to make the rest of the ride invisible:

fi7VJvu.png

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.

  • Like 6
Link to comment
  • 5 months later...
  • 2 months later...

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?

  • Like 2
Link to comment

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.

  • Like 1
Link to comment

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

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