Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
0004406Dwarf FortressDwarf Mode -- Jobs, Activity Zonespublic2011-03-31 08:242015-06-02 04:37
Toady One 
normalminorhave not tried
0004406: Hospital zone does not respect cloth maximums
Hospital zone is currently storing 140,000 units of cloth (all cloth in fortress) when the maximum is set to 20,000. Hospital information screen displays 140,000/20000 cloth stored.

Thread storage appears to be working correctly.

Save is here:

http://dffd.wimbli.com/file.php?id=4095 [^]
0.34.02, binary patch, cloth, hospital, stockpiles
related to 0004327resolved Toady One Hospital Stockpiling still broken 
related to 0000191resolved Toady One Hospital stores more materials than assigned. 
has duplicate 0006345resolved Knight Otu Overstocking hospital and theft from caravan 
has duplicate 0007818resolved Dwarfu Hospital Zones don't respect supply maximums 
related to 0006260new  Hospital activity zone interferes with strange mood cloth item collection 
related to 0000771new  Cloth/Thread partially used by medical dwarfs can't be dyed/woven & they prefer new supplies over used ones 
related to 0007506new  Buckets, splint, crutch not availables because of Hospital (used in a task) 
Issue History
2011-03-31 08:24BishopXNew Issue
2011-03-31 09:17RhenayaNote Added: 0016856
2011-03-31 09:26BishopXNote Added: 0016859
2011-03-31 09:31FootkerchiefRelationship addedrelated to 0004327
2011-03-31 09:45FootkerchiefIssue Monitored: Toady One
2011-04-04 06:01ndiggerNote Added: 0017050
2011-04-04 06:02ndiggerNote Edited: 0017050bug_revision_view_page.php?bugnote_id=0017050#r6351
2011-04-04 06:02ndiggerNote View State: 0017050: private
2011-04-04 06:17BishopXTag Attached: cloth
2011-04-04 06:17BishopXTag Attached: hospital
2011-04-04 06:17BishopXTag Attached: stockpiles
2011-04-04 06:36FootkerchiefNote View State: 0017050: public
2011-05-14 08:18king doomNote Added: 0017723
2011-05-14 09:38king doomNote Edited: 0017723bug_revision_view_page.php?bugnote_id=0017723#r6598
2012-02-16 17:14Toady OneNote Added: 0019878
2012-02-16 17:14Toady OneAssigned To => Toady One
2012-02-16 17:14Toady OneStatusnew => acknowledged
2012-02-17 13:32KumquatNote Added: 0019963
2012-02-17 13:33FootkerchiefIssue Monitored: king doom
2012-02-17 13:33FootkerchiefIssue Monitored: ndigger
2012-02-17 13:33FootkerchiefNote Added: 0019964
2012-02-17 15:07PlassonNote Added: 0019971
2012-02-19 04:38PlassonNote Added: 0020112
2012-02-19 04:42PlassonNote Edited: 0020112bug_revision_view_page.php?bugnote_id=0020112#r7516
2012-02-19 10:59PlassonTag Attached: 0.34.02
2012-02-20 05:47PlassonNote Added: 0020246
2012-04-18 12:40TelarinIssue Monitored: Telarin
2012-04-22 06:29greycatNote Added: 0022339
2012-04-22 06:29greycatNote Edited: 0022339bug_revision_view_page.php?bugnote_id=0022339#r8325
2012-05-02 13:00XelsolNote Added: 0022417
2012-05-18 07:43slinkNote Added: 0022592
2012-05-18 10:58QuietustNote Added: 0022594
2012-05-18 13:22FootkerchiefRelationship addedrelated to 0000191
2012-05-18 14:05slinkNote Added: 0022597
2012-06-20 21:03QuietustNote Added: 0023069
2012-07-09 08:12toybasherNote Added: 0023192
2012-08-14 04:42king doomIssue End Monitor: king doom
2012-11-01 05:55agNote Added: 0023700
2012-11-01 05:56agTag Attached: binary patch
2012-11-01 05:58agIssue Monitored: ag
2012-11-18 12:22arclanceIssue Monitored: arclance
2013-06-23 23:40Knight OtuRelationship addedhas duplicate 0006345
2014-01-15 14:40Kirig Stonebeard IIIssue Monitored: Kirig Stonebeard II
2014-01-17 10:10Kirig StonebeardIssue Monitored: Kirig Stonebeard
2014-01-27 13:46FootkerchiefRelationship addedrelated to 0006260
2014-01-27 13:48FootkerchiefRelationship addedrelated to 0000771
2014-05-07 02:22StebIssue Monitored: Steb
2014-07-12 15:35greycatNote Added: 0026035
2014-07-20 08:32FootkerchiefRelationship addedrelated to 0007506
2014-07-21 03:34mostevilNote Added: 0027112
2014-07-21 03:35mostevilIssue Monitored: mostevil
2014-07-24 14:15Toady OneStatusacknowledged => resolved
2014-07-24 14:15Toady OneFixed in Version => Next Version
2014-07-24 14:15Toady OneResolutionopen => fixed
2014-08-03 10:06DwarfuRelationship addedparent of 0007818
2014-08-12 11:19FootkerchiefRelationship replacedhas duplicate 0007818
2015-06-02 04:37TelarinIssue End Monitor: Telarin
2016-03-08 02:22StebIssue End Monitor: Steb

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
2011-03-31 09:26   
.25, with a freshly genned vanilla world. Unlike 0004327 I Haven't observed any theft from the dwarven caravan.
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 [^]

king doom   
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.

Toady One   
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.
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.
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/ [^]
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.
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.)

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.
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.)

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.
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.
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.
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.
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.
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)
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.
2014-07-12 15:35   
Bug is still present in 0.40.02 (not a surprise, but sad).

My hospital has Cloth: 582000/50000
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)