Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009784Dwarf FortressDwarf Mode -- Interface, Managerpublic2016-05-23 06:342016-07-03 15:11
ReporterSchwartz 
Assigned Tolethosor 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionduplicate 
PlatformWindowsOSWindowsOS Version8.1 x64
Product Version0.43.02 
Target VersionFixed in Version 
Summary0009784: Job Manager does not respect item conditions
DescriptionPerpetual orders do not respect item conditions. If you make a ONE-TIME, CHECKED DAILY order with an item limit, the order will continue despite those limits. I had a coal production order with an AT MOST condition of 100 coal. Half an hour later I have 700 coal sitting in the fortress and see the order still continue to produce despite the managing interface correctly colouring the condition red.

Similarly, I had a bunch of one-time, checked daily orders set to automate various productions around my fortress. They all had an AT LEAST order set so they wouldn't exhaust my stockpiles of bone, dye, empty food storage items etc. entirely. All of these orders kept running until I got job cancellation spam. And that spam would not stop until I manually removed those orders.

- - - - -

Even if you make a repeating order, checked monthly, seasonally or yearly - that job will still trigger if item conditions are not met. There's already a bug report floating around for this, bu for clarity's sake it should be said that this is not an issue with how repeating perpetual orders work - they don't work correctly for the same reason that one-time perpetual orders don't. (http://www.bay12games.com/dwarves/mantisbt/view.php?id=9741 [^])

I also noticed that item conditions have an extremely inaccurate way of counting some items. Setting food production to an AT MOST limit of 1000 unrotten prepared meals or 1000 unrotten drinks will continue to produce despite as outlined above. The interesting point here is when the condition turns from green to red. As an experiment, make one of these orders and look at your available meals / drinks. Now adjust the number in the conditions screen and see when it changes colour. This number does not correspond to the real number of items in the fortress. I.e. a 1000 item condition will not turn red until there's about 1800 actual items in the fortress. 1000 items in the fortress similarly require a much lower item condition (less than half) to have it change colour. This has nothing to do with rotten items, either.
Steps To ReproduceMake a perpetual production order with an AT LEAST or an AT MOST condition that limits production. Make it ONE-TIME, CHECKED DAILY. For example a coal production order whose condition is that there are AT MOST 100 pieces of coal in the fortress. Or a bone bolt production order whose condition is that there are AT LEAST 5 pieces of workable bone left.
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0009741new  Job Manager - Perpetual orders with conditions never stop 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-05-23 06:34SchwartzNew Issue
2016-06-09 22:47BumberNote Added: 0035389
2016-06-09 22:49BumberNote Edited: 0035389bug_revision_view_page.php?bugnote_id=0035389#r14258
2016-06-09 22:50BumberNote Edited: 0035389bug_revision_view_page.php?bugnote_id=0035389#r14259
2016-06-09 22:54BumberNote Edited: 0035389bug_revision_view_page.php?bugnote_id=0035389#r14260
2016-06-09 22:54BumberNote Edited: 0035389bug_revision_view_page.php?bugnote_id=0035389#r14261
2016-06-09 22:55BumberNote Edited: 0035389bug_revision_view_page.php?bugnote_id=0035389#r14262
2016-06-09 22:57BumberNote Edited: 0035389bug_revision_view_page.php?bugnote_id=0035389#r14263
2016-06-11 16:28VerouleNote Added: 0035395
2016-06-12 23:46BumberNote Added: 0035398
2016-06-12 23:48BumberNote Edited: 0035398bug_revision_view_page.php?bugnote_id=0035398#r14276
2016-06-12 23:53BumberNote Edited: 0035398bug_revision_view_page.php?bugnote_id=0035398#r14277
2016-06-12 23:54BumberNote Edited: 0035398bug_revision_view_page.php?bugnote_id=0035398#r14278
2016-06-12 23:56BumberNote Edited: 0035398bug_revision_view_page.php?bugnote_id=0035398#r14279
2016-06-21 05:23SchwartzNote Added: 0035440
2016-07-02 02:58BumberNote Added: 0035543
2016-07-02 03:10BumberNote Added: 0035544
2016-07-03 15:11lethosorRelationship addedduplicate of 0009741
2016-07-03 15:11lethosorStatusnew => resolved
2016-07-03 15:11lethosorResolutionopen => duplicate
2016-07-03 15:11lethosorAssigned To => lethosor

Notes
(0035389)
Bumber   
2016-06-09 22:47   
(edited on: 2016-06-09 22:57)
Conditions aren't end conditions, they're (re)start conditions. Perpetual orders never end, so they're never re-checked. Set a quantity limit if you want an order that stops.

Unintuitive, but not a bug. There might be some kind of workaround for what you want involving co-dependency on a second identical order's completion (i.e., they take turns) that gets broken when one of them fails. Otherwise, just create an order for 100 items, and then create another if you undershot the limit.

The inaccurate count is due to tasked items.
(0035395)
Veroule   
2016-06-11 16:28   
Bumber, the perpetual is in the place of quantity on the order. It means that the quantity being ordered is infinite. All the condition tests that occur on an order for 10 jobs should be tested the same way on orders for 100, 1000, 10K, 10M, 4B, and infinity count of jobs.

Think of the (O)rders menu and auto-tan, auto-loom, auto-kitchen, etc. These are perpetual orders, and the job is only created when the correct conditions exist. We simply expect the same from the manager controlled work orders, and when it is there then removal of those auto-xxxx orders would be good.
(0035398)
Bumber   
2016-06-12 23:46   
(edited on: 2016-06-12 23:56)
Unless I'm mistaken, they are all treated the same way. Say, for instance, you set quantity to 10 and create a condition for at least 10 of an input. The job will start once you meet that condition, and will not stop early if you use up some of those on another task. You'll keep getting occasional cancel spam until you provide more input items to finish the batch. Then it will wait for another 10 inputs to become available before starting again (if it wasn't changed to a single-time order.)

Auto-orders are not perpetual orders. They create a single do-once task on a single workshop each time. They can be thought of as quantity 1 repeat orders. Perpetual orders are like a repeat task ('r' on a workshop job) that refuses to cancel, or as the old manager orders without a quantity limit. (At least they don't flood all the workshop slots anymore.)

Basically, there's no reason to have a perpetual order repeat, because it's the same as a perpetual single-time. (Adding conditions to an order automatically changes it to repeating, but you can switch back.)
(0035440)
Schwartz   
2016-06-21 05:23   
Yep, I agree that conditions are (re)start conditions. But perpetual orders should not run forever if their condition is set to one-time, checked daily. That is the whole point of difference between repeating conditions and one-time conditions.

You may call it unintuitive, I say it's not working as intended. Because if you have a difference in settings with no discernable difference in outcome, then that setting is either pointless or the system doesn't handle it like it's supposed to. I hope it's the latter.
(0035543)
Bumber   
2016-07-02 02:58   
Well, what do you expect to happen when a quantity 5 repeating order loses a condition (e.g., 5 unrotten bones) during the middle of a batch (because it used one)? Does the order halt for the bones to return to 5, or does it continue to process the remaining 4 bones of the order? This is what the perpetual order behavior is an extension of.
(0035544)
Bumber   
2016-07-02 03:10   
Also, this is a duplicate of 0009741.

I made a suggestion (since I don't consider it a bug) about changing this behavior to something more intuitive a while back: http://www.bay12forums.com/smf/index.php?topic=158631 [^]