0004406: Hospital zone does not respect cloth maximums

Notes
(0016856) Rhenaya (reporter) 2011-03-31 09:17	which version are you using, or in which was the world gened? cause according to toady in 0004327 this one was fixed

(0016859) BishopX (reporter) 2011-03-31 09:26	.25, with a freshly genned vanilla world. Unlike 0004327 I Haven't observed any theft from the dwarven caravan.

(0017050) ndigger (reporter) 2011-04-04 06:01 edited on: 2011-04-04 06:02	I can also report that this bug has returned to life as of df 31.25. - This world was generated fresh in 31.25, using modded raws carefully hand-diffed from their predecessors which were written in 31.23 - This fort is 2-3 years old - I created the hospital zone from a flow-designation - It contains 8 coffers, 8 cabinets, 8 beds, 8 traction benches, and 8 tables - 2\10 crutches (plenty available) - 8\10 splints (plenty available) - 5\10 buckets (plenty available) - 180000\60000 cloth - 130000\50000 thread - I didn't observe anyone stealing from the caravan, but I have purchased (via legitimate trade) all cloth and thread that any merchant has brought around so far, except the first time the humans came because I pissed them off with excessive haggling. - I've destroyed and recreated the hospital zone (which did not fix the problem) but have not tried removing the zone and all of the buildings at the same time. - Save: http://dffd.wimbli.com/file.php?id=4127 [^]

(0017723) king doom (reporter) 2011-05-14 08:18 edited on: 2011-05-14 09:38	world created new in 31.25 and yeah, this bug is still here, my dwarves fill my hospital zone with every bit of cloth on the map I own, leaving no room for any other resources in the hospital. I'm 100% sure I've reported this exact same issue elsewhere before, but messing around with it I've discovered that dwarves wont stock anything in a hospital if the cloth is inaccesible, behind a tightly locked door for instance. Stuff that's in the open like casts or splints wont get touched till the cloth is available or forbidden.

(0019878) Toady One (administrator) 2012-02-16 17:14	I couldn't get this to reproduce, and I couldn't get any information from the saves or by staring at the code. I'll probably need some kind of sweet-spot save where they haven't stockpiled or even selected anything yet, but will select bad cloth shortly.

(0019963) Kumquat (reporter) 2012-02-17 13:32	I have gotten this quite a few times. I usually build the hospital before designating the zone, so here's one thing to test: 1. Have a good number of idlers and plenty of cloth 2. Build a bunch of containers 3. Designate hospital zone over them Theory: hospital doesn't count cloth/thread/whatever that's been tasked to be stored, only what is actually stored. Then it keeps spamming new jobs until it is fully stocked, but there are still bunch of jobs underway that make it 'overflow'. Fix suggestion: create jobs to move excess back to stockpiles.

(0019964) Footkerchief (manager) 2012-02-17 13:33	Reminder sent to: BishopX, king doom, ndigger Toady: "I couldn't get this to reproduce, and I couldn't get any information from the saves or by staring at the code. I'll probably need some kind of sweet-spot save where they haven't stockpiled or even selected anything yet, but will select bad cloth shortly." Can anyone produce such a save? You can upload to http://dffd.wimbli.com/ [^]

(0019971) Plasson (reporter) 2012-02-17 15:07	My Hospitals always overstock on cloth(31.25 and now), usually have to keep adding containers to ensure I have stocks of the other various bits. Poised to start my second fort in 34.01. so If i remember it, I'll try and get a save, unless beaten to the punch. Atleast plaster seem to stock properly now.

(0020112) Plasson (reporter) 2012-02-19 04:38 edited on: 2012-02-19 04:42	Here is a save of my current fort in 34.02, though the behaviour is pretty much like in the last 2 versions. I've dug out and placed chests/bags and beds on the left, past my foodstorage and dininghall on Zlevel 9. Just designate a Hospital zone in that room, and watch the cloth craze begin. http://dffd.wimbli.com/file.php?id=5603 [^] It's with Ironhand's Tileset package for .02 Played on afterwards and as they stopped moving more to the hospital it ended at: Thread 15,000/75,000 Cloth 440,000/50,000 (so 9 times more than specified) Splints 4/5 (have more in stock) Crutches 1/5 (have more in stock) Powder for casts 0/750 (not found gypsum on the map and caravans yet) Buckets 0/2 (3 sitting right there in my furniture stockpile) Soap 0/750 (haven't got that industry rolling properly yet.)

(0020246) Plasson (reporter) 2012-02-20 05:47	Forget what I Said about plaster. though I've seen at the standard max previously, my hospital stocks now have twice the specified plaster (1500/750) And overstocked on thread, and buckets (5/2) this happened after I added some more bags and chests since I had a patient needing immobilisation, but no powder had been stored in the hospital zone resulting in no action from the medical team.

(0022339) greycat (reporter) 2012-04-22 06:29 edited on: 2012-04-22 06:29	Isn't this the same as 0000191? (Which, by the way, is not fixed, even though it's marked resolved.)

(0022417) Xelsol (reporter) 2012-05-02 13:00	Experienced this in my recent fort. Easily fixed by dumping a container and waiting for it to be refilled with the proper supplies before designating another to be dumped. Prevent the issue in the first place by building containers one by one.

(0022592) slink (reporter) 2012-05-18 07:43	In 34.09, I placed a single coffer in a hospital zone. It now contains: Thread: 105000/75000 Cloth: 290000/50000 Splints: 6/5 Crutches: 3/5 (more are available in fortess) Powder for casts: 1500/750 Buckets: 1/2 (more are available in fortess) Soap: 0/750 (none available in fortress) These contents are visible with [t] and not with [k], so they are in the coffer. I am accustomed to over-runs on supplies carried to the hospital, but this seems like a bit much for one coffer. Save reserved in case you want to see it.

(0022594) Quietust (reporter) 2012-05-18 10:58	This does indeed seem to be the same as 0000191, and I'm pretty sure Kumquat's theory is correct.

(0022597) slink (reporter) 2012-05-18 14:05	I do believe that coffers are holding a lot more now than they used to hold. This may be intentional.

(0023069) Quietust (reporter) 2012-06-20 21:03	The 'buildingst' class has a vmethod for determining a building's available capacity, and it has an option to include pending jobs ("Store Item in Chest", "Store Item in Cabinet", or "Store Item in Hospital") which is what prevents the game from simultaneously issuing enough jobs to fill the building beyond its capacity. The same thing is presumably true for bins and barrels. However, the buildingst vmethod for counting up hospital supplies (the 3rd one) does not count pending jobs, only items which are actually stored inside the building - presumably, this is why a hospital which needs one more of a particular item item ends up generating enough jobs to completely fill all remaining space in all of its containers.

(0023192) toybasher (reporter) 2012-07-09 08:12	Confirmed in 0.34.11 My hospital was at the previous max, then suddenly overstocked with thread, cloth, and maybe plaster once I had a dwarf hurt by goblins (I used a cheat to kill the goblins because my militery just wasnt ready yet, but thats ilrellivent) I also built another chest in the hospital after trading for plaster, this was after the dwarf recovered but I cannot be completely sure. It might have started once I built the second chest. According to Quietust, whats happening is the hospital zone isn't including pending jobs. Basicly, we have the hospital going "GIMME ONE CLOTH. GIMME ONE CLOTH. GIMME ONE CLOTH." constantly, athough it only needs one cloth, each request is seperete, which causes the overstocking because it produces MANY jobs to refill it, and by the time it gets the one cloth it needs, theres already a large number of jobs already issued to refill it, resulting in overstocking. The hospital should be including pending jobs, like what Quietust said. This should result in the hospital going "Give me one cloth, alright, the job was issued to give the unit of cloth I requested. No other job to restock cloth shall be preformed unless the job I issued was canceled." (If two cloths are needed, the hospital shall only issue two cloth requests, etc)

(0023700) ag (reporter) 2012-11-01 05:55	Funnily enough, the game does count items in Bring to Hospital jobs, and does add the amounts to the counters immediately when it creates those jobs. However, both of those operations are very subtly broken. 1. When it recomputes the current hospital amounts from scratch, e.g. in a building update vmethod every 100 frames, or when you open the Zone menu, it loops through all jobs and tries to count items in those that belong to the hospital. However, in order to check that, it retrieves the BUILDING_DESTINATION link of the job, which points to the _chest_, and compares it with the _hospital building itself_ - which obviously doesn't work. 2. When it adds amounts to the counters immediately after creating a job, it uses the wrong building pointer which is left over from a previous loop, and is essentially garbage. The code would look like this: for (i = zones.size()-1; i >= 0; i--) { cur_zone = zones[i]; ... } if (found zone) { add job; cur_zone->appropriatecounter += amount } This works correctly in one and only one case: when the hospital is the very first activity zone in the vector. Binary patches: v0.34.11 linux: http://pastebin.com/NUDvuZU6 [^] v0.34.11 windows: http://pastebin.com/8CfRwxae [^] Caveat: if you have two or more hospitals, both of them will count all pending jobs as their own due to the completely disabled destination check.

(0026035) greycat (reporter) 2014-07-12 15:35	Bug is still present in 0.40.02 (not a surprise, but sad). My hospital has Cloth: 582000/50000

(0027112) mostevil (reporter) 2014-07-21 03:34	One thing I have noticed is that the mountain of cloth/thread appears to have been dumped on the container, not placed inside the containers. Not sure if this is the cause, due to the excessive quantities or just a bug in how the containers work. (there's nothing inside the chests)

Issue History
Date Modified	Username	Field	Change
2011-03-31 08:24	BishopX	New Issue
2011-03-31 09:17	Rhenaya	Note Added: 0016856
2011-03-31 09:26	BishopX	Note Added: 0016859
2011-03-31 09:31	Footkerchief	Relationship added	related to 0004327
2011-03-31 09:45	Footkerchief	Issue Monitored: Toady One
2011-04-04 06:01	ndigger	Note Added: 0017050
2011-04-04 06:02	ndigger	Note Edited: 0017050	View Revisions
2011-04-04 06:02	ndigger	Note View State: 0017050: private
2011-04-04 06:17	BishopX	Tag Attached: cloth
2011-04-04 06:17	BishopX	Tag Attached: hospital
2011-04-04 06:17	BishopX	Tag Attached: stockpiles
2011-04-04 06:36	Footkerchief	Note View State: 0017050: public
2011-05-14 08:18	king doom	Note Added: 0017723
2011-05-14 09:38	king doom	Note Edited: 0017723	View Revisions
2012-02-16 17:14	Toady One	Note Added: 0019878
2012-02-16 17:14	Toady One	Assigned To	=> Toady One
2012-02-16 17:14	Toady One	Status	new => acknowledged
2012-02-17 13:32	Kumquat	Note Added: 0019963
2012-02-17 13:33	Footkerchief	Issue Monitored: king doom
2012-02-17 13:33	Footkerchief	Issue Monitored: ndigger
2012-02-17 13:33	Footkerchief	Note Added: 0019964
2012-02-17 15:07	Plasson	Note Added: 0019971
2012-02-19 04:38	Plasson	Note Added: 0020112
2012-02-19 04:42	Plasson	Note Edited: 0020112	View Revisions
2012-02-19 10:59	Plasson	Tag Attached: 0.34.02
2012-02-20 05:47	Plasson	Note Added: 0020246
2012-04-18 12:40	Telarin	Issue Monitored: Telarin
2012-04-22 06:29	greycat	Note Added: 0022339
2012-04-22 06:29	greycat	Note Edited: 0022339	View Revisions
2012-05-02 13:00	Xelsol	Note Added: 0022417
2012-05-18 07:43	slink	Note Added: 0022592
2012-05-18 10:58	Quietust	Note Added: 0022594
2012-05-18 13:22	Footkerchief	Relationship added	related to 0000191
2012-05-18 14:05	slink	Note Added: 0022597
2012-06-20 21:03	Quietust	Note Added: 0023069
2012-07-09 08:12	toybasher	Note Added: 0023192
2012-08-14 04:42	king doom	Issue End Monitor: king doom
2012-11-01 05:55	ag	Note Added: 0023700
2012-11-01 05:56	ag	Tag Attached: binary patch
2012-11-01 05:58	ag	Issue Monitored: ag
2012-11-18 12:22	arclance	Issue Monitored: arclance
2013-06-23 23:40	Knight Otu	Relationship added	has duplicate 0006345
2014-01-15 14:40	Kirig Stonebeard II	Issue Monitored: Kirig Stonebeard II
2014-01-17 10:10	Kirig Stonebeard	Issue Monitored: Kirig Stonebeard
2014-01-27 13:46	Footkerchief	Relationship added	related to 0006260
2014-01-27 13:48	Footkerchief	Relationship added	related to 0000771
2014-05-07 02:22	Steb	Issue Monitored: Steb
2014-07-12 15:35	greycat	Note Added: 0026035
2014-07-20 08:32	Footkerchief	Relationship added	related to 0007506
2014-07-21 03:34	mostevil	Note Added: 0027112
2014-07-21 03:35	mostevil	Issue Monitored: mostevil
2014-07-24 14:15	Toady One	Status	acknowledged => resolved
2014-07-24 14:15	Toady One	Fixed in Version	=> Next Version
2014-07-24 14:15	Toady One	Resolution	open => fixed
2014-08-03 10:06	Dwarfu	Relationship added	parent of 0007818
2014-08-12 11:19	Footkerchief	Relationship replaced	has duplicate 0007818
2015-06-02 04:37	Telarin	Issue End Monitor: Telarin
2016-03-08 02:22	Steb	Issue End Monitor: Steb