Print

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

[myk]

Alright, I've merged the cleanup changes for Dreamfort and completed all the milestone 2 tasks for the blueprint overhaul.

I'm still working on a tool that will measure fort efficiency so we can objectively determine whether the "efficiency" tooling we're writing is actually helping, and whether changes to those tools are making things better or worse. The challenge I've run into is figuring out whether a job was completed successfully or whether it was canceled, and if it was canceled, whether it was canceled by the player or whether it was canceled because of lack of required materials. This is important because canceled tasks are "completed" quickly, and they would make the fort appear much more efficient than it really is, from a job latency perspective.

There are also a few things I've been discussing on the Discord server that I'd like to implement:

• quickfort needs a way to specify single-tile carved tracks to support the wipe-all-engravings-so-i-can-resmooth-and-reengrave-until-everything-is-masterwork use case
• also for that same use case, quickfort should detect masterwork engravings and refuse to designate them for destruction by default. I'll introduce a commandline parameter that will allow you to designate and destroy masterwork engravings so the current behavior is still possible.
• quickfort needs an API that can be called from other scripts.

For the API, I was thinking of this:

Code: [Select]

quickfort.apply_blueprint(params)

Applies the specified blueprint data and returns processing statistics. The
statistics structure is a map of stat ids -> {label=string, value=number}.

params is a table with the following fields:
  mode (required) - The name of the blueprint mode, e.g. 'dig', 'build', etc.
  data (required) - A sparse map populated such that data[z][y][x] yields the
      blueprint text that should be applied to the tile at map coordinate
      x, y, z.
  command - The quickfort command to execute, e.g. 'run', 'orders', etc.
      Defaults to 'run'.
  pos - A coordinate that serves as the reference point for the coordinates
      in the data map. That is, the text at data[z][y][x] will be shifted to
      be applied to coordinate pos.x + x, pos.y + y, pos.z + z. If not
      specified, defaults to {x=0, y=0, z=0}.
  aliases - a map of query blueprint aliases names to their expansions. If
      not specified, defaults to {}.
  dry_run - Just calculate statistics; don't actually apply the blueprint.
      Defaults to false.
  verbose - Output extra debugging information to the console. Defaults to
      false.

Example:

local guidm = require('gui.dwarfmode')
local quickfort = reqscript('quickfort')
-- dig a 10x10 block at the cursor position
quickfort.apply_blueprint{mode='dig', data={[0]={[0]={[0]='d(10x10)'}}},
                          pos=guidm.getCursorPos()}


[ldog]

Nice!
I'll have to give the burrows a try next go. I don't use them much outside of lockdown, but I was thinking of doing an underground treefarm currently (have multiple soil layers).
Already using the aquifer tap.
Prisoner dump too, although you've got it taking empty cages, I don't know if that was on purpose or an oversight. I also move it up 2 tiles, so the QSP is in the center. The troops tend to congregate more on the north end, and 2 less tiles hauling a full cage with no wheelbarrow is 2 less tiles. It could honestly go up 3 with the track stop right next to the door but I like to keep some spacing.

You could parse events from the log file for cancellation/completion (like Soundsense does).

Wipe and re-engrave would be awesome if you can pull it off!

Forgot if I mentioned, added a small (4 tiles around the metal QSP) pile for flux, because having the visual indicator saves me aggravation. I do a bronze pile too (I always wind up moving the sand anyway). Left the larger combined misc liquids pile where you have it since slurry needed to be added too, upped the max barrels to max (6).

Your apt level screenshot in guide is still old plan.

Example guide can strike "Late game, you can turn off their Architecture labor since that will be better handled by your Haulers." from Mason description since we removed it.

[myk]

I just finished working on a feature request to support repeating blueprints up and down z-levels. This enables me to finally include repeatable blueprints in the blueprint library.

I spent some time prepping a pump_stack blueprint set.  `repeat` makes it much much cleaner. Before, my pump_stack blueprint set had meta blueprints that included the base "pump from north" and "pump from south" blueprints various numbers of times. To apply the blueprints to your map, you'd use the largest size blueprint until you ran out of space, then the smaller sizes to fill the gaps. This was really really annoying (which is why I haven't included the blueprint in the library yet). Now with the --repeat commandline param, we just need a single 2-level blueprint and the user can specify exactly how many times to repeat it with a single command.

However, the blueprint set also had a copy of the north-south blueprints to accommodate east-west pump stacks.  I realized I could simplify the blueprints even further if we supported Euclidean transformations (rotations, reflections, translations). That way, we really only need the one north-south stack, and the user can rotate/flip it as necessary. This is even more powerful than having separate north-south and east-west blueprints since the position of the staircase can be adjusted to the user's preference.

Long story short, repeat is merged, but while I'm in this part of the code, I'm adding support for transform and shift as well.

[ldog]

I just finished working on a feature request to support repeating blueprints up and down z-levels. This enables me to finally include repeatable blueprints in the blueprint library.

I spent some time prepping a pump_stack blueprint set.  `repeat` makes it much much cleaner. Before, my pump_stack blueprint set had meta blueprints that included the base "pump from north" and "pump from south" blueprints various numbers of times. To apply the blueprints to your map, you'd use the largest size blueprint until you ran out of space, then the smaller sizes to fill the gaps. This was really really annoying (which is why I haven't included the blueprint in the library yet). Now with the --repeat commandline param, we just need a single 2-level blueprint and the user can specify exactly how many times to repeat it with a single command.

However, the blueprint set also had a copy of the north-south blueprints to accommodate east-west pump stacks.  I realized I could simplify the blueprints even further if we supported Euclidean transformations (rotations, reflections, translations). That way, we really only need the one north-south stack, and the user can rotate/flip it as necessary. This is even more powerful than having separate north-south and east-west blueprints since the position of the staircase can be adjusted to the user's preference.

Long story short, repeat is merged, but while I'm in this part of the code, I'm adding support for transform and shift as well.

Awesome!

[myk]

I'm finishing up unit tests for the transformation code. In the meantime, here's how the pump stack blueprint turned out (lightly reformatted for posting):

Code: [Select]

#notes label(help)
A pump stack is useful for moving water or magma up through the z-levels.

To use these blueprints:

1) Measure how many z-levels the pump stack should span.

2) Position the cursor on the bottom level of the future pump stack. It should be on the z-level
  just above the liquid you want to pump. Run "quickfort run library/pump_stack.csv -n /dig2SN"
  to see where the suction hole will end up. Replace "run" with "undo" in the previous command to clean up.

3) If you need an East-West pump stack, or if you need the staircase in another spot, use the "--transform"
  commandline option to alter the blueprint to your needs. For example:
  "quickfort run library/pump_stack.csv -n /dig2SN --transform rotcw,fliph". If you use a transformation, be
  sure to use the same option for the remaining commandlines.

4) Once you have everything lined up, run "quickfort run library/pump_stack.csv -n /dig2SN --repeat up,20"
  to designate the entire pump stack for digging. Replace that last "20" with the height of your pump stack
  divided by 2 (since each repetition of /dig2SN is two z-levels high). If the height ends up being one too
  many at the top, manually undesignate the top level.

5) Since you do not need to transmit power down below the lowest level, replace the channel designation on
  the middle tile of the bottom-most pump stack level with a regular dig designation. Likewise, replace the
  Up/Down staircase designation on the lowest level with an Up staircase designation.

6) After the stack is dug out, prepare for building by setting the buildingplan plugin material filters for screw
  pumps (b-M-s-M). If you are planning to move magma, be sure to select magma-safe materials.

7) Finally, position the cursor back on the access stairs on the lowest level and run
  "quickfort run library/pump_stack.csv -n /build2SN --repeat up,20" (with 20 replaced with your desired
  repetition count and with your --transform command, if any).

Sometimes, a screw pump will spontaneously deconstruct while you are building the stack. This will reduce
the efficiency of the stack a little, but it's nothing to worry about. Just re-run the /build2SN blueprint over
the entire stack to "fix up" any broken pieces. The blueprint will harmlessly skip over any correctly-built
screw pumps.

See the wiki for more info on pump stacks: https://dwarffortresswiki.org/index.php/Screw_pump#Pump_stack

#dig label(digSN) start(2;4;on access stairs) hidden() for a pump from south level

,,,d
,,,h
,i,d,d
,,,h

#dig label(digNS) start(2;4;on access stairs) hidden() for a pump from north level

,,,h
,d,d,d
,i,,h
,,,d

#meta label(dig2SN) start(at the bottom level on the access stairs) 2 levels of pump stack - bottom level pumps from the south
/digSN
#<
/digNS
#build label(buildSN) start(2;4;on access stairs) hidden() for a pump from south level

,,,`
,,,~
,`,`,Msm
,,,`

#build label(buildNS) start(2;4;on access stairs) hidden() for a pump from north level

,,,`
,`,`,~
,`,,Msu
,,,`

#meta label(build2SN) start(at the bottom level on the access stairs) 2 levels of pump stack - bottom level pumps from the south
/buildSN
#<
/buildNS

online version of that blueprint here

[myk]

I realized I never replied to your earlier post. Sorry about that!

Already using the aquifer tap.

I'm fixing this up for inclusion next. It needs a good bit of help text to describe how to set up drainage to safely dig out the tap.

Prisoner dump too, although you've got it taking empty cages, I don't know if that was on purpose or an oversight.

It takes empty cages by design. Otherwise they can fill up the stockpile north of the barracks when you "process" all the caged prisoners in the quantum stockpile.

Wipe and re-engrave would be awesome if you can pull it off!

This is merged. Quickfort now avoids designating tiles for digging/track engraving if the tiles contain masterwork engravings. The quality of engraving to protect is configurable.

Forgot if I mentioned, added a small (4 tiles around the metal QSP) pile for flux, because having the visual indicator saves me aggravation.

Good idea. I shrunk the coal stockpile and added visual indicators for flux and iron.

Your apt level screenshot in guide is still old plan.

Yeah, I need to update the screenshots for apartments and now industry too

Example guide can strike "Late game, you can turn off their Architecture labor since that will be better handled by your Haulers." from Mason description since we removed it.

Thanks! Done.

Transformations are merged and Dreamfort has been updated to take advantage of the new features. This might be the first update to Dreamfort that actually resulted in a *smaller* file size : )

[myk]

I finished writing the help text for the aquifer tap. The walkthrough turned out longer than I would like, but hey, routing water is complicated!

Code: [Select]

#notes label(help)
This blueprint will help you get a safe, everlasting source of fresh water
from a light aquifer.

Here's the procedure:

1) Dig a tunnel from where you want the water to end up (e.g. your well
cistern) off to an unused portion of the map.

2) From the end of that tunnel, dig a staircase straight up to the z-level
just below the lowest aquifer level. Also dig the staircase down one z-level.

3) From the bottom of the staircase (the z-level below where the water
will flow to your cisterns), dig a one-tile wide tunnel to the edge of the
map. Smooth the map edge tile and carve a fortification. The water can
flow through the fortification and off the map, allowing the dwarves to dig
out the aquifer tap without drowning.

4) Place a lever-controlled floodgate in the drainage tunnel and open the
floodgate.

5) If you care about how nice things look, haul away any boulders and
smooth the tiles. You won't be able to access any of this area once it fills
up with water!

6) Apply this blueprint to the z-level above the top of the staircase, inside
the lowest aquifer level. Do not unpause until after the next step.

7) Damp stone cancels adjacent dig designations if the tile is currently
hidden, so to avoid having to re-apply this blueprint after every tile your
dwarves dig, position the cursor straight up (north) of the left-most tile
designated for digging and straight left (west) of the topmost designated
tile and run the following commands in the DFHack console:
tiletypes-command f any ; f designated 1 ; p any ; p hidden 0 ; r 23 23 1
tiletypes-here

8) Unpause and dig out the tap. If you care about appearances, haul away
any boulders and feel free to remove the ramps (d-z). The water will safely
flow down the staircase, through the open floodgate, and off the map until
you choose to close the floodgate.

9) Once everything is dug out and all dwarves are out of the waterways,
close the floodgate. Your cisterns will fill with water. Since the waterway to
your cisterns is depressurized, the cisterns will stay forever full, but will not
flood.

A diagram might be useful. Here is a vertical view through the z-levels. This
blueprint goes at the top:

j  <- center of this blueprint
i
... <- make this as tall as you need
i
i <- cistern outlet level
u <- drainage level

Good luck! If done right, this method is the safest way to supply your fort
with clean water.

Here's the online version: https://docs.google.com/spreadsheets/d/1kwuCipF9FYAHNP9C_XlMpqVseaPu4SmL9YLUSQkbW4s/edit?usp=sharing

What do you think? Is this clear? Can you visualize what you have to do from the help text? I also plan to link to https://docs.dfhack.org/en/stable/docs/guides/quickfort-library-guide.html#example-plumbing-to-fill-cisterns to show what the pressure break should look like.

[ldog]

I finished writing the help text for the aquifer tap. The walkthrough turned out longer than I would like, but hey, routing water is complicated!

Code: [Select]

#notes label(help)
This blueprint will help you get a safe, everlasting source of fresh water
from a light aquifer.

Here's the procedure:

1) Dig a tunnel from where you want the water to end up (e.g. your well
cistern) off to an unused portion of the map.

2) From the end of that tunnel, dig a staircase straight up to the z-level
just below the lowest aquifer level. Also dig the staircase down one z-level.

3) From the bottom of the staircase (the z-level below where the water
will flow to your cisterns), dig a one-tile wide tunnel to the edge of the
map. Smooth the map edge tile and carve a fortification. The water can
flow through the fortification and off the map, allowing the dwarves to dig
out the aquifer tap without drowning.

4) Place a lever-controlled floodgate in the drainage tunnel and open the
floodgate.

5) If you care about how nice things look, haul away any boulders and
smooth the tiles. You won't be able to access any of this area once it fills
up with water!

6) Apply this blueprint to the z-level above the top of the staircase, inside
the lowest aquifer level. Do not unpause until after the next step.

7) Damp stone cancels adjacent dig designations if the tile is currently
hidden, so to avoid having to re-apply this blueprint after every tile your
dwarves dig, position the cursor straight up (north) of the left-most tile
designated for digging and straight left (west) of the topmost designated
tile and run the following commands in the DFHack console:
tiletypes-command f any ; f designated 1 ; p any ; p hidden 0 ; r 23 23 1
tiletypes-here

8) Unpause and dig out the tap. If you care about appearances, haul away
any boulders and feel free to remove the ramps (d-z). The water will safely
flow down the staircase, through the open floodgate, and off the map until
you choose to close the floodgate.

9) Once everything is dug out and all dwarves are out of the waterways,
close the floodgate. Your cisterns will fill with water. Since the waterway to
your cisterns is depressurized, the cisterns will stay forever full, but will not
flood.

A diagram might be useful. Here is a vertical view through the z-levels. This
blueprint goes at the top:

j  <- center of this blueprint
i
... <- make this as tall as you need
i
i <- cistern outlet level
u <- drainage level

Good luck! If done right, this method is the safest way to supply your fort
with clean water.

Here's the online version: https://docs.google.com/spreadsheets/d/1kwuCipF9FYAHNP9C_XlMpqVseaPu4SmL9YLUSQkbW4s/edit?usp=sharing

What do you think? Is this clear? Can you visualize what you have to do from the help text? I also plan to link to https://docs.dfhack.org/en/stable/docs/guides/quickfort-library-guide.html#example-plumbing-to-fill-cisterns to show what the pressure break should look like.

Good. Yes, it is clear and even after a long hiatus from the game it gives a good picture of what is going on.

[myk]

Good. Yes, it is clear and even after a long hiatus from the game it gives a good picture of what is going on.

Thanks! Merged.

Next up is the prisoner processing system for Dreamfort. Integrating the blueprint into the Dreamfort blueprints was easy. Again, the help text is the hard part. It needed to be written, though. Dreamfort is designed to be highly defensible, but I never documented exactly *how* I expect players to defend it. This is what I came up with:

Sieges and Prisoner Processing:

Here are some tips and procedures for handling seiges --
including how to clean up afterwards!

- Ensure your "Inside" burrow includes only below-ground
areas and safe surface areas of your fort. In particular, don't
include the "atrium" area (where the "siege bait" zone is) or
the trapped hallways.

- When a siege begins, set the alert to "Siege" to ensure all
your civilians stay out of danger. Immediately pull the lever
to close the outer main gate. It is also wise to close the
trade depot and inner main gate as well. That way, if enemies
get past the traps, they'll have to go through the soldiers in
your barracks.

- During a siege, use the levers to control how attackers path
through the trapped corridors. If there are more enemies than
cage traps, time your lever pulling so that the inner gates snap
closed before your last cage trap is sprung. Then the remaining
attackers will have to backtrack and go through the other
trap-filled hallway.

- If your cage traps fill up, ensure your hallways are free of
uncaged attackers, then close the trap hallway outer gates
and open the inner gates. Unset the civilian alert and allow
your dwarves to reset all the traps -- make some extra cages
in preparation for this! Then re-set the civilian alert to "Siege"
and open the trap hallway outer gates.

- Once the last attacker is caged, open all the gates and unset
the civilian alert. Life is normal again!

After a siege, you can use the caged prisoners to safely train
your military. Here's how:

- Once the prisoners are hauled to the "prisoner quantum"
stockpile, run "stripcaged all" in the DFHack console.

- After all the prisoners' items have been confiscated, bring
your military dwarves to the barracks (if they aren't already
there).

- Use the zone (i) menu to assign a group prisoners to the
pasture that overlaps the prisoner quantum stockpile

- Hauler dwarves will come and release prisoners one by one.
Your military dwarves will immediately pounce on the released
prisoner and chop them to bits, saving the hauler dwarves
from being attacked. Repeat until all prisoners have been
"processed".

Is that sufficiently clear? I haven't merged these changes yet since I want to do a little more testing first. The PR is up, though: https://github.com/DFHack/dfhack/pull/2017/files

I also redid all the annotated images in a real graphics app (GIMP instead of my screenshot capture app). Since the urls didn't change, the new images should already be visible in the current blueprint library guide: https://docs.dfhack.org/en/stable/docs/guides/quickfort-library-guide.html#visual-overview

[ldog]

Yeah, that's a handy write-up.

[myk]

DFHack-0.47.05-r4 is released!

Lots of quickfort and blueprint improvements, and some good updates to dreamfort (see the fancy new screenshots) and the blueprint library.

Blueprint transformations (rotations, flipping, etc.) are in this release, but they aren't accessible from gui/quickfort yet. I'm planning on providing interactive rotation support in a new preview viewscreen, which will overlay the active map with indicators for where a blueprint will make changes. I gathered my thoughts on this feature here, if anyone is interested in the gory technical details or wants to provide input for the design.

[myk]

I uploaded a new fully built dreamfort to dffd if anyone would like to play around with it without having to actually build it from scratch: https://dffd.bay12games.com/file.php?id=15434

[MYSTICBADGER]

Hello, I'm using the blueprint gui to generate my own blueprints, but every time I generate them, I can't find them. They don't seem to be generated anywhere. My df folder is not in a system location, so I don't know why it doesn't create the files.
Any ideas for me ?


Edit : found it ! They were in my df folder, not the quickfort folder

[myk]

They get generated in the blueprints subdirectory in your df folder, which is the same place that quickfort looks for blueprints to run. Were you expecting them to appear in the dfhack-config/quickfort directory? I could add a note to the success message when you generate a blueprint with blueprint or gui/blueprint to make this more clear. Would that have helped?

edit: actually, I see that we already output the full (relative) path to the generated blueprint file -- it includes the "blueprint/" directory prefix.

[myk]

A brief update on what I've been working on.

I got basic blueprint transformation capabilities into the last DFHack release. It works great for simple blueprints. It handles the majority of library blueprints just fine. It does have a few limitations, though, that prevent it from being a complete general solution.

First, it transforms the location of a cell with expansion syntax (e.g. d(15x20)), but it doesn't transform the shape of the expanded area. For example, a 5 by 1 area rotated clockwise would properly come out as a 1 by 5 area if each cell were individually designated (e.g. d,d,d,d,d), but if you use the equivalent expansion syntax (d(5x1)), the designation would start at the correct cell, but you'd still get a 5x1 area instead of a 1x5.

Second, buildings get rotated around to the correct tiles, but if the building has a direction associated with it, like which direction a bridge opens or whether an axle is horizontal or vertical, that direction is not modified. This makes rotated versions of these building types not work as expected.

Third, quickfort supports just specifying the center tile of a building on a blueprint and it will automatically expand the footprint of the building to the building type's regular dimensions. For example, you just have to write a single wm to designate an entire 3x3 mason's workshop. Rotation doesn't change anything.. unless the building type has both a fixed size and is not a square. In the current version, these buildings get expanded in different directions depending on the rotation.

Finally, cursor movements on query blueprints don't get modified at all by transformations. If you have one stockpile configured to give to an adjacent workshop, and then you rotate the blueprint, the cursor movements will go off in the wrong direction and the blueprint will error out.

Now, none of this worked correctly in the original python-based quickfort either, but I think we can do better.

Expansion syntax handling is already implemented and merged. As a side benefit, you can now use negative numbers in expansion syntax. This means that you can designate rectangles from any corner now. This includes designations for carved tracks, so it won't be quite as complicated as before to carve track corners.

I've started on implementing rotating direction-specific buildings and footprint expansion. It turned out to be a lot more difficult than I originally expected. Each key sequence that indicates a building type on a blueprint needed an associated database for which other building key sequences it could turn into for each kind of transformation. I'm writing regression tests for my implementation right now.

I have ideas for how to automatically adjust map cursor movements on query blueprints, but I'll write more about that later once I figure out what is feasible.