needs-based autolabor

[wookietreiber]

Example Use Case

I want to disable/enable crafting labors based on the Craft Object need, i.e. enable crafting for unfocused after being unable to practice a craft, including the worse variants, and disable crafting for all who are not distracted, including the better variants. I don't care about the quality, just to meet the needs so they stay focussed.

The way I've been doing this (manually) with Dwarf Therapist is:

1. set up a custom grid view (I call it Urist McLabors :joy:)
2. add a column with the Craft Object need to the custom grid view
3. add a Craft super labor with the crafting labors for which you don't care about quality and for which you have enough/refilling stockpiles, e.g. Bone Carving because there's always stuff from butchering or Stonecrafting because I don't care about the quality of my rock pots
4. add a column with the Craft super labor to the custom grid view
5. (in game) set up recurring work orders to craft stuff, so there is always labor available, e.g. Make bone Crafts
6. regularly refresh Dwarf Therapist, sort by Craft Object need column, and manually enable the Craft super labor for those who are getting distracted, and disable for those who have the need fulfilled

Automation

As you can imagine, doing this needs-based autolabor ensures a higher level of met needs and a higher level of focus. But, doing this manually, still sucks a bit because I frequently have to switch over to the therapist, refresh and click the cells.

I would like to have/write a tool that automates this workflow, i.e.:

1. runs every n ticks
2. check Craft Object need
3. if need exceeds threshold, then enable labors [a,b,c,...], else disable labors [a,b,c,...]

For dfhack.init, the syntax could be something like:

# automatically enable/disable crafting labors based on craft object need
# runs every 1200 ticks by default (one in-game day)
# syntax: autoneed craftobject labora,laborb,... [ticks]
autoneed craftobject bonecarving,stonecrafting

Contrib / PR

I'd like to contribute, but I have some questions on how to get started because I'm new to the dfhack code:

• Can this be done with a script, or does this need to be done with C++?
• Can you give me some pointers on specific doc / API pages I should look at?

[myk002]

This seems to me like it should be added functionality for autolabor and not a separate plugin/script. autolabor already has a heuristic for choosing which dwarves to assign to which labors, and this could just be part of the heuristic. Otherwise you run the risk of different tools competing to set labors for dwarves, and that can get frustrating for players.

@ab9rf is in the middle of refactoring/unifying autolabor/labormanager/autohauler, so I defer to her for advice on how this can be approached. In the meantime, you might want to read the existing autolabor (and friends) code in https://github.com/DFHack/dfhack/tree/develop/plugins/autolabor

you can also check out https://github.com/DFHack/scripts/blob/master/fillneeds.lua for some very simple code that iterates through a unit's needs

[ab9rf]

i am not planning on any updates to autolabor and its cousins with respect to pre-0.50 versions, at least not until after dfhack for 0.50 is working. 0.50 has a significantly revamped labor management system and while i believe both autolabor and labormanager will have a place in 0.50, they will need to be significantly adapted.

it has been my intention to add a feature such as you describe to labormanager for some time now, but i've deferred work to do so for over a year due to the announcement from Toady that he was reworking how labors work in the pending release. it seemed folly to put a ton of effort into improving a tool that would not longer be relevant. it currently appears, based on what we know of the 0.50 release, that tools like autolabor and labormanager still have a purpose (while the new labor system is different, it does not wholly solve the problems that autolabor and labormanager seek to solve) and thus it is likely that i will resume work on refactoring these tools after the initial effort to get dfhack working with 0.50 is complete.

i will caution you that while i cannot stop you from forking either autolabor or labormanager to add this functionality, it is unlikely that the dfhack team will agree to allow yet another fork of autolabor to be added to the official set of supported plugins. the code duplication and maintenance headache of having three forks of the same codebase present has been bothersome for some time, and it's definitely our intent to coalesce all three of these tools into a single unified tool. adding another fork would be a step backward in this regard and thus almost certainly will not happen.

tl;dr: this is a good idea but it'll have to wait for now