View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004406 | Dwarf Fortress | Dwarf Mode -- Jobs, Activity Zones | public | 2011-03-31 08:24 | 2015-06-02 04:37 |
| Reporter | BishopX | Assigned To | Toady One | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.31.25 | ||||
| Fixed in Version | 0.40.05 | ||||
| Summary | 0004406: Hospital zone does not respect cloth maximums | ||||
| Description | 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 | ||||
| Tags | 0.34.02, binary patch, cloth, hospital, stockpiles | ||||
| related to | 0004327 | resolved | Toady One | Hospital Stockpiling still broken |
| related to | 0000191 | resolved | Toady One | Hospital stores more materials than assigned. |
| has duplicate | 0006345 | resolved | Overstocking hospital and theft from caravan | |
| has duplicate | 0007818 | resolved | Hospital Zones don't respect supply maximums | |
| related to | 0006260 | new | Hospital activity zone interferes with strange mood cloth item collection | |
| related to | 0000771 | new | Cloth/Thread partially used by medical dwarfs can't be dyed/woven & they prefer new supplies over used ones | |
| related to | 0007506 | new | Buckets, splint, crutch not availables because of Hospital (used in a task) |
|
|
which version are you using, or in which was the world gened? cause according to toady in 0004327 this one was fixed |
|
|
.25, with a freshly genned vanilla world. Unlike 0004327 I Haven't observed any theft from the dwarven caravan. |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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/ |
|
|
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. |
|
|
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.) |
|
|
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. |
|
|
Isn't this the same as 0000191? (Which, by the way, is *not* fixed, even though it's marked resolved.) |
|
|
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. |
|
|
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. |
|
|
This does indeed seem to be the same as 0000191, and I'm pretty sure Kumquat's theory is correct. |
|
|
I do believe that coffers are holding a lot more now than they used to hold. This may be intentional. |
|
|
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. |
|
|
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) |
|
|
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. |
|
|
Bug is still present in 0.40.02 (not a surprise, but sad). My hospital has Cloth: 582000/50000 |
|
|
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) |
| 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 |
|
Relationship added | related to 0004327 |
| 2011-04-04 06:01 | ndigger | Note Added: 0017050 | |
| 2011-04-04 06:02 | ndigger | Note Edited: 0017050 | |
| 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 |
|
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 | |
| 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 |
|
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 | |
| 2012-02-19 10:59 | Plasson | Tag Attached: 0.34.02 | |
| 2012-02-20 05:47 | Plasson | Note Added: 0020246 | |
| 2012-04-22 06:29 | greycat | Note Added: 0022339 | |
| 2012-04-22 06:29 | greycat | Note Edited: 0022339 | |
| 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 |
|
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-11-01 05:55 | ag | Note Added: 0023700 | |
| 2012-11-01 05:56 | ag | Tag Attached: binary patch | |
| 2013-06-23 23:40 |
|
Relationship added | has duplicate 0006345 |
| 2014-01-27 13:46 |
|
Relationship added | related to 0006260 |
| 2014-01-27 13:48 |
|
Relationship added | related to 0000771 |
| 2014-07-12 15:35 | greycat | Note Added: 0026035 | |
| 2014-07-20 08:32 |
|
Relationship added | related to 0007506 |
| 2014-07-21 03:34 | mostevil | Note Added: 0027112 | |
| 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 |
|
Relationship added | parent of 0007818 |
| 2014-08-12 11:19 |
|
Relationship replaced | has duplicate 0007818 |
