Print

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

[myk]

Ok, I removed the hunter ammo removal and the "Clearcutting area" burrow. I kept the precision setting for the bookkeeper since most people (I think) would forget to set it later (and it would be difficult to write a blueprint to set it later since the number of nobles may have changed and we wouldn't know the position of the bookkeeper).

Auto-adding to burrows is an intriguing thought. I worry that doing this in a #query blueprint is too fragile -- what if the player removes the Inside burrow or has them in a different order by the time the #query blueprint is run?

I think I can make it more robust, though. I could add a "burrows" command to quickfort. Just like the "orders" command generates orders from #build and #place blueprints, the "burrows" command could add the area affected by a #dig blueprint to a user-specified burrow. This would allow for a lot more dynamic error checking than a #query blueprint. I'll add this idea to my backlog.

re:odds and ends, you're right that having a few of everything on hand is useful.. I was objecting adding them to the "main" automation orders which focus on the basics, but now that we're splitting things into separate files, a set of orders that keeps a small stock (1 or 2) of items like pump parts, chairs, tables, mechanisms, alters, bookcases, statues, etc. could be nice. Then players could just buildingplan plan whatever they want and everything would just get built without any explicit orders at all. Only big projects (that's what I meant by "one-off") would require real orders. I wonder if players would appreciate options for which material these items are made out of -- one for rock and one for glass? Not everyone will be able to build glass, though.

I'll tweak the starting piles and test the hospital.

[ldog]

Maybe make glass it's own file.
So looking at the setup we could actually add entire uniforms from scratch?
Can we set other starting jobs too? (I honestly don't even remember how to do that without Dwarf Therapist it's been so long)
I love automating repetitive tasks.

Among other jobs, I am seeing the stone crafting really can wait until the 1st migrant wave (once the initial 2 nestboxes are made). Bee keeping too. I don't know about you but I'm not getting surface5 going before Late Summer/Early Autumn. LOL, and I just got sieged in Early Autumn for the first time in a while. Necro came raised 2 dead keas and left. Undead kea's truly terrifying. GG.

Oh, not only does the vet gain regular skills, they also don't gain any animal care (last game I was overrun with entire waves of migrants with animal care & plant gathering and no other skills) but they do need it enabled. Considering the state Toady left it in, I can accept the fact that is a kludgy hack to make it work at all. They do get a lot of area inaccessible cancelation spam for some reason I can't understand (other than when they can't walk).

So make mead is importing properly (my bad, was make honey), lye & soap jobs are still getting plain ITEMS. On the numbers by the way, I think 5-10 each plus what is in the hospital is plenty.
I guess I forgot to make the dfhack updates.

[myk]

I remember now why I configured the starting food pile to not use containers -- it eats all our barrels which we need to build the ashery and dyer's workshops. However, now that the farming level gets built so quickly, this point is moot since *those* stockpiles can eat the barrels anyway. I'll add documentation that extra barrels might need to be built (and/or combine-plants and combine-drinks need to be run) if stockpiles have claimed the ones you need.

We can absolutely create entire uniforms from scratch in a #query blueprint. Unlike the other modes, which modify game structures directly, #query blueprints are just glorified keystroke replayers. Anything you can do in the UI, you can do in a #query blueprint. Be aware, though, that the cursor behaves..oddly.. in the military menu and doesn't always end up where you expect. Scripting the military menu takes a lot of careful transcribing of direction key sequences.

Setting starting labors can be done the same way, just by scripting the key sequences. Creating custom professions in the DFHack manipulator UI (u-l), saving them with 'P', and later setting labors with 'p' might be easiest. I uploaded the set of DFHack manipulator professions I use to the dreamfort folder (copy into the "professions" subdir in the DF directory). I'll have to document them.

Dwarf Therapist can actually import these professions (as long as you have them assigned to some dwarf) so you can use the same profession presets in DFHack manipulator and DT.

The reaction condition support for the orders plugin is not merged yet, so the only way to solve the "plain items" problem on orders import is to locally pull the PR and build the code yourself. Once it's merged, it will be easy to get the updated code via DFHack's continuous integration builds (the "Build Artifacts" list).

[ldog]

Never really thought about that with the barrels (but after consolidating I have enough empties to last until pots get going), but the surface pile isn't going to be the culprit as you said, it's the farming level. Build orders queues the needed barrels though I guess they could still get taken.

So it's just replaying a macro? That's pretty flexible at least, even if it is a pain to setup. It still beats doing it every new game.

Y'know I know custom professions is a feature of Dwarf Therapist forever and yet I never think of using it.

I know, I had started to do that and then I got distracted and forgot about until the import failed again.

[myk]

I've been exploring how tweak do-job-now can improve the efficiency of the fort by boosting the priority of certain jobs, but it got tedious to always be boosting the same types of jobs. So I wrote a script to monitor job creation and automatically boost the priority. I'm still testing the implementation, but here's the doc I wrote for it:

Code: [Select]

prioritize
==========

The prioritize script sets the ``do_now`` flag on all of the specified types of
jobs that are currently ready to be picked up by a dwarf. This will force them
to complete the jobs as soon as possible. This script can also continue to
monitor creation of new jobs and automatically boost the priority of newly
created jobs of specific types.

This is most useful for ensuring important (but low-priority -- according to DF)
tasks don't get indefinitely ignored in busy forts. The list of monitored job
types is cleared whenever you load a new map, so you can add a line like the one
below to your onMapLoad.init file to ensure important job types are always
completed promptly in your forts::

    prioritize -a StoreItemInVehicle PullLever DestroyBuilding RemoveConstruction

Also see the ``do-job-now`` `tweak` for adding a hotkey to the jobs screen that
can toggle the priority of specific individual jobs.

Usage::

    prioritize [<options>] [<job_type> ...]

Examples:

``prioritize``
    Prints out which job types are being automatically prioritized and how many
    jobs of each type we have modified since we started watching them.

``prioritize ConstructBuilding DestroyBuilding``
    Prioritizes all current building construction and destruction jobs.

``prioritize -a StoreItemInVehicle``
    Prioritizes all current and future vehicle loading jobs.

``prioritize -d StoreItemInVehicle``
    Stops automatically prioritizing new vehicle loading jobs.

Options:

:``-a``, ``--add``:
    Prioritize all current and future new jobs of the specified job types.
:``-d``, ``--delete``:
    Stop automatically prioritizing new jobs of the specified job types.
:``-h``, ``--help``:
    Show help text.
:``-j``, ``--jobs``:
    Print out how many jobs of each type there are. This is useful for
    discovering the types of the jobs which you can prioritize right now. If any
    job types are specified, only returns the current count for those types.
:``-q``, ``--quiet``:
    Suppress informational output (error messages are still printed).
:``-r``, ``--registry``:
    Print out the full list of valid job types.

The example I put in the docs is what I intend to add to dreamfort's onMapLoad.init:

Code: [Select]

prioritize -a StoreItemInVehicle PullLever DestroyBuilding RemoveConstruction
with callouts in the checklist for when to run one-off commands like

Code: [Select]

prioritize ConstructBuilding
like when the industry level is first laid out.

[myk]

I've been testing the prioritize script, and I'm really pleased with how it increases responsiveness and efficiency in a fort. I think I'll add ConstructBuilding to the recommended watch list as well since construction is such a critical part of getting a fort up and running.

I wish I had this script years ago! Such a short simple script, but it makes so much of a difference!

[myk]

Ok, I'm rescinding my recommendation for ConstructBuildilng being automatically prioritized. It causes too much strain on the dwarves when building a lot of constructions (such as when dreamfort builds the walls and roof of the surface fort). It is still sometimes useful to prioritize the ConstructBuilding jobs that are ready *right now* with just prioritize ConstructBuilding (i.e. without the -a option), but I've come to the conclusion that it's not good to have it on all the time.

My current recommended addition to onMapLoad.init:

Code: [Select]

prioritize -a StoreItemInVehicle PullLever DestroyBuilding RemoveConstruction RecoverWounded FillPond DumpItem SlaughterAnimal

In other words, these are the tasks that (seem to me to) benefit most from being completed ASAP. Did I miss anything that should be here by default? Players can always add (and/or remove) other types during gameplay at any time too.

I'm gonna say it again: this script has made a world of difference in the responsiveness of my forts. When I buy a shipment of animals from traders, it no longer takes years to slaughter them all. When I dump the equipment of a caged invading army, it now happens quickly and efficiently. I no longer have to waste dwarves by focusing them on just the "Pull Levers" labor. I don't have to suspend all my masonry jobs so my masons finally have time to build bridges and wells.

I know not everyone plays the way I do or has the problems I have, but I really hope this script can bring people as much joy as it brings me : ) If you'd like to try it before it gets merged, you can download the script here.

[ldog]

Ok, I'm rescinding my recommendation for ConstructBuildilng being automatically prioritized. It causes too much strain on the dwarves when building a lot of constructions (such as when dreamfort builds the walls and roof of the surface fort). It is still sometimes useful to prioritize the ConstructBuilding jobs that are ready *right now* with just prioritize ConstructBuilding (i.e. without the -a option), but I've come to the conclusion that it's not good to have it on all the time.

My current recommended addition to onMapLoad.init:

Code: [Select]

prioritize -a StoreItemInVehicle PullLever DestroyBuilding RemoveConstruction RecoverWounded FillPond DumpItem SlaughterAnimal

In other words, these are the tasks that (seem to me to) benefit most from being completed ASAP. Did I miss anything that should be here by default? Players can always add (and/or remove) other types during gameplay at any time too.

I'm gonna say it again: this script has made a world of difference in the responsiveness of my forts. When I buy a shipment of animals from traders, it no longer takes years to slaughter them all. When I dump the equipment of a caged invading army, it now happens quickly and efficiently. I no longer have to waste dwarves by focusing them on just the "Pull Levers" labor. I don't have to suspend all my masonry jobs so my masons finally have time to build bridges and wells.

I know not everyone plays the way I do or has the problems I have, but I really hope this script can bring people as much joy as it brings me : ) If you'd like to try it before it gets merged, you can download the script here.

Here I thought butchering was fairly high priority. What about tan hide? Possibly haul food as well, although that might be a bit much.

[myk]

Unfortunately, job types don't always map cleanly to labors. I'll have to track down what job type "Tan a hide" is. It might be "CustomReaction", which isn't helpful. Haul food is of type "StoreItemInStockpile" (or "StoreItemInBarrel"), which is far too broad to automatically prioritize.

I probably could figure out what labors are involved, though. Prioritizing hide tanning and food hauling does sound like a good idea.

[ldog]

Unfortunately, job types don't always map cleanly to labors. I'll have to track down what job type "Tan a hide" is. It might be "CustomReaction", which isn't helpful. Haul food is of type "StoreItemInStockpile" (or "StoreItemInBarrel"), which is far too broad to automatically prioritize.

I probably could figure out what labors are involved, though. Prioritizing hide tanning and food hauling does sound like a good idea.

Uhhh, yeah I think it is custom reaction.
Therapist might shed some light, since it splits the hauling labors?

[myk]

I spent some time investigating, but mapping job types back to labors looks very hard to do. I absolutely would like to prioritize time-sensitive tasks like tanning and food hauling, but I'm going to have to look into it more later.

I also looked into the lye and soap orders. It looks like pots can store anywhere from 1 to 7 units of lye, but always count as one "lye-containing item" (whereas buckets were deterministically one-to-one). If lye is in pots, the whole pot gets dragged to the workshop for use in making soap, so we have to be a little loose with our limits to compensate. Using pots is more space-efficient, though, and gives us room to show an "out of stock" meter for wood, so I'm fine with the change overall. I halved the size of the "miscliquids" stockpile, enabled pots. and adjusted the limits of the "make lye" and "make soap" orders so they make sense regardless of whether lye is stored in buckets or pots -- the automation orders are useful for all fort designs, not just Dreamfort. I'm targeting three lye-containing pots instead of just one to reduce the chances of cancellation spam as the pots are hauled to and from the stockpiles.

I've been doing a lot of testing, and I think Dreamfort is just about ready for the next release. Big thanks to ldog here on the forums for their help in driving Dreamfort to greater heights! Here are the changes:

• Improvements to documentation:
  • Editing pass for clarity and correctness
  • Added info on common tasks that Dreamfort does not do (like manufacturing trade goods)
  • Added hyperlinks to screenshots and related info
  • Removed complicated instructions and warnings that are now handled automatically by the prioritize script
  • Added a reminder to have fun : ) (it's not all about spreadsheets and optimization!)
• Improvements to automation orders:
  • Replaced the error-prone "do X when Y finishes" orders with proper item count-based conditions (depends on new code in the orders plugin)
  • Added glassmaking products
  • Added weapon/armor orders that create the best equipment possible based on the metals you have on hand
  • Orders are split into groups based on when you should import them so you gain the benefits incrementally without ever overloading your fort with automation tasks
• Improvements to onMapLoad.init -- I uploaded this file separately from the existing onMapLoad.init so users of the current release don't get error messages about missing scripts
  • Added configuration for the new prioritize script
  • Refined autobutcher settings
  • Banned booze from being cooked by default
  • Enabled and configured seedwatch for seed stock management
• new /setup blueprint that sets basic settings (players can change preferences and make further customizations after running this blueprint):
  
  • The manager, chief medical dwarf, broker, and bookkeeper noble roles are assigned to the first suggested dwarf. This is likely to be the expedition leader, but the game could suggest others if they have relevant skills.
  • Bookkeeping is set to the highest precision
  • Standing orders are set to:
    • only farmers harvest
    • gather refuse from outside (incl. vermin)
    • no autoloom (we'll be managing cloth production with automated orders)
  • A burrow named "Inside" is created (it's up to the player to define the area, though). An alert named "Siege" is also created and associated with the "Inside" burrow, intended for use in getting your civilians to safety during sieges.
  • Military uniforms get the following modifications:
    • all default uniforms set to replace clothing
    • all default uniforms get a leather cloak
    • the "Metal armor" uniform, the "metal armor" item is removed and replaced by "metal breastplate" and "metal mail shirt"
    • in the "Metal armor" uniform, the "metal legwear" item is removed and replaced by "metal greaves"
  • Hotkeys are created for the 8 most interesting levels. Only the names are set -- it's up to the player to adjust them to actual locations in the (H) menu since the blueprint can't know where the levels will eventually be built.
• Updated embark suggestions and example embark profile based on playtesting results. In particular, Dreamfort now recommends raising geese for bones and leather instead of turkeys.
• Added a list of useful professions (collections of associated labors) to assign to your dwarves. Uploaded corresponding files that can be used with DFHack manipulator to the shared Dreamfort directory.
• Improvements to the checklist -- I kept this as a separate sheet for now so I don't confuse players trying to use the existing checklist with the currently released version of Dreamfort and DFHack. I'll overwrite the old checklist with this new one once we get closer to the next DFHack release:
  
  • Added links to onMapLoad.init and the new automation JSON files
  • Added line for the new /setup blueprint
  • Removed guidance that players should run the dig blueprints separately, but could run the (hidden) /dig_all_underground blueprint if conditions allow. Added guidance that players should run the (renamed and unhidden) /dig_all blueprint unless conditions disallow, with instructions on how to run the individual blueprints if necessary
  • added in calls to prioritize ConstructBuilding where especially useful
  • Added a "Plumbing" section where it would be good for the player to think about filling wells and finding/pumping magma
  • Added orders import lines where appropriate for importing the newly split automation orders
  • Moved building of the suites level earlier in the sequence, based on results of playtesting
• Surface level improvements:
  • The central stairwell has been changed from priority 7 to priority 6 so that miners who have hauling labors enabled will choose to dig rather than haul. Priority 6 is still low enough so that the miners will finish digging the current level before digging the stairs down to the next level.
  • Trees are now cut down at priority 1 so that woodcutters will voluntarily choose to woodcut without manual labor twiddling
  • starting cloth stockpile now also accepts refuse
  • starting food stockpile now allows all types of food/booze and also allows containers (barrels/pots)
  • on the roof, build order for the floor tiles around the access hatch is more carefully managed so that the floor tile to the north of the access hatch isn't built first, which would cause it to immediately collapse as it would not be properly supported
• Farming level improvements:
  • Stockpiles now take from starting stockpiles so even if the player forgets to remove the starting stockpiles, items will still be appropriately moved down to farming
• Industry level improvements:
  • The "miscliquids" stockpile (i.e. lye and quicklime) is now halved in size but now accepts containers
  • Added wood stockpile to indicate whether the stock of wood is depleted
  • Moved meltables stockpiles to the left to allow more room for magma furnaces/forges
• Services level improvements:
  • Moved the hospital well earlier in the build sequence to allow it to be used ASAP
  • Enabled animal training for the hospital zone so the dwarfvet plugin can use it as a veterinary hospital
  • Created inactive pond zones over the cistern tiles to assist players who fill the wells via bucket brigade. The inactive zones won't interfere with other strategies for filling the wells.
  • Redrew the cistern dig map and reworked the priorities used to account for the reduced priority of the central stairs

Whew!

I'm still making a few more changes, especially around where the supporting files are stored. The enhancements to the orders plugin and the prioritize script are also not merged yet, so the new dreamfort version isn't quite ready for use. I'll update again once everything's ready.

[myk]

I finally realized that many of the Dreamfort checklist commands are very similar, differing only by the command (e.g. "run" vs. "orders") or the label (e.g. "quickfort orders library/dreamfort.csv -n /surface2" vs. "quickfort orders library/dreamfort.csv -n /surface3").

Now, any of these elements can be replaced with a comma-separated list, so you can run just one command instead of 2 or more. For example:

Code: [Select]

quickfort run,orders library/dreamfort.csv -n /suites2

quickfort orders library/dreamfort.csv -n "/surface2, /farming2, /surface3, /farming3, /industry2, /surface4, /services2"

This cuts the length of the command checklist roughly in half and makes it much less daunting!

[ldog]

Just going through the new stuff. Very nice tweaks!

onMapLoad.init is missing:
tweak do-job-now
dwarfvet enable
soundsense (this is my own tweak just to remind myself)

Those need to be enabled every time unless you've got some other method?

I don't remember if I've ever brought it up or not, but cutting the center bedrooms along with the redundant doors is 64 less doors we need to make. It's also somewhat improved pathing (although I doubt the bedrooms are big offenders of FPS loss since they only go to sleep like once per season). That is 192 bedrooms vs 216 for the 6 floor stack. Considering I see more married couples in current version of DF I think that is still more than enough unless you are raising the pop cap? Granted, I seem to have trouble fitting in an apartment stack, caverns always in my way.

From center of wagon running quickfort run library/dreamfort.csv -n /setup I get:
quickfort: expected to be at cursor position (47, 47, 69) on screen "dwarfmode/QueryBuilding/Some/Wagon" but cursor is at (45, 45, 69); there is likely a problem with the blueprint text in cell A219: "{startnobles}{startorders}{startburrows}{startmilitary}{starthotkeys}"

Since I ran it several times from various other positions (1 of my draft animals is on the center by the way) before checking, and then finally moving it off the wagon before it executed successfully, it added several plain cloaks to the uniforms, greaves to the metal as well, all were set to over instead of replace. Also the H menu it messed up the names, like it applied them and then tried a few more times and used whatever blank characters were left. I'm assuming partial reruns of the macro and probably not much in the way of error-trapping available for that. The other things seem to have applied normally.

Doesn't seem to like the multi-orders either:
[DFHack]# quickfort orders library/dreamfort.csv -n "/surface2, /farming2, /surface3, /farming3, /industry2, /surface4,
...rtress 0.47.05/hack/scripts/internal/quickfort/parse.lua:335: attempt to call a nil value (method 'description')
stack traceback:
        ...rtress 0.47.05/hack/scripts/internal/quickfort/parse.lua:335: in function <...rtress 0.47.05/hack/scripts/internal/quickfort/parse.lua:321>
        (...tail calls...)
        [C]: in function 'dfhack.call_with_finalizer'
        ...k 0.47.05-r04\Dwarf Fortress 0.47.05\hack\lua\dfhack.lua:72: in function 'dfhack.with_finalize'
        (...tail calls...)
        ...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:49: in global 'do_command_internal'
        ...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:138: in function <...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:134>
        [C]: in function 'dfhack.call_with_finalizer'
        ...k 0.47.05-r04\Dwarf Fortress 0.47.05\hack\lua\dfhack.lua:72: in function 'dfhack.with_finalize'
        ...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:132: in field '?'
        ...05-r04\Dwarf Fortress 0.47.05/hack/scripts/quickfort.lua:231: in local 'script_code'
        ...k 0.47.05-r04\Dwarf Fortress 0.47.05\hack\lua\dfhack.lua:753: in function 'dfhack.run_script_with_env'
        (...tail calls...)
[DFHack]#

[myk]

Added tweak do-job-now. I'll leave the others up to the discretion of the player. You can have more than one onMapLoad*.init file. In https://github.com/DFHack/dfhack/pull/1925 I'm naming the file we've been using to onMapLoad_dreamfort.init. Then players can add their own additions to onMapLoad.init. They'll both get run on map load (in alphabetical order).

Fair points about the inefficiency of the apartments layout. My thinking at the time was that the extra doors would add value to the rooms and make the dwarves happier. I do see happy thoughts from nice bedrooms, but I haven't really tested doing less, and it's absolutely true that the number of doors is onerous. I'll take a stab at an alternate layout that's not so door-heavy and see if it affects dwarf happiness.

Regarding the error message for the /setup blueprint: in this case, the error message is harmless. Everything actually does get applied correctly. Entering and leaving the (H)otkey menu tends to move the cursor around and trigger the query blueprint error detection. Long term, I plan to implement alias-level settings that will tell quickfort that it's ok for the cursor not to end up at the starting position for this particular alias. Short term, I bet if I force the wagon to the center of the screen with a simulated {F1} hotkey press then the cursor will end up in the expected position. That is, the /setup blueprint becomes:

Code: [Select]

{startnobles}{startorders}{startburrows}{startmilitary}{starthotkeys}{F1}
I hadn't done this before since it will fail if the player has redefined the F1 hotkey before running /setup, but I have tried to reinforce in several places that /setup should be run first, before any customization is done.

I just merged the multi-command handling yesterday, so you'll have to pull the most recent code for that to work.

[ldog]

Hey, what happened to your guide on the custom professions? I was reading it the other day but it vanished.
Still trying to get my head around that stuff.