Disallow firing staff who are currently fixing or inspecting rides

[ZehMatt]

This may lock up the ride when staff is fired at the right time, since staff manipulates the state of the ride status there is no work-around without enabling exploits that people can use to immediately fix rides by sending mechanics in and then immediately fire them. I think this solution is the right way to solve the problem without adding any complex extra logic on top of.

Here is a park where I isolated the problem:
0_Everything_Park_Unfixable_ride.zip

With this PR when you try to fire mechanics that are either inspecting or fixing the ride you'll get an error as shown below:

Also in order to reproduce this you have to fire the mechanic at the right time, ActionFrame has to be 0x28 in order for this bug to trigger, that's where it sets the new mechanic status on the ride and would set it to completed in another sub state.

[AaronVanGeffen]

Would it be easy / feasible to disable the fire button in the interface as well, depending on the staff/mechanic status?

[karst]

Would it be easy / feasible to disable the fire button in the interface as well, depending on the staff/mechanic status?

An issue then would be that if someone initiated the fire button before entering it will still have the pop-up so you could still actually get rid of them. Tho greying out the bin might be a clean extra.

[AaronVanGeffen]

An issue then would be that if someone initiated the fire button before entering it will still have the pop-up so you could still actually get rid of them. Tho greying out the bin might be a clean extra.

Yes, I realised the game action would still need to perform the check. Greying out the button is just for UX purposes.

[ZehMatt]

Would it be easy / feasible to disable the fire button in the interface as well, depending on the staff/mechanic status?

Not a bad idea, however might be best to separate the UI change from this logical change.

[rik-smeets]

LGTM, just have two suggestions for the string literals.

(And the changelog/network version of course but those are already labelled as to do's)

[rik-smeets]

I also added the disabling of the fire button in the window in a separate commit.

[ZehMatt]

Tested and all good, unfortunately people who ended up in this situation have to use cheats to make the ride work again, I don't want to make any assumptions during import about a complicated state especially when staff is the one where the sub state drives the repair/inspection state, I rather not make any assumptions, its even possible that a new mechanic has been hired meanwhile who has the same id as the one who previously was on the ride, so from here on its impossible to get into this dilema.