Openrct2: No-Entry banners for staff

[awebeer256]

A quick search of this project shows that dissatisfaction with staff movement has been brought up several times, usually with a request for enhancements like setting patrol areas with 1-tile granularity, copying patrol areas, and disallowing staff from entering queues. Generally, the response from developers has been unenthusiastic, saying that the changes would be difficult to implement or that there are edge cases where the change would be unwanted.

So how's this for an alternative: create a No-Entry banner that staff will obey, or add functionality to regular banners allowing the player to toggle their ability to block staff separately from their ability to block guests.

[L3mmy]

I agree, this could be a usefull feature

[awebeer256]

Upon further reflection, I have come to believe that most use cases would require allowing the player to toggle the blocking each _type_ of staff separately, such that one could build a banner that blocked guests, another that blocked security guards, another that blocked handymen and mechanics, and so on.

Without looking at the code or knowing hardly anything about the sv6 format, I'm guessing that the "block guests" flag is currently stored as a 1-byte boolean, which _should_ mean that adding this functionality to banners could be accomplished by bit-packing without really breaking the format. The only snarl would be that if a save created in OpenRCT2 was loaded in RCT2, either the game would crash or any banners set to block _anything_ would change to blocking guests and only guests, depending on how RCT2 actually reads the file. And I don't think that that level of backwards incompatibility is a huge concern; at worst, if the game crashed, there could be an in-game feature that creates a RCT2-compatible copy of the file in which all banners not set to block guests are changed to block nothing.

[Ryder17z]

@awebeer256
Another option is to abuse the banner text string. But it may not be the best solution.

[ocalhoun6]

Personally, I'd be thrilled if we could just keep handymen and mechanics out of queue paths.

I can't even count how many times I've found a super-messy path in my park, tried to figure out why, and then found the handyman assigned to that area stuck inside a queue line, going back and forth because he's trying to get closer to the puke, but he's too stupid to go all the way back and get out of the queue line before trying to walk toward it.

[ShadowPhrogg32642342]

Is there possibility of puke/littering on queues, anyway? I've never seen such thing. The mechanic has nothing to do on the queue either - maybe there's an easier solution, banning staff off of ride-connected queues?

[Broxzier]

Yes, guests can leave litter and puke one queues that aren't linked with a ride's entrance (yet). Perhaps adding a chance for handymen to turn around when they are about to enter a queue would be best, so that there is still a chance they can enter and clean up when necessary.

[ShadowPhrogg32642342]

that aren't linked with a ride's entrance

this corroborates that nor mechanics, neither handymen have anything to do there... but do entertainers? Do quequed guests react to them? I should do tests...

For litter created before the ride was connected, you can always pick up a handyman and drop them there manually, it's not that common occasion either.

[ocalhoun6]

Here's a great example of what this would help prevent:

In this example, the handyman assigned to this area is pacing back and forth in those two squares, trying to get to where all the mess is, but he's too dumb to go out to the end of the queue line to get there.

Or maybe we could work on better pathfinding for handymen? Something to prevent them from getting stuck like this?