Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004406Dwarf FortressDwarf Mode -- Jobs, Activity Zonespublic2011-03-31 08:242015-06-02 04:37
ReporterBishopX 
Assigned ToToady One 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version0.31.25 
Target VersionFixed in Version0.40.05 
Summary0004406: Hospital zone does not respect cloth maximums
DescriptionHospital 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 [^]
Tags0.34.02, binary patch, cloth, hospital, stockpiles
Attached Files

- Relationships
related to 0004327resolvedToady One Hospital Stockpiling still broken 
related to 0000191resolvedToady One Hospital stores more materials than assigned. 
has duplicate 0006345resolvedKnight Otu Overstocking hospital and theft from caravan 
has duplicate 0007818resolvedDwarfu 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) 

-  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


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker