Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ravaught]

There would have to be some kind of sanity check on this to avoid issues. For example, what happens when the manager comes to a stockpile, queues the max number of orders, leaves, comes back, and queues the max number of orders again. It would need to be able to check which orders had already been queued to make sure that it wasn't automatically queuing more than the stockpile could hold because of the latency between production and order creation. There is also the issue of stockpiles being emptied during this process, which creates the exact opposite effect of the stockpile never getting to its full state. This problem would be exacerbated to either extreme during the early and late stages of the game when you have less/more stockpiles for your manager to handle.

[breadman]

I like this idea, but options related to manager automation should be controlled per stockpile, default=off.  Sometimes extra stockpile space is a really good idea, and no one wants their general furniture stockpile filled up with wooden doors or whatever, or all their wood turned to ash.

Absolutely, it should default to off.  Fortunately, that's also the simplest way to initialize it.

Since people would be using the manager more, there should be an option in the workshop profile to disable certain jobs at workshop to be automatically queued (this would be time consuming to designate for forges that have many permutations of possible jobs)

Yes, as discussed above, that would be very nice.  Granted, I feel that the two features, though synergistic, are in some sense orthogonal.  That is, either would be beneficial, but the combination would be even better.

Good note on the forges.  Perhaps they could work well with something like the stockpile interface, where columns correspond to menus of the "add order" screen.  On the other hand, I wouldn't mind a messy, time-consuming interface for what is essentially a one-time event that would save me loads of time in the future, so even a single long list would be fine.  Something like the way we disable cooking or brewing certain ingredients, perhaps.

However, it would be silly to do this change before the "take from" option is fixed.  We really need to be able to have one stockpile take from many, and many stockpiles take from one.

This is a third feature that I consider orthogonal.  I can also see why the limitation exists; it's essentially a single field on the stockpile being taken from.  (It wouldn't feel so bad if the interface were structured that way.)  Sometime, I'll have to test my theory that a long chain of specialty stockpiles could work, but it really would be more convenient to have a single mass storage that all of the smaller ones take from.

I disagree on priority, however.  Auto-queuing orders would make my life even easier than many-to-many "take from" designations.

Also introducing "take from" options for workshops, and allowing/disallowing them to use non-stockpiled goods or allowing/disallowing use of goods in other stockpiles.... Brilliant.

Interesting.  I would consider this a fourth orthogonal feature.  Even less important to me, since it can be replicated by burrows, with a little extra micro-management.

There would have to be some kind of sanity check on this to avoid issues. For example, what happens when the manager comes to a stockpile, queues the max number of orders, leaves, comes back, and queues the max number of orders again. It would need to be able to check which orders had already been queued to make sure that it wasn't automatically queuing more than the stockpile could hold because of the latency between production and order creation.

That's what the bit about "less the total of that order already in the queue" is supposed to mitigate.  If your bed stockpile has seven empty slots, and there's already one job in the queue for two beds and another for three, then the bookkeeper should only queue up another two.  Yes, it's a bit of burden for the programmer, but it's an important safety check.  Unfortunately, it's still possible to overshoot, during the latency between production and hauling to the stockpile, but that's a much smaller window for the bookkeeper to hit, and shouldn't be a problem for items that get used regularly enough.

There is also the issue of stockpiles being emptied during this process, which creates the exact opposite effect of the stockpile never getting to its full state. This problem would be exacerbated to either extreme during the early and late stages of the game when you have less/more stockpiles for your manager to handle.

In that case, you'll end up with a steady stream of job requests in the queue.  The good news is that it's exactly what the auto-queue system is best at; ideally, your stockpile never quite runs dry, and your dwarves produce new items just as fast as they get used.

If, on the other hand, the stockpile is frequently empty, that means you need more workshops, workers, and/or raw materials for the job.  The last one will be obvious from all the job cancellation spam.

[slothen]

Describing all my ideas as orthogonal

thispleasestwilight.jpg

Also introducing "take from" options for workshops, and allowing/disallowing them to use non-stockpiled goods or allowing/disallowing use of goods in other stockpiles.... Brilliant.

Interesting.  I would consider this a fourth orthogonal feature.  Even less important to me, since it can be replicated by burrows, with a little extra micro-management.

a LOT of extra management, since while that stockpile is in use a dwarf has to be assigned to a burrow, in which case only that dwarf can be trusted to use that workshop.  Not as practical when you want 15 masons using 8 workshops (I work around this by making stockpiles of specific stones near the mason's workshops, and just accept that I won't get exactly what I want 100% of the time.  The real culprit is jewelery and other decorating jobs.  Besides, players have been asking for this functionality for years.

[breadman]

To summarize the progress made within the last two years:

"Take from" option for stockpiles

  Implemented; thanks, Toady!

"Take from" option for workshops

  Implemented as "give to" from stockpiles.  It would be nice to see the linked stockpiles from the workshop screen, though.

Bookkeeper enqueues manager orders selected through the stockpile interface

  A proof of concept is available as a DFHack plugin. So far it works well for me, though it would be nice if the bookkeeper worked more often.  Has anyone else tried it?



Yet to be implemented:

Template a stockpile to take only items like one selected

  This idea got lost in the shuffle, probably because it's only tangentially related to everything else in the thread.  It reminds me of the idea in several other threads to have customizable stockpile profiles, analagous to the customizable embark profiles, replacing the current menu.

Designate a specific workshop for stockpile/manager orders

  Alternatively: Disallow certain task types or labor types from being enqueued to certain workshops.

"Wait" flag for workshop jobs

  This related idea, from the Workshop toggle Wait thread, adds another flag to let a job move to the end of the queue if materials are unavailable, instead of being cancelled. Ideally, the "job cancelled" (deferred?) notifications would be reduced for such jobs, though not entirely suppressed.

[breadman]

A post by sweitx inspired an alternative proposal:  Now that we have workshop links, we could potentially let stockpiles suspend and resume jobs on their linked workshops.  One flag either per stockpile, or even better, per link.  When a workshop has a flagged link to take from an empty stockpile, its jobs are automatically suspended.  When its flagged output links are all full, its jobs are automatically suspended.  Otherwise, its suspended jobs are resumed.

Granted, this idea isn't quite as powerful as having the bookkeeper enqueue manager orders, and can lead to annoyance if manual suspensions are overridden, but it could be simpler to understand and/or implement.  Then agan, suspending and resuming only relevant jobs would be quite tricky.

However, this idea depends on the "Wait" flag for workshop jobs, to prevent the user from having to add the same jobs to each workshop every time they get canceled instead of suspended.

For that matter, even using manager orders would benefit from the Wait flag, since it can effectively replace the option of enqueuing a certain order for each item in the stockpile, and could reduce the amount of notification spam caused by orders for each empty stockpile space when materials aren't yet available.  Therefore, I recommend that the Wait flag be implemented first.  It might even be just barely enough to maintain the booze supply.

[NW_Kohaku]

Honestly, I'm not sure why this was purged from the Eternal Voting, since only a small portion of it was completed. 

I still don't see what would be hard about adding a "make to #" command, and possibly linking it to the manager and bookkeeper's functions. 

I mean, I played Gnomoria in the hiatus while I was away, and it just works like a charm.  They even include an automatic enqueueing of dependent tasks, (so that making an iron axe will trigger the making of an axe head if you are out, and then a smelting of iron ore if you have no iron,) and have the ability to designate specific materials you want to make any given item out of from a drop-down menu.  Automatic enqueueing is togglable on a per-workshop basis.  When there are insufficient materials, they even just plain suspend until materials come in. 

All of these dependencies upon stockpiles are micromanagement-heavy bass-ackwards ways of accomplishing a very simple task with needless complication and only serve to make the interface eat even more babies. 

Gnomoria is a game that, in general, is a pale wannabe of Dwarf Fortress, but by God, they get this part right, and it's wonderful.  Notice this, Toady!