Allow More Specific Patrol Area

[pizza2004]

I don't know what people's opinions on this would be, but I've been playing RCT1 lately and it really bugs me that I can't adjust the patrol area one square at a time. I want to be able to restrict each handyman to a very specific area, but it's hard because you can only set patrol area in 4x4 squares at a time.

[vzybilly]

This would be amazing. If possible, I could also see one way or one way (go the same way that they came in) with turns (left, right, turn around) to stop some of the crazy things they do. I've seen a sweeper go back and forth on the same 3 paths while his service area was larger, I ended up needing 3 people for a single 'coaster exit from that...

[pizza2004]

Another thing that would be nice is to be able to assign the mechanics to work on specific rides, and they'd just stay somewhat nearby the rides they're assigned. That feels like it would be a lot better than giving them a patrol area.

[vzybilly]

that does sound pretty nifty as well, but I think to get all of the awesome out of the staff and paths, the pathfinding will need to be done and from what I hear, it isn't...

[Gymnasiast]

Sounds good.
As for the handyman issues: these may be solved with better pathfinding code (going to nearby litter instead of just randomly walking), which I think will eventually be in OpenRCT2 (though only after the whole game has been reverse engineered).

[duncanspumpkin]

Its not quite as easy as just making handymen clean litter whenever there is one nearby. If that change was implemented the whole dynamic of handymen would be changed. If we improve handymen a.i. then something will need to balance this out. Maybe having to introduce handymen having lunch to prevent the game from becoming too easy. Wages would need to be adjusted and...

So the a.i. could be improved but the knock on effects will change the game a lot.

Bugs in the a.i. preventing peeps from finding destinations when fixed shouldn't cause too many issues same with making some way for staff to walk their whole patrol area.

For anyone who does want to look into the a.i. more than have a look through 0x00693C9E which i think might be the function that works out the direction for the peep to walk.

As for changing the size of patrol areas this would break save games. So that would have to be discussed at some point after finishing the reversing of the whole game.

[IntelOrca]

As for patrol area, map sizes can go up to 256 x 256. This means there are 65536 possible tiles. Using a bit mask, 65536 / 8 = 8192 (8KB) would be needed per staff member. This is why the current limit is 4x4 which only requires (0.5KB) per staff member. This is also probably why there is a staff limit too.

If OpenRCT2 is going to allow map sizes of 1024, (128KB) is needed per staff member, so it scales up quickly. It is probably more efficient to store patrol areas as a list of coordinates or rectangular regions.

[pizza2004]

Yeah, I'm sure there are ways to allow more precise patrol areas without taking up all that space. I just know that sometimes I want to have my handymen handle more specific areas of the map.

I don't like the idea of handymen heading to the nearest litter/vomit like some sort of trash bloodhound. I don't even want you to be able to give them super specific orders, just a more specific patrol area. My hope is that with the new AI they'll more logically patrol all of the path within their patrol area, and therefore find vomit and litter more readily. As it stands I don't like that I can assign a handyman 20 tiles of path and half of it is covered in vomit for 10 minutes. It just doesn't make sense to me that the handyman isn't patrolling the whole area. In real life wouldn't they be expected to patrol the whole area like that?

[vzybilly]

A balancing factor could just be the wages, if you pay like 100x then they go directly to the trash and such but when you pay the minimum, they end up moving like they do now... just a thought...

[IntelOrca]

I think, if they are walking in the opposite direction to litter, they shouldn't suddenly change direction and go directly towards it.

[pizza2004]

I definitely agree with IntelOrca on this one. They shouldn't be able to 'sense' when a mess is nearby, but I think you should be able to reasonably expect them to keep an area clean of vomit and litter. Perhaps if they are going towards it they can 'see' it from a certain distance, and won't turn and go another direction. That might be acceptable.

[duncanspumpkin]

Its trivial to work out the direction of a peep and I'm pretty sure its not hard to view the contents of the footpath tile infront so I might be able to make a quick simple fix to this but it will require implementing peep_update_patrol which at present has not been reversed. On the plus side though I think it will be very similar to peep_update_walking which I completed last week. So give me a little while and I might be able to crack out a simple solution.

[IntelOrca]

Perhaps:

foreach litter closest to furthest (with distance cap) do
    if sign(litter.dx) = -direction.x or sign(litter.dy) = -direction.y then
        continue
    go to litter for clean up
    break

[duncanspumpkin]

ahh never thought of iterating over the litter I was just going to check the tile infront for litter. Either way need to reverse a couple functions before doing that.

[IntelOrca]

Just a thought for the future, I don't think this enhancement is important at the moment.

[cgrinham]

@IntelOrca Sounds like coordinates would be a better idea, especially if people want to specify vertical coverage, for paths over paths or underground paths etc

[vzybilly]

Would vertical coverage be that needed? the only point where it would be is when there is a staircase type walkway going straight up but that would make almost no way for the peeps to get up it with their current AI, atleast from what I know... removing vertical would also remove the extra byte/word for each coord, allowing for more coords/staff.

[cgrinham]

I was thinking more for situations where there is a path overground and one underground. Not 100% necessary but seems like some people might be interested in it.

[pizza2004]

Oh, being able to set vertically would definitely be very nice. It would allow for paths that go under other paths without having to worry about the AI trying to get between them or stuff like that. I think it could definitely be very useful, although it's not necessary. I'd love it if when you set the patrol area it goes one by one and you could just set it on the path itself instead of on the ground below when the path is floating in the air.

[Andronomos]

I would love to be able to edit patrols a single tile at a time and if it really causes that big of a change in gameplay then simply make it a cheat option.

[ZehMatt]

After reading all the comments, another way would be also to have a single array which represents each tile and each entry can have one or more staff member ids so the structure would be something like Tiles[x,y] = { StaffId_1, StaffId_2 }. And staff logic can check if a tile has them marked inside.

[pizza2004]

Perhaps it would be more storage efficient to add some field to each tile itself allowing for a list of staff members with that tile set as part of their patrol area, instead of being saved separately or individually as part of each staff member, and then it could either be generated into an array for each staff member at load or staff members could just check the tile before they try to enter it to see if they're "allowed".

Also, would it be possible to tie staff members directly to a specific path object? Other than handymen, no staff really needs to be able to go off the path as it is, and sometimes you have to stack multiple pathways up in the air in the same place. If you could link a specific staff member to just a specific portion of the path I think that could be very useful.

[Broxzier]

That's no space efficient way to store patrol information and there's not enough free space available to save that in any tile element, nor is that design very flexible. Tiles shouldn't be aware of what staff members can walk on them, but the other way around.

[pizza2004]

I meant under a new save system, in order to avoid the potentially massive array attached to each individual staff member, but I don't know enough about the structure of the code to know if it's something that would make any sense to do.