New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Two patients in a loop of loo use, keep on re-entering the Toilet room #555
Comments
From mark.l1...@hotmail.co.uk on May 08, 2013 03:00:08 Noticed that there are a couple of "attempt to index local 'hosp'", which I though 0.21 was supposed to have fixed. Was this a new game or an old save? Summary: attempt to index local 'hosp' (was: Patients always returning to toilets) |
From maartenp...@hotmail.nl on May 08, 2013 03:35:09 The gamelog is from the errors using version 0.20 (see gamelog.txt.) Summary: Patients always returning to toilets (was: attempt to index local 'hosp' ) |
From mark.l1...@hotmail.co.uk on May 08, 2013 07:49:37 It looks like that there have been other errors with the save as one patient is stuck going home. One of the patients has no history, this suggests he has not past reception yet. They both appear to be locked into using the loo and are about to die, this is similar to the error when Dr's get stuck in a loop of not going for a break and the patient starts to die whilst waiting. Only similar in that the dealt with bit has not happened correctly so they can move on. So, does this mean they have no next action to do? Given the age of the save, it is not connected to the recent change in loo use - which I am glad about. Perhaps Edvin will have some ideas, so I'll queue this - he is not really available now until June. Summary: Two patients in a loop of loo use, keep on re-entering the Toilet room (was: Patients always returning to toilets) |
My clue: this will happen when there are more patients trying to get on toilet then number of toilets in the room. Next clue: ...maybe it's connected with pateints which will pee outside while they are in toilet queue. I've made my own game change, so I'm playing with random number of spawn patients (1, 1500). So there are moments, when I have 1000 - 1300 patients in hospital, and moments when almost nobody is there. And this issue happens only when big crowd is everyvere... Version: 0.40 |
That should be free toilets that limits who can enter the room, we changed it from the number of loos a couple of years ago. |
I haven't been able to reproduce this myself lately. |
Perhaps sdl2 is more stable! |
Haven't tested on SDL2 (I haven't been able to compile) only 0.40 but on a different save. |
The original link above was meant to work, but @Lego3 ticked something on googlecode that now means you cannot access it. I noticed the same applies to other links we have in the suggestions wiki etc. I don't think this was intended, so I wonder if it is worth removing that for the time being Edvin? |
Ok, let's have it open for a while longer. I would just like to close the google code project to avoid people reading outdated things there. |
I have downloaded all the attachments onto my server, I can do the same for the other issues too, if needed. |
New final (I hope) clue: Example: 5 patients arrive to toilet and they makes queue outside of door. If the first one pee on floor, it's OK, nothing happen. But if second one (or other after) pee on the floor, it makes him try to find another toilet room. And that's the source of problem because he will spend rest of his life finding toilet room (if I will not kick him out from hospital). Fact 1) Fact 2) I hope that my clue it The One. :-) |
It appears to be, that Room:tryToFindNearbyPatients is called for the toilet. That long queue is a good indicator to when tryToFindNearbyPatients will run and perform the tryMovePatient code. This code will automatically set next_room_to_visit if it does calculate that a move should occur, and upon doing so it will put it in a loop via the ToiletRoom:dealtWithPatient code. Either could avoid tryToFindNearbyPatients (by overriding method), or have dealtWithPatient swing them by reception again, and get them to gps office to start again. if they are trying to find the toilets (also would need reception not to send them to the toilets). |
Just to clarify the situation, the tryMovePatient guards against the redirection occuring if patient.going_to_toilet == "yes" essentially. However if the queues are long enough, the patient going to the toilet whilst in the queue (fact 2) will reset them to "no" and they will fall into this redirection loop. I can't recall what the original did, if the patient ended up having the toilet need go, whilst they were on the way to the toilet, if they remained continuing on, or if they proceeded to the next step. Also, if the patient is seated, and they get the call to Patient:pee this incorrectly executes and resets the no value, and sets the toilet_need to a lower amount than the threshold. So currently benches reduce toilet need. |
Just also noting with this code CorsixTH/CorsixTH/Lua/entities/humanoids/patient.lua Lines 791 to 794 in 1dd1672
The patients toilet need is adjusted prior to the actions completing, whereas when they use the toilets its deferred to the room to handle it after toilet use. |
I can't seem to replicate this in 0.64... @mugmuggy did you have any input on if this still happens? |
None of the changes I made corrected this. I did look at trying to get the going_to_toilet flag to persist nicely but it did introduce a side effect but I can't recall exactly what that was but it was separate to the PR at the time and might have just required more thought. To replicate need to have many patients wanting to use the toilet. They need to queue at the toilet and be the 2nd or later in queue position (to enter). Whilst in the queue they need to pee, before entering the toilet. At the same time you want to pause (just to get timing right) and build another toilet, which will do the Room:tryToFindNearbyPatients call which sets the next_room_to_visit for the patient in tryMovePatient, which the guard for going to toilet is now bypassed due to the pee call occuring. I replicated this in the save from 1455. You'll see patients with toilet need icons, who have a toilet need less than threshold that are seated. Because they are seated the pee action doesn't complete, build a toilet and a handful or so stream in. But make Patient:pee return true only if the actions were queued, and check for that in patient tickDay - the code in my previous comment, don't adjust need/going_to_toilet - build toilet with a single cubicle and you'll have 40+ patients queue. Some of these patients will pee now in the queue, and thus give you a chance to build another toilet, that they hopefully get redirected and enter the loop. Obviously this is manipulating the state, to support what can happen randomly. It is more than likely only going to happen when a new room is built (ref 1337) as the getUsageScore only takes into account the currently queued count, and nothing with the expected (which was broken anyway, ref 1568). Likewise the patients probably shouldn't pee whilst walking to a toilet/queuing for a toilet or if they do, skip going to the toilet and resume at the next point. |
From wolfy1...@gmail.com on May 07, 2013 17:33:54
What steps will reproduce the problem? 1.i am not sure how to reproduce this problem. 2. 3. What is the expected output? What do you see instead? A patient that just used the toilets returns even though he does not need to.
What version of CorsixTH are you using (e.g. "Beta 2", "SVN r123 ")?
0.21 What operating system / compile settings are you using? Windows 8 Pro 64 bit
What level was this on (e.g. "Demo level", "Full game level 12")?
Full Game level Attach a saved game file (preferably an autosave from before the error) if you have one and it is relevant. Please provide any additional information
Attachment: config.txt gamelog.txt thomas01.sav
Original issue: http://code.google.com/p/corsix-th/issues/detail?id=1623
The text was updated successfully, but these errors were encountered: