Print

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

[zuglar]

Hi all,

I'm a new player here, but I've already spent more time than I care to admit, and got a fortress up to nearly 60 dwarfs so far. One thing I've noticed in the various fun times that got me to this point is that inventory management is a big problem, with consumables being especially annoying to manage. For example, it's trivially easy to run out of booze without noticing, or to get an explosion of food by giving my grand master farmer two fertilized fields and some plump helmet spawn. Usually the latter, since that's better than running out. Repeat and auto tasks help avoid shortages, but do nothing to prevent explosions.

So, here's the idea (inspired by real life inventory control practices): have the ability to set "stock alerts" with the manager. It's nice to say "make 10 lavish meals", and that should stay, but it would be awesome to also say "make sure we always have at least 100 lavish meals in stock." Basically, any job that you can currently schedule with the manager would have the option to set a stock alert level as well; whenever inventory drops below the target level, the stock alert fires and the manager queues up appropriate jobs in response. Naturally, it will still be up to the user to make sure all dependencies are available, place workshops and link stockpiles, enable appropriate labours, etc.

Example:

Spoiler (click to show/hide)

Consider a food supply chain based on a single 1x7 field that grows Sweet pods (spring), cave wheat (summer), quarry bushes (fall) and plump helmets (winter, two harvests). Ideally, an automated food production supply chain could be set up using the following targets:

• Ash: 4
• Potash: 4
• Sweet pods: 50
• Cave wheat: 50
• Quarry bushes: 50
• Plump helmets: 100
• Dwarven sugar: 20
• Dwarven flour: 20
• Quarry bush leaves: 20
• Dwarven wine: 1000
• Dwarven rum: 500
• Dwarven beer: 500
• Lavish meals: 1000

Over time (probably 2-3 years), the system would stabilize at the targeted stock levels. Then, as dwarves eat through the lavish meals, a stock alert will eventually kick the cook to make more. He'll probably produce a stack of 40 in one go, removing the alert and letting him get back to soaking up mist at the waterfall in the dining hall. However, he used a bunch of dwarven flour, quarry bush leaves, and wine, causing alerts for the miller, plant processor, and brewer. They, in turn, will get the farmer's attention next time the appropriate planting seasons arrive. When the farmer fertilizes, potash and ash will be pulled in as well.

The net effect is that the user manage resource production in terms of where they want to end up, rather than queuing myriad jobs to get there (isn't that what managers are for?). Great for rapidly fluctuating consumables, but also for infrequent ones: traded away a couple bags of dwarven flour to the elves? Stock alerts will make sure those bags get replaced with no fuss. Since actual tasks go through the job manager, missing dependencies will still cause cancelation spam, and missing labors/workshops will still lead to silent work stoppages.

Caveat emptor: long lead times can be fun! If the brewer decides to attend a party and leaves a big stack of plump helmets lying around during winter planting, the farmer might decide not to plant more -- even though the current stocks could be depleted within a few days once the brewer gets back on the job. Result: a whole year with no plump helmets if you set things up badly and/or are not paying attention.

Other considerations:

Spoiler (click to show/hide)

• This feature would fit well with the bookkeeper's work. It doesn't have to be updated every tick, rather, it would be part of the "update stockpile records" task; a stock alert could even be missed due to the bookkeeper rounding less-accurate quantities upward ("We still have at least 10? gypsum plaster sacks in the hospital, nothing to worry about").
  
• Work triggered by stock alerts goes into the manager's regular job queue. Besides fitting nicely with existing mechanisms, it gives a way to put high-priority tasks ahead of autogenerated ones, if need be; if it so happens that the usuer already queued up 10 bags, that would count towards the total stock levels and potentially cancel/avoid an alert as well.
• Each season, farmers would need to make a binary decision to plant or not -- based on presences/absence of a stock alert -- because they don't know the size of their harvest. This is both reasonable and compatible with current behavior. Farming in general is going to be a special case, tho, because the decision to plant fields is not currently accessible via the job manager. Note that you'd still need to set up the fields for various crops and seasons.
• Inconsistencies between job name/input/output. There are several places where a single job can take different inputs and produce different outputs depending on those inputs. This will not play well with stock alerts, but it also (IMHO) indicates UI bugs that need fixing. More details below.
• For clothing, it would be really nice if stock targets could exclude items that are particularly badly worn. Then, when Urist McRattySocks grabs a new pair, a work order would be generated to produce replacements even though the ratty pair is still sitting around somewhere. Material types factor in here, too: maybe we want that sheep's wool sock to be replaced with a pig tail fiber sock because we have no wool industry, let alone sheep. But that can be worked around because the replacement (which is pig tail fiber) will eventually wear out as well, leading to a stock alert down the road (again, long lead times, so set targets carefully).

Interactions with (some) existing job specifications:

Spoiler (click to show/hide)

• Smelting. This is perfectly reasonable already. You specify a specific [combination of] input material, and the output is well-known. It's also really nice how the smelter shows clearly which jobs don't have the necessary raw materials available.
• Forging. This is also quite reasonable. Specify the object category, choose a valid metal for that category, then choose the object to forge.
• Stonework. This is currently ambigious, but that's mostly good, with so many types of non-economic stone lying around (each differing only in color, not value or functionality); it's reasonable to make somebody work harder if they really want to build everything from microcline. The one exception would be economic stones like marble and dolomite, which are also useful for building. Perhaps it would be helpful to differentiate "build rock throne" from "build dolomite throne" in the manager's job queue (the very nice search filters make it easy to ignore the extra options). I'm not too worried about making it easy to work with ore, because that's a special case that can reasonably demand extra work from the user.
• Woodwork. Same arguments as for non-economic stonework.
• Processing/milling plants. This is currently divided up by the type of container the result goes in. A menu like the smelter's would be vastly better: specify the input to use, and the output (with any container needs) is fixed. There aren't *that* many plants out there...
• Brewing. If you're trying to get rich selling dwarven sugar, it's really annoying to see your sweet pods turning into rum just because the plump helmets ran out. Stockpile dependencies can fix some of this (with a lot of work), but it would be vastly simpler to just specify the type of booze to make (smelter-style, there are far more ore types than brewable plants). Doing so would also make it much easier to maintain variety in your booze stockpile and to implement stock alerts on different booze types.
• Cooking. Thousands (millions?) of combinations of inputs producing thousands of possible meal types, with the further complication of easy/fine/lavish. Dwarfs will eat whatever's nearest, so it doesn't usually matter. For usable stock alerts, the Urist McBookkeeper would need to know that "prepare lavish meal" results in "roasts", etc. Probably not too hard to implement, if it's not already there. Booze cooking and high-value meal trading would be left to the determined micromanager.

[10ebbor10]

I do believe there's an utility for it. (Can't remember the name though). That's not a reason to exclude this suggestion from the game, but at least there's a temporary fix.

[zuglar]

Do you mean Dwarf Foreman? The links to recent versions in the forum seem to be dead (or else the web site is down), so I can't test it. It looks pretty invasive, though (killing jobs in the queue on attach, must remember to detach before save, etc.) and automates more than I would want (auto tree cutting, auto melting, etc.). Still, it might do the trick as an interim solution.

[Dwarfu]

The basic idea of your suggestion is already queued up as a Dev Goal:

Standing Production Orders

    Production triggers for new work orders
    Being able to link work orders and triggers to buildings

[weenog]

I like (optional) automation, so I like this.  I think an option to set required maximums on items (and maybe even creatures), and an action for dealing with the excess, would also be good.  If, for example, large silver daggers exceed 0, melt a large silver dagger and check again.  If there are multiple adult male specimens of whatever your chosen meat/leather/bone/etc animal is, butcher the population back down to 1.  That kind of thing.