Quick question or 2 about autolabor/labormanager

[MechanosG]

Heya. So, I'm out of the loop.. haven't visited the Discord or anything, so I apologize if I make any wrong assumptions ahead of time.

I'm under the impression, based on some issue responses and some older discussions here, that the autolabor related tools are being combined/refactored, along with some research into how current DF's labors are assigned. I'm completely new to dfhack, and have been really enjoying learning how to use a lot of these "auto" themed tools. I've constructed myself a massive onMapLoad script from scratch, and it's working great.

So to my questions. I noticed labormanager's source code still exists on github, but isn't in the latest dfhack builds (I made a big script for labormanager only to find out it wasn't actually available in game - oops xD). Is it currently incompatible? And what's the chances of a patched version (if needed) of labormanager being released before the big refactor (if that is indeed a thing)? No worries if that won't be happening. I'm just personally interested in trying it's priority based system and comparing it to the current autolabor.

And lastly, if I'm not completely off base.. how goes the refactor? Feel free to ignore me if this feels like prying or anything. Simply curious as a fan of the tools, and no rushing/prying intended. Thank all of you guys for DFHack and it's goodies.

[myk002]

ab9rf is the authority here, but let me describe the situation as I understand it.

The plan is to combine labormanager into autolabor, and cover its functionality with autolabor options. There appear to be significant bugs in vanilla DF's labor assignment algorithm, which is putting a damper on autolabor development. We don't want to fine tune autolabor to a buggy base, especially if those bugs are reasonably likely to be fixed soon(tm)

If I may ask, what did you put in your onMapLoad.init file? Eventually, I'd like to offer configuration "presets" in gui/control-panel, and I'd like to know how people are deviating from the current defaults.

[ab9rf]

This is pretty much spot on.

The idea I have had brewing for about the past year and a half now has been to combine autolabor, labormanager, and autohauler into a single (modal) tool. The v50 update also made significant changes to the manner in which units are assigned to tasks, including introducing several bugs.

labormanager is finely tuned to mesh with a number of the core game mechanics that have significantly changed, which means it would likely work like complete bollocks; on top of that, it does not compile as of yet, and so it has not been reenabled.

autolabor is less sensitive to these details (its algorithm is much simpler and less sensitive to picky details in the game's engine) and so it was possible to reenable it with relatively little effort, although there are still adjustments that need to be made and which will be addressed in the near future in order to at least make autolabor "not worse" than the game's default labor management option.

autohauler is effectively obsolete; that tool required the player to manually manage the labors of skilled laborers and there simply isn't any means available for players to do so.

I do intend to return to labormanager in some way in the future, but I don't think it's worthwhile to try to adapt a finely-tuned algorithm to the peculiarities of an underlying algorithm that has serious bugs in it and is thus likely to be changed, possibly radically, in the near future. My time, in this area at least, right now is being spent trying to understand how, at a fine-grained level, the new labor assignment algorithms in DF v50 work. Once that knowledge has been adequately acquired, only then will it be possible for me to contemplate revising labormanager to work with the new version.

So, TL;DR: autolabor works to some degree now, and we'll try to make incremental improvements going forward; labormanager will return at some time in the future, but don't hold your breath; and autohauler is pining for the algorithmic fjords.

[MechanosG]

@myk002 Regarding the onMapLoad.init, sure. It's fairly large, so I'll kinda summarize. First I run
'on-new-fortress orders clear; orders import mechsorders'
to load a massive list of work orders on new forts. Then I run a couple repeats, one for sorting orders, one for auto unforbidding, both set for once a day (I might change unforbidding so it happens less often, to reduce the chance of mid-fight hauling attempts, although it hasn't been a problem yet). Then I enable nestboxes, enable autofarm, and customize autofarm to farm 400 plump helmets, 50 pig tails, and 20 of everything else. Enable auto unsuspend. Enable autobutcher then customize it to mostly ignore dogs/cats, then default to 8 females, 2 males, 50 kids m/f, for everything else. I enable prioritize with the defaults, then I enable autolabor and have customized every job. Some of these I likely don't need to run every single map load, but I kinda like having it reset and re-initialize, "just in case". Also lets me apply any changes by just saving the init then reloading my save.

Currently with autolabor, I have disabled a handful of jobs that I want to make sure are done only by the best skilled dwarves. Then I created an optimization plan in dwarf therapist (just figured out how to do this today) so I can 1 click assign the jobs autolabor isn't managing, each time my population changes. I haven't tested this extensively yet, to see what autolabor does to the therapist assigned dwarves

@ab9rf Ah, I see. Alright. Thanks for the info. :)

[myk002]

This is great. Thanks! It gives me ideas for extending the standard tooling.

Which orders do you add beyond what is available in the orders library? Or is it that you have the thresholds configured differently?

It sounds like unforbid could use a --but-not-if-theres-a-siege parameter. Then maybe it can be offered as a maintenance task in the control panel so others can have this as well. (orders-sort, incidentally, is already there, so you don't technically need to write your own)

Eventually, I'd like to gather popular custom configs like this and offer them as presets that you can select and modify in the control panel (in-game)

Thanks!

[MechanosG]

No worries, happy to help.

I've never actually looked at the pre-made orders library. To kinda explain why, I was playing DF off and on (mostly blind) since day 1 steam release, with the intention of experiencing as much as I could from that blind standpoint. Never really gave DFHack much thought, as I struggled to get into classic DF, so I was just unaware of what DFHack was about or could do. But as I got better at DF, and eventually started having to check the internet for hard to self-learn info (still avoiding actual guides though), I found myself often starting new forts to try new strategies (rather then waiting for an actual collapse). Despite making myself a personal guide with an attempt at a universal work order list, it became a huge pain to put everything back in every restart. I started looking for a way to export and import work orders, jobs, settings, etc. Found some blurbs about DFHack being able to do work orders, and as coincidence had it, DFHack had just became publicly available for 50.0+ testing for about a week. So I grabbed it, jumped on the wiki, read how to get started, and mostly followed the in-game GUI's help text to export my orders (and use onMapLoad to load them). The real use case examples in the in-game help text/console output, are really useful btw!

So because of this, I actually have no idea how much my orders differentiate from the library, as I'm 100% using my own. But what I can tell you, is my work order export is designed to be universal for any fort pretty much, with some personal preferences of making things out of stone (even if wood/metal would be worth more, I like to limit my reliance on wood, and save as much metal as I can for armor, weapons, etc). Then I just supplement manual orders for special purpose stuff. Many things, like coffers/cabinets/beds, it'll pre-make 10 of them, as my population tends to grow really quickly and I end up spending a lot of time spamming bedrooms. Other things like doors, it'll pre-make 10 as well. Things that are used less, like gravestones/stone coffins, it'll pre-make 5 of. Things like.. armor stands, it'll only pre-make 1. This trend continues with 1 to 10 counts for most frequent use things, including containers and medical supplies, with some exceptions. Every ore is set up to auto smelt if producible ingots are under 10, including ores with the 20% second ingot type, sorted to prioritize things that I use more, like iron/silver. That way if the fort needs silver, and all I have is tetrahedrite or galena, it'll look past the copper/lead count and spam smelt those for the silver. After extensive testing of leather/bone/shell armor, I find myself not bothering with them now, and only have armor work orders for iron, and keep 10 of each on hand. Helm, chainmail, chestplate, greaves, gauntlets, high boots (if available, low boots if not). New recruits or archers, I'll have them not equip the chestplate/greaves. Otherwise, full set. I haven't played a game long enough to produce my own steel yet (or the 2 other rare metals), so no work orders related to them. Wood shields, silver warhammers, copper warhammer if no silver, iron spears for traps. Might be a waste of iron, but I believe I keep 3 iron axes/picks on hand. If I find in a particular playthrough I want to focus on a certain weapon type, I'll add a workorder for an iron variant of just that weapon, but won't add that to the main export. I tested one game attempting all out crossbows with iron bolts... and I find I really don't like crossbows. No stopping power, and goblins just shoot back anyway. So now, I only produce 1 wood crossbow and some wood bolts, very slowly, mostly just for hunters (if any) to plink with.

I do have an oddball set of orders related to plump helmets and cooking however, for a strategy I'm trying. Instead of limiting what can be cooked, to prevent running out of helmet spawn, I instead leave all cooking recipes, turn off auto-cooking, and use workorders to only cook when plump helmet counts are over X amount. I forget the exact numbers off hand, but something like.. basic meals if plump helmet count is over 100 to 150, fine if 151 to 200, fancy (I forget the name) when over 200. Or something. The idea being, I'm after an automated hands off approach, and will just let the cooks use whatever ingredients they want when I'm certain they won't stall the plump helmet production. As plump helmet count increases and they start using more ingredients, they naturally dip into other ingredients and make use of things. But when plump helmet count (and likely their spawn) is still low, no meals are made to help get spawn count up. This usually ends up my earliest and highest profit trade item, along with random morale contributions. I have similar work orders for brewing as well, where if plump spawn count is under 10 but plump helmets are available, start brewing dwarven wine like crazy to get spawn count up. Normal brewing of dwarven wine up to X amount otherwise. Then brew from fruit lower priority when we have the ingredients and drink count is between Y and Z. So far, this strat helps with getting plump helmet counts up where I want early game, slows down the spawn from hitting huge numbers, then just lets them cook whatever when it's safe.

One thing of note - my workorders do assume you have big stockpiles, or even some quantum stockpiles. I don't know if the library workorders take that into account or not. I imagine workorders could be set to craft in smaller amounts spread out, to reduce stockpile stalling by making sure smaller amounts of more things are available. But my fort definitely stalls if I forget to make enough stockpile room, particularly from the dwarven wine rush for plump helmet spawn. Also my workorders assume plentiful resources. If you have no iron, then lots of it isn't going to work.

It was looking into the orders importing/exporting, that motivated me to try DFHack actually. I happen to enjoy games with a little bit (or a lot) of scripting/automation involved, and it was kinda fun setting up the onMapLoad.init. So I started looking into what else DFHack could do, and it just snowballed into reading random tool descriptions and going "Oh, that sounds useful, lets try that!" It's honestly became a new part of the gameplay for me, beyond just automating a ton of the micromanagement. But the downside of this, is.. I don't actually have any guides or videos telling me to use X thing.. I have to just get lucky and stumble upon the tool.

I am actually using orders-sort, on one of the 2 repeats. Pretty useful for bumping manual workorders to the top of my giant workorder list. I might be using it exactly how the in-game text example shows it. Edit: Nvm, I changed the repeat identifier to sort_orders instead of orders-sort, but close enough.

repeat -name sort_orders -time 1 -timeUnits days -command [ orders sort ]

I don't know how difficult/possible this would be.. but is there some way a tool can check if "any" non-training combat is happening? A parameter for unforbid to check if there's a siege would be useful. But I'm not certain what all counts as a siege? For example, I tend to get hit by cyclops and giants more than goblin/faction sieges, or even random spies in steel gear that decide to go on a rampage after learning about my artifacts. In those situations, I've love to be able to temporarily stop unforbidding as well. But from a programming standpoint, I would completely understand if there aren't any easy "events" to hook into, to check for that.

I hope this answers some questions, and I hope I didn't make this too long.