View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009784 | Dwarf Fortress | Dwarf Mode -- Interface, Manager | public | 2016-05-23 06:34 | 2016-07-03 15:11 |
| Reporter | Schwartz | Assigned To | lethosor | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | duplicate | ||
| Platform | Windows | OS | Windows | OS Version | 8.1 x64 |
| Product Version | 0.43.02 | ||||
| Summary | 0009784: Job Manager does not respect item conditions | ||||
| Description | Perpetual 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 Reproduce | Make 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. | ||||
| Tags | No tags attached. | ||||
| duplicate of | 0009741 | new | Job Manager - Perpetual orders with conditions never stop |
|
|
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. |
|
|
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. |
|
|
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.) |
|
|
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. |
|
|
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. |
|
|
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 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-05-23 06:34 | Schwartz | New Issue | |
| 2016-06-09 22:47 | Bumber | Note Added: 0035389 | |
| 2016-06-09 22:49 | Bumber | Note Edited: 0035389 | |
| 2016-06-09 22:50 | Bumber | Note Edited: 0035389 | |
| 2016-06-09 22:54 | Bumber | Note Edited: 0035389 | |
| 2016-06-09 22:54 | Bumber | Note Edited: 0035389 | |
| 2016-06-09 22:55 | Bumber | Note Edited: 0035389 | |
| 2016-06-09 22:57 | Bumber | Note Edited: 0035389 | |
| 2016-06-11 16:28 | Veroule | Note Added: 0035395 | |
| 2016-06-12 23:46 | Bumber | Note Added: 0035398 | |
| 2016-06-12 23:48 | Bumber | Note Edited: 0035398 | |
| 2016-06-12 23:53 | Bumber | Note Edited: 0035398 | |
| 2016-06-12 23:54 | Bumber | Note Edited: 0035398 | |
| 2016-06-12 23:56 | Bumber | Note Edited: 0035398 | |
| 2016-06-21 05:23 | Schwartz | Note Added: 0035440 | |
| 2016-07-02 02:58 | Bumber | Note Added: 0035543 | |
| 2016-07-02 03:10 | Bumber | Note Added: 0035544 | |
| 2016-07-03 15:11 | lethosor | Relationship added | duplicate of 0009741 |
| 2016-07-03 15:11 | lethosor | Status | new => resolved |
| 2016-07-03 15:11 | lethosor | Resolution | open => duplicate |
| 2016-07-03 15:11 | lethosor | Assigned To | => lethosor |
