action queue: Substituted Diagnosis Room is not checked for agreesToPay

[lewri]

#2208

Not fixing this in PR above but may in future.

When the action queue chooses a different diagnosis room for a patient (because the GP's selected one wasn't available) we just blindly assume the patient will pay. Open to discussion if this should be fixed or not.

[Alberth289346]

Hmm, two questions:

1. Why is the action rewriting the doctors choice? I mean, I often get "patient need OP, should it wait for you building one?" even when building an OP isn't even possible! You'd hope a doctor in a hospital knows what rooms exist or (oh well) are available for build, in my view.
2. I don't see why the patient is not asked to agree.

[lewri]

I'm not sure why the action queue does it. It probably shouldn't. In the short term though I don't want to change it myself.

I believe the example you have might be to do with a diagnosis (or treatment room) being discovered but not yet built. Though I think it sometimes trips up (because the patient is meant to be sent home if we ran out of diagnosis rooms), so not perfect I think.

[Alberth289346]

It definitely trips up, my first reaction is always to try building it, and it's not always there.

[lewri]

1. I often get "patient need OP, should it wait for you building one?" even when building an OP isn't even possible!

Just to note, I'm trying to work out how this stuff occurs at the moment and will report back when I have.

[lewri]

So some tinkering: When the patient leave the GP office they have multiple paths they could take for their next action (seek_room).

1. The patient goes to the next diagnosis room (assuming they agree to pay)
2. The patient goes to their treatment room (assuming they agree to pay)
3. A patient is sent home because we ran out of diagnostic equipment (did not exceed the Send Home value)
4. A patient is sent home because they refused to pay for diagnostic step/treatment
5. A patient's disease has not been discovered yet, and we have diagnosed them enough not to send them home automatically (player input fax -- send home/build more diagnosis rooms)
6. A patient has been diagnosed enough to not be sent home, and we have some confidence in the type of disease they have (below Guess at Cure value) (player input fax -- send home/build more diagnosis rooms/guess at cure)
7. A patient has been diagnosed but we don't have an available treatment room (player input fax -- send home/send to research dept (if treatment room not discovered)/wait)

All of these except for diagnostic step in scenario 4 touch the seek_room action. In scenario 1 the GP properly calls the seek room action for the diagnosis room (albeit creeping out of scope, it's at least close). In scenario 2 and 3 it is executed either for GP or seek_room (why?) Scenario 5, 6, and 7 all seem to call to the hospital for a fax from seek_room. Side note: seek_room does some odd stuff to the no treatment room fax as callbacks.

[Alberth289346]

When you start coding something you typically start with the happy flow. Once that is running, you find there are also non-happy flow cases to deal with, and these then get detected and handled in whatever you have at the time, at a right looking spot.

If you start instead by considering all the possible behavior and options first, and then design code for it, you basically handle all the bad flows, and at the end you're left with the happy flow. Just the other way around thus.

So what you observe is the history of the code. It started with "seek_room", and further down the road other paths were added (probably by other programmers).

Your list looks nicely complete, this is the kind of decision list that belongs in an NPC life rather than ad-hoc in all the code around it, imho.

[Alberth289346]

What should be added here eventually is handling of unreachable rooms.

[mugmuggy]

Scenario 1 - diagnosis is randomly chosen, if the room doesn't exist, the agrees to pay drops to using the hospital reputation. Patient:getPriceDistortion takes into account the casebook.price which isn't the dollar value but the percentage in the casebook 50-200% relative to reputation (plus the other weighting factors) so its not directly to the specific room, but they are agreeing to pay by proxy. You wouldn't want to wait x days then go decide that you don't want to go to the diagnosis room.

Scenario 2 and 3 - agreesToPay called from seek_room when diagnosis progress above the guess at cure threshold and no further diagnosis can be done, sends them for treatment not diagnosis, essentially upgrade from seek diagnostic to seek treatment so is asking again as treatments vary in cost greatly again if its not built will proxy via hospital rep

Scenarios 5, 6, 7 - the call backs - update the fax content on game state which can change between creation and opening of the fax

I can see how some of this could fall back into patient to do.