[RFC] Change how staff find work #2133
Conversation
| --! Checks if the room still needs the staff in it and otherwise | ||
| -- sends them away if they're needed somewhere else. | ||
| function Room:findWorkForStaff() | ||
| -- If the staff member is idle we can send him/her somewhere else | ||
| for humanoid in pairs(self.humanoids) do | ||
| -- Don't check handymen | ||
| if class.is(humanoid, Staff) and humanoid.humanoid_class ~= "Handyman" and humanoid:isIdle() then | ||
| self.world.dispatcher:answerCall(humanoid) | ||
| end | ||
| end | ||
| end |
There was a problem hiding this comment.
I still like the idea of having an immediate find work at the end of the consult. Is there a specific consequence if we left this in with the new code?
I suppose the worst of it in removing this code is that the staff member takes a day to find new work.
There was a problem hiding this comment.
On reflection I think I prefer the balance you have chosen, so happy to dismiss my above comment.
There was a problem hiding this comment.
I did toss up leaving it in as well, hence leaving it more as a proposal. The original has decisions and logic processed on part day ticks. I assume so some logic doesn't run every tick but also some more frequently than once per day. This probably sits in one of those in the original.
There was a problem hiding this comment.
Actually doesn't this function only get called from GP Office?
There was a problem hiding this comment.
As per above. Only GP Office used this function. Maybe that was part of the problem too.
|
I would like to see this one make the next release, as it does offer quite a marked improvement to finding work. |
Is this significant to occur; or would it have a significant impact on gameplay if it happened? |
Penalise finding work if in a room
| for _, staff in ipairs(self.staff) do | ||
| if staff:isIdle() then | ||
| self.world.dispatcher:answerCall(staff) | ||
| end | ||
| end |
There was a problem hiding this comment.
On reinspecting some code, we do use idle a fair bit for some actions as a wait (I found vaccinate and multi-use object). Would these likely get misinterpreted by this code?
There was a problem hiding this comment.
Just judging by the question, it seems to me that isIdle is ambiguous. So one step is to decide yes or no on your question and then document it with isIdle, possibly also improving the name of the function to better match its use.
Also, you may want to split its use between 2 or more functions with different names, so it becomes easier to get the right function. To assist the programmer, it's likely a good idea to mention the related functions in lua doc and/or put them close together, to improve the chance the right function gets found.
As for the functionality, in the calls dispatcher you added not staff:getRoom() as condition, which apparently means "a wandering staff member". While I'd prefer an explicit function for that notion, eg hasNoWork or so, that check may possibly be good here?
There was a problem hiding this comment.
If you add a new function for the latter, please also add a link to that in the lua doc of getRoom to avoid further spreading of the getRoom function for this purpose.
Another measure that can be done is to make the getRoom private, although that has much larger consequences (it should be called with self only), not sure if that is feasible.
There was a problem hiding this comment.
isIdle is actually quite a hefty function to determine a true idle state now that I got round to reading it. It is definitely much more than the mere IdleAction I thought it was. It's documented inside nicely enough in the function, not for doc though.
This is a proposal to address these issues. The fix has had some funky behaviour in scenarios where a Dr calls to the room, patient leaves for toilet, before call is completed, then the staff member leaves the room and heads to the next room, where the same thing occurs and ended up returning to the same first room.
There is also a change to prefer wandering staff but not sure how effective that is at the moment to get them, due to the weighting of fatigue beforehand. For when excess staff are employed and they leave staff room after rest and there is no call, they start wandering, but they'll have near 0 fatigue and all else being equal is a distance difference of 10 tiles to have the staff leave the room instead.
Fixes #1582/#2060
Describe what the proposed change does