quickfort
Processes Quickfort-style blueprint files. This is a pre-release – not all features are implemented yet.
Quickfort blueprints record what you want at each map coordinate in a spreadsheet, storing the keys in a spreadsheet cell that you would press to make something happen at that spot on the DF map. Quickfort runs in one of four modes: dig, build, place, or query. dig designates tiles for digging, build builds buildings and constructions, place places stockpiles, and query changes building or stockpile settings. The mode is determined by a marker in the upper-left cell of the spreadsheet (e.g.: #dig in cell A1).
You can create these blueprints by hand or by using any spreadsheet application, saving them as .xlsx or .csv files. You can also build your plan “for real” in Dwarf Fortress, and then export your map using the DFHack blueprint plugin for later replay in a different fort. Blueprint files should go in the blueprints subfolder in the main DF folder.
You can read more about how to create blueprint files in the blueprints/README.txt file, and there are ready-to-use examples of blueprints in each of the four modes in the blueprints/library folder.
Usage:
quickfort set [<key> <value>]
Allows you to modify the active quickfort configuration. Just run quickfort set to show current settings. See the Configuration section below for available keys and values.
quickfort list [-l]
Lists blueprints in the blueprints folder. Blueprints are .csv files or sheets within .xlsx files that contain a #<mode> comment in the upper-left cell. By default, blueprints in the blueprints/library/ subfolder are not included. Specify -l to include library blueprints.
quickfort <command> <list_num>
Applies the blueprint with the number from the list command.
quickfort <command> <filename> [-s <sheet_num>]
Applies the blueprint from the named file. If it is an .xlsx file, the -s parameter is required to identify the sheet number (the first sheet is -s 1).
<command> can be one of:
run
applies the blueprint at your current active cursor position.
orders
uses the manager interface to queue up orders for the specified build-mode blueprint.
undo
applies the inverse of the specified blueprint, depending on its type. Dig tiles are undesignated, buildings are canceled or removed (depending on their construction status), and stockpiles are removed. No effect for query blueprints.
Configuration:
The quickfort script reads its startup configuration from the dfhack-config/quickfort/quickfort.txt file, which you can customize. The following settings may be dynamically modified by the quickfort set command (note that settings changed with the quickfort set command will not change the configuration stored in the file):
blueprints-dir (default: ‘blueprints’)
Can be set to an absolute or relative path. If set to a relative path, resolves to a directory under the DF folder.
force-marker-mode (default: ‘false’)
Set to “true” or “false”. If true, will designate dig blueprints in marker mode. If false, only cells with dig codes prefixed with m will be designated in marker mode.
interactive-build (default: ‘false’)
Allows you to manually select building materials for each building/construction when running (or creating orders for) build blueprints. Materials in selection dialogs are ordered according to preferences in materials.txt (see below). If false, will only prompt for materials that have :labels. See original Quickfort documentation for details.
There are also two other configuration files in the dfhack-config/quickfort folder: aliases.txt and materials.txt. aliases.txt defines keycode shortcuts for query blueprints, and materials.txt defines forbidden materials and material preferences for build blueprints. The formats for these files are described in the files themselves.
#place
,a, , , ,a,a
a,a, , , , ,a
a,a,a, , , ,a
a,a,a,a,a,a,a
would create a valid, though oddly shaped, animal stockpile.#place
,a,w,w,w,a,a
a,a,w,w,w,w,a
a,a,a,w,w,w,a
a,a,a,a,a,a,aWould also work?
#place
a,u,s,h
u,u,s,h
s,s,s,h
h,h,h,h
(which doesn't sound complicated but there's some technical complexity with it)
#place
a,a, ,a
a, ,a,a
In either case, I plan to suport adding labels to the cells so a stockpile can be defined as disconnected patches. Like, if we do decide to keep the flood fill just checking orthogonal tiles, we could still define the above stockpile as a single pile like this:#place
a:onepile,a:onepile, ,a:onepile
a:onepile, ,a:onepile,a:onepile
or even do a disconnected one like this:#place
a:onepile, , , ,a:onepile
a:onepile, , , ,a:onepile
a:onepile, , , ,a:onepile
But I'll get to that once I get basic functionality done for build and query
I should also spend some time putting together a library of useful example blueprints. If anyone has blueprints to share, I'd love to see them!I know that the Starter Pack has its own library of blueprints. Perhaps you could port those?
Currently, just orthogonally, but there's no reason why I can't make it also connect diagonally if that's what map makers want. What would be "expected" by a novice mapmaker? should this be one stockpile or two?:Slightly late to this[1], but I tend to chequerboard some pairs of stockpiles (say in preparation for alloy-making, copper-storing tiles alternating with tin ones, or whatever) for no good reason other than aesthetics and a rather specific kind of at-a-glance level checking.Code: [Select]#place
a,a, ,a
a, ,a,a
#build
,`
,trackstopN
`,`,`
`,`,`
`,`,`
#place
,s
,
s,s,s
s,s,s
s,s,s
#query
,quantum
,quantumstopfromsouth
`,`,otherstone
`,`,enablegems
`,`,`
quantum: {linksonly}{nocontainers}{enableanimals}{enablefood}{enablefurniture}{enablestone}{enableammo}{enablecoins}{enablebars}{enablegems}{enablefinishedgoods}{enableleather}{enablecloth}{enablewood}}{enableweapons}{enablearmor}{enablesheet}where each of those elements are aliases themselves, for example:foodprefix: s{Down}
enablefood: {foodprefix}e^
The caret ("^") is shorthand for {ESC}, required to exit the stockpile settings screen. query blueprints have to make sure to return to the same screen they started on whenever they apply a configuration so we can move the cursor to the next cell to configure.booze: {foodprefix}b{Right}{Down 5}p{Down}p^
After an intense battle (https://github.com/DFHack/dfhack/pull/1620) with the build system, the quickfort script now supports reading from .xlsx files (https://github.com/DFHack/scripts/pull/177). That was a lot tougher than I thought it would be! Cross-platform support is difficult when building libraries you don't control on operating systems you don't have! Huge thanks to lethosor for getting me unstuck when I ran into linker symbol resolution issues, and for giving me an excellent walkthough for how to make C pointers type safe when sending them through the Lua layer!I'm still scarred from some library integration - build time is 200 times longer.The library itself builds for half a day. Never again...
<...>
There are still quite a few PRs to submit. I'm getting it merged feature by feature, and I don't want to overload lethosor with too many PRs at once (the quickfort script is almost 4000 lines long at this point). All the required C++ code has been merged, though, so if you're building DFHack from source and want to try quickfort, you can download it here (https://drive.google.com/file/d/10in6-XqzqKfQCP4mS6WZdjDmu_2v7l-s/view?usp=sharing). Just extract the file in your hack/scripts directory. It contains the quickfort.lua entrypoint (which is mostly just help text) and the actual script logic in internal/quickfort/*.lua. It will be much easier, of course, to wait until it's included in an actual release (I'm hoping it will all be merged by the upcoming -r3), but I'm posting the code in case anyone is eager to try it out.So the download is if one would like to compile dfhack? Do you or anyone else have a post-compiled version we could drop in just to see how it works?
I've completed the last two major development milestones! There is now a small library of example blueprints, including the large-scale "dreamfort" end-to-end example. There is also now a GUI, so you can use quickfort from a pop-up dialog instead of the command line. Once it all clears review and gets merged, it will be available for actual use! I'm really looking forward to feedback so we can smooth out any remaining rough edges and implement features that people come up with.Is the gui present in the build that you linked? If so, how it is accessed? Perhaps I'm being blind, but I see no reference to it anywhere.
Does 'quickfort gui' not work? If not, I must have saved from the wrong branch :-\ Will fix when I get home. Btw, full command documentation will be on docs.dfhack.org once the script is merged, but for now you can read it in the top comment in quickfort.lua.It does not, it only reprints the usage commands. Also, the documention does not mention anything about the GUI, I believe. I did a whole control-f and everything.
, , , , ,3, , , , ,
d,d,d,d,d,3,d,d,d,d,d
d,d,d,d,d,3,d,d,d,d,d
d,d,d,d,d,3,d,d,d,d,d
d,d,d,d,d,3,d,d,d,d,d
d,d,d,d,d,3,d,d,d,d,d
d,d,d,d,d,3,d,d,d,d,d
d,d,d,d,d,3,d,d,d,d,d
d,d,d,d,d,3,d,d,d,d,d
d,d,d,d,d,3,d,d,d,d,d
d,d,d,d,d,3,d,d,d,d,d
d,d,3,3,3,3,3,3,3,d,d
, ,3, , , , , ,3, ,
4,4,2,4,4, ,4,4,2,4,4
4,2,2,2,4, ,4,2,2,2,4
4,2,2,2,4, ,4,2,2,2,4
4,2,2,2,4, ,4,2,2,2,4
4,4,4,4,4, ,4,4,4,4,4
(I don't know if there's similar use of Marking and Designate-(All,Auto-mine,etc)... Perhaps the automine extension, but perhaps not given the purpose to carefully mould rooms, without excess.)
There's also marking and the auto-dig options.In my opinion, these probably aren't that important to support, at least right now. From what I remember (which could be out of date), auto-dig only works on revealed vein tiles, so I don't see much of a use-case for pre-planned auto-dig designations (since they would most likely do nothing). As for markers, there's a d-M option that you could use to toggle the marker status of some (or all) of a blueprint after it has been applied. I don't expect many cases where people would want fine-grained control over which tiles are just markers, but I suppose there could be some.
#dig
d, d, d, d,d
d,md,md,md,d
d,md,md,md,d
d,md,md,md,d
d, d, d, d,d
#dig
d,d,d,d,d
d,md(3x3),,,d
d, , , , d
d, , , , d
d,d,d,d,d
[DFHack]# quickfort run important_level.csv
[DFHack]# quickfort set force_marker_mode true
[DFHack]# quickfort run level_i_just_want_to_plan_but_not_dig_right_now.csv
[DFHack]# quickfort reset
Perhaps assume a bare digit to be "dig, priority <n>", like the suggestion of a bare letter to be "<whatever>, priority 4". Any requirements beyond that (or pedantic specification of the assumption, for at least the better human readability of the 2.5-dimensional data without the overwhelming vision of whitespace 'gaps') need to be char+digit.
What else should we include?The bedroom styles from the old quickfort library provided in the LNP.
Are the bedroom blueprints online somewhere I can check them out? Are they from https://github.com/joelpt/quickfort/tree/master/Blueprints ?No, they're in the ...\LNP\utilities\Quickfort\blueprints folder from the PeridexisErrant's Starter Pack (https://dffd.bay12games.com/file.php?id=7622).
I uploaded them separately as well, if you would prefer.
Are the bedroom blueprints online somewhere I can check them out? Are they from https://github.com/joelpt/quickfort/tree/master/Blueprints ?No, they're in the ...\LNP\utilities\Quickfort\blueprints folder from the PeridexisErrant's Starter Pack (https://dffd.bay12games.com/file.php?id=7622).
I uploaded them separately as well, if you would prefer. (https://mega.nz/file/qtFV3aQR#zMogJ7ePwogUSxhcuhPFRH4QJCxTw-s2qV9x_I5eC-Q)
I'd default to sticking them in the library directory - to help with discoverability, how about adding a hint line like "[and list NN more with `quickfort list --library`]" as the last line of default output?
#query
{quantumstopfromeast}{namelastrouteprefix}Goods/Wood quantum{namelastroutesuffix}
but we could potentially use the syntax I defined to simplify to:#query
{quantumstopfromeast name="Goods/Wood quantum"}
I put that on my "Future ideas" listTL;DR Quickfort is not accessible to me without learning the blueprint macro language to make use of quickfort.
I hoped I would be able to apply blueprints and capture existing structures into blueprints without learning the blueprint macro language. I hoped and wondered if it was possible for me to build a fort with quickfort by applying a blueprint example, make some modifications, capture the design to a new blueprint, and apply the new blueprint to a fresh embark.
When I resumed the game, I started getting announcements about non-economic blocks and unable to complete <some> workshop.
In my Starter Pack, I found two folders called blueprints.
I guess I could work on the dwarffortresswiki.org to help others become aware of the two different programs
I think of the Quickfort User Guide as something like The C Programming Language by Kernighan and Ritchie. I think the Quickfort User Guide could benefit from a "hello, world" example. To quote from Kernighan, "The only way to learn a new programming language is by writing programs in it." If Dreamfort is a showcase of blueprint code, I think the "hello, world" example should be one of the first building blocks of Dreamfort. There are a few code chunks in the Editing Blueprints section of the Quickfort User Guide, I plan to write files based on those code chunks and learn the language. Once I learn enough to read the Dreamfort "/surface1", I hope to be able to take chunks of code from that file to make a tutorial for myself.
Buildingplan Global Settings
e: Enable all: Off
Enables buildingplan for all building types. Use this to avoid having to
manually enable buildingplan for each building type that you want to plan.
Note that DFHack quickfort will use buildingplan to manage buildings
regardless of whether buildingplan is "enabled" for the building type.
Allowed types for generic, fire-safe, and magma-safe building material:
b: Blocks: On
s: Boulders: On
w: Wood: On
r: Bars: Off
Changes to these settings will be applied to newly-planned buildings.
A: Apply building material filter settings to existing planned buildings
Use this if your planned buildings can't be completed because the settings
above were too restrictive when the buildings were originally planned.
M: Edit list of materials to avoid
potash
pearlash
ash
coal
Buildingplan will avoid using these material types when a planned building's
material filter is set to 'any'. They can stil be matched when they are
explicitly allowed by a planned building's material filter. Changes to this
list take effect for existing buildings immediately.
g: Allow bags: Off
This allows bags to be placed where a 'coffer' is planned.
f: Legacy Quickfort Mode: Off
Compatibility mode for the legacy Python-based Quickfort application. This
setting is not needed for DFHack quickfort.
orders import automation) means that the low level toil of building a self-sustaining fortress is now completely automated, and players can focus on other exciting things, like trade or dwarven engineering projects or preparing for HFS or conquering the world!The blueprint plugin will currently produce perfectly valid blueprints that dfhack quickfort will use, but it has not yet been modified to take advantage of all of dfhack quickfort's new capabilities. This is my feature list for blueprint that I expect to work on (any help from the community on this is, of course, very much appreciated):blueprint doesn't write output for all building types. There is some duplication here since both blueprint and quickfort need complete mappings of hotkeys to building types. I plan to factor a queryable database out of quickfort that they both can use so we only have one place to maintain the mappings.
- Support remaining building types
That is, make use of dfhack quickfort's extended modelines: comment, label, start position and start_comment, message, hidden, etc. More info about modelines in the guide (https://docs.dfhack.org/en/latest/docs/guides/quickfort-user-guide.html#modeline-markers)
- Specify blueprint modeline metadata
at least pick up all the top-level enabled categories. recording full stockpile configuration will take a lot more work, though
- Multi-type stockpiles
- Non-rectangular stockpiles
- Zone blueprints (incl. detailed settings)
more than just the current if room then "r+". I'm thinking actual room sizes, justice settings, door settings, etc.
- Room configuration
If they're within the same blueprint
- Stockpile links (give/take)
And then I'm thinking blueprint needs some usability features too:blueprint is not very user friendly when it comes to specifying the area to scan. I'd like to add a "box select" mode (perhaps stolen from/shared with the automaterial feature of the same name) so you can select the bounds of your blueprint directly on the game map.
- Select target area with cursor
I don't have this work scheduled for myself yet, but it is on my radar.
it doesn't mention anything about you or your accomplishmentsI'm not really sure what you're looking for, but these don't seem like things that belong in the documentation to me (other than possibly mentioning breaking changes, but the guide currently says that any Python quickfort blueprints should work with this script). There are lots of contributors to DFHack, listed on the authors page (https://docs.dfhack.org/en/latest/docs/Authors.html), and changes are listed in the changelog (https://docs.dfhack.org/en/latest/docs/NEWS.html) (including some quickfort changes).
Assuming you are referring to https://docs.dfhack.org/en/latest/docs/guides/quickfort-user-guide.html, it is the latest - it has "latest" in the URL. This thread and that guide are about the new quickfort script, which is implemented as a DFHack script. It has always been a script, never a plugin (see also the first post of this thread). The guide does reuse some material (but not all) from an older implementation of quickfort, which was an external utility (independent of DFHack) written in Python.
You may be confusing this with blueprint (https://docs.dfhack.org/en/latest/docs/Plugins.html#blueprint), which is a plugin that has existed for a while and can be used in combination with quickfort, but it has a different use-case.Quoteit doesn't mention anything about you or your accomplishmentsI'm not really sure what you're looking for, but these don't seem like things that belong in the documentation to me (other than possibly mentioning breaking changes, but the guide currently says that any Python quickfort blueprints should work with this script). There are lots of contributors to DFHack, listed on the authors page (https://docs.dfhack.org/en/latest/docs/Authors.html), and changes are listed in the changelog (https://docs.dfhack.org/en/latest/docs/NEWS.html) (including some quickfort changes).
db(20x20) to dump all items in a 20 by 20 area.
Yeah, all actions in the (d)esignate menu are implemented. 'bd' in a #dig blueprint cell will designate all items in that cell for dumping. This works with expansion syntax too, so you can write, for example,Code: [Select]db(20x20)to dump all items in a 20 by 20 area.
#place set up weapons quantum stockpile
p, ,c
#build set up quantum trackstop
,trackstopE
#query configure quantum dump
{nocontainers}{givename name="weapons feeder"},{quantumstopfromwest name="weapons quantum rt."},{quantum name="weapons quantum"}
buildingplan set all_enabled true
on-new-fortress buildingplan set boulders false; buildingplan set logs false
bars are off by default so we don't actually have to set that one. Note that I just set boulders and logs on new fortresses. They'll get saved with the fortress after that, and if I do change them in-game, I don't want those changes to be overwritten by commands in my onMapLoad.init.orders import)As requested by A_Curious_Cat. One of the major problems with the alias documentation being in aliases.txt is that aliases.txt is a user configuration file and it doesn't get overwritten when you install a new version of DFHack. Therefore, if the docs in aliases.txt get updated, players with existing aliases.txt files *will never see the updated docs*. Pure silliness. Alias documentation belongs on docs.dfhack.org with the rest of the docs.
- Move alias documentation from aliases.txt to the user guide
Very nice!Neat, I've enabled that - didn't realize it was a feature, but it's been something I've wanted to investigate for a while.
FYI DFHack could enable docs previews for pull requests (https://docs.readthedocs.io/en/stable/guides/autobuild-docs-for-pull-requests.html), if you wanted to have an online HTML version of your current draft ;D
.. _quickfort-alias-guide:
Quickfort Alias Guide
=====================
Explicit targets can be used across documents (strictly speaking, this is a Sphinx feature - the RST spec itself only focuses on single documents).
Note that DF does not handle keys that have more than a single modifier, soPersonally, I use Ctrl+Alt+o for orders fine. Maybe Windows issue?
sequences like ``{Ctrl}{Alt}a`` will result in an error.
Getting a lot of use out of it (especially since DF keeps crashing so I get to do the same things over and over and over again...I'm getting a lot of practice)I'm curious now - could this be related to the comment about some zones causing crashes above (on the previous page)?
Getting a lot of use out of it (especially since DF keeps crashing so I get to do the same things over and over and over again...I'm getting a lot of practice)I'm curious now - could this be related to the comment about some zones causing crashes above (on the previous page)?
I couldn't reproduce the crash, though I gave myself a good forehead smack when I saw the missing active flag. I'll get that fixed up then go back to investigating the crash.
I don't think my crashes are related to Quickfort, it seems pretty stable. Lethosor has been looking into it.There is still a possibility that quickfort (or DFHack) is corrupting something that causes crashes later, but doesn't crash immediately when you use it. If you're seeing frequent crashes across different saves, and have been using quickfort in all of them, then I would recommend trying similar things in different saves without using quickfort to see if you also get crashes.
I don't think my crashes are related to Quickfort, it seems pretty stable. Lethosor has been looking into it.There is still a possibility that quickfort (or DFHack) is corrupting something that causes crashes later, but doesn't crash immediately when you use it. If you're seeing frequent crashes across different saves, and have been using quickfort in all of them, then I would recommend trying similar things in different saves without using quickfort to see if you also get crashes.
Just want to say great work on this.Thanks! I appreciate that : )
So I noticed the labels not being set for Dreamfort zones & piles, since I was reading along from the download, but I realize the files included with the LNP don't have those lines. Editing them in, they do work nicely (and saves a lot of typing).Yeah, the online spreadsheet has them, but the changes haven't been merged with DFHack yet (pull request here (https://github.com/DFHack/dfhack/pull/1750)) You can download the spreadsheets (File -> Download -> Microsoft Excel), put the .xlsx files in your blueprints folder, and use those directly too.
I like it, other than central stairs being a known contributor to FPS death and also Fun! caused by falling objects/dorfs, I suggest a central ramp.I like the idea. Currently, each level has stairs included, but I won't be able to do that with ramps since now each level can have either one of two possible ramp placements. I can change the stair_guide (https://docs.google.com/spreadsheets/d/1vlxOuDOTsjsZ5W45Ri1kJKgp3waFo8r505LfZVg5wkU/edit#gid=1058843185) to run the ramp down 10 levels or so, and make that blueprint unhidden so it can be manually run repeatedly to extend the ramps down further as needed. Probably also want to rename it from 'stair_guide' to 'central_ramp'. Overall, this increases complexity for people who are trying to use dreamfort, but results in a better/safer fortress and exemplifies best practices. I'm very wary about making the blueprints any more difficult to apply, but in this case it's probably a good trade-off.
While I'd prefer a 3 wide ramp myself, this is what fits without much change:
` h ` #
` ` ` #
` h ` #
#> # # #
d #
h ` h #
d #
#> # # #
Some comments/suggestions on industry level:Ah, looks like a mistake in the alias definitions. I'll fix that up. Thanks!
The iron/steel meltables has an incorrect setting for weapons.
Steel bars & coke piles also missing no containers.fixed. thanks!
Is it safe mixing cloth & refuse in the same pile? Will it not cause the cloth to rot rapidly or it that only clothing?according to the wiki (https://dwarffortresswiki.org/index.php/DF2014:Refuse), this is safe. The 'refuse' category will only cause accelerated rotting for clothing and armor, not raw cloth (or leather or anything else in that pile).
Stone, metalworkers & corpses piles would benefit greatly from heavy feeders (wheelbarrows) as well as light feeders (no wheelbarrows).I'd had bad experiences with wheelbarrows in the past, but you're right that they can help here. I'll need to design a new feature for setting the wheelbarrow count for specific stockpiles, though, since the interface for setting wheelbarrows depends on whether you have the stockpiles plugin enabled (so I can't just do it in a #query blueprint). I currently just have a global setting for how many wheelbarrows to set by default for all quickfort stone stockpiles, but that's not flexible enough.
Rotating the workshops (making the smelters/forge on the Southside....hey is plan rotation a thing in this version of Quickfort?) would allow building Services level directly underneath but allowing for magma in the otherwise wasted space (I pretty much always bring the magma where I want it, by minecart if need be...building on the magma sea is one of the worst pieces of advice given to noobs, building near the flux/coal/iron/sand is much more efficient)Good idea. I'll do this (and blueprint rotation is on my backlog (https://docs.google.com/document/d/17EjZlGsUOJ6E8WtqkCRZi9BBKjL9L1IdHfkB3Ajqas8/edit#heading=h.xk2hv04zs6ea))
Other:Yeah, the slow safety of the surface level has been irking me for quite some time. I believe I can split it up as you describe without adding any extra steps. I can split the building up into smaller blueprints and simply chain them together in the #meta blueprints. buildingplan will match items for buildings in the order that they were planned, so I can still plan large constructions but have them be built in a more sensible order.
The surface fort takes forever to get going. Some more granular separation would make it easier to get some minimal security faster. I'm thinking separate flooring to prioritize the exposed farming level as well as maybe walls around stairwell. Some kind of marksdorf shooting gallery would be nice too (although the massed cage traps really don't need much help and are hard to beat). Haven't gotten around to doing it myself.
Temp office for bookkeeper on other side of farming level.Good idea -- I have always made a single dorf be both my manager and my bookkeeper, but it makes sense to be more flexible.
Services. Why such lavish jail cells? And why no walls between them? (longstanding habit: I don't appoint a sheriff so I'm ignorant about the finer points of jails)we build lavish jail cells to keep criminals happy of course : ) It was my attempt to follow [some of the] advice on the wiki (https://dwarffortresswiki.org/index.php/DF2014:Jail). I'm open to suggestions, though.
Not crazy about the cisterns, although with the new shitty aquifers maybe this is more sensible than the large ones I favor.I wanted to make them equally usable for players who fill their wells with a bucket brigade and those who fill them by routing flowing water. How do you think they could be improved?
Same for the baths, the concept is cool but aren't they just going to cause contaminants to be tracked all over?Sigh...the baths have gone through so many design changes and caused so much trouble.. I should just take them out. You're right about the contaminants. There used to be a dwarven shower set up over the baths that would clean the contaminants, but it was just too complex to set up and keep running. It involved a ring mist generator (https://dwarffortresswiki.org/index.php/DF2014:Mist#Ring_generator) powered by a dwarven water reactor (https://dwarffortresswiki.org/index.php/DF2014:Water_wheel#Dwarven_Water_Reactor) and linked by controllable gears. It was awesome, but it added 3 more blueprint application steps to the services level. Moreover, the whole thing would randomly just stop working and need to be reset. When I removed the mist generator components, I forgot that the whole reason it was there was to clean contaminants.
Also seems like a good place for tombs on these levels.I integrated the tombs into the apartment levels, since dorfs like looking at urns so much.
Lye automation order is broken; it's dependent on the soap making order being completed, which can't be done without lye.Sorry, I should add documentation for this. DF has a bug that prevents 'lye-containing items' from being used as a condition. You can *add* the condition, but it disappears when you save and reload, breaking the manager order that it was attached to. In the dreamfort automation orders, I have it set up so that soap making triggers lye making so lye exists for the *next* bar of soap, but you have to "prime the system" by manually making a few buckets of lye first.
Also shouldn't the regular meltables exclude iron & steel or was it mutually exclusive to set?The lower meltables stockpile is a superset of the upper, iron/steel-specific one. There are just two meltable stockpiles since dorfs prioritize melting the closest items, so this is how I have them prioritize melting iron and steel items. I didn't see any reason to exclude iron and steel from the lower stockpile -- if you have a lot of garbage iron and steel, you probably want to melt it all first anyway.
I just realized you don't have furniture going anywhere either. Is this intentional?Thank you for catching that. Fixed. Furniture was intended to be included in the "goods" quantum stockpile. I didn't notice while playtesting since quickfort orders creates exactly the amount of furniture that I needed and I never had any to stockpile : P
And we made it to caravan unloading again and instacrashugh, could you possibly try a run without zones? I could prepare a version of dreamfort that skips them.
I like the idea. Currently, each level has stairs included, but I won't be able to do that with ramps since now each level can have either one of two possible ramp placements. I can change the stair_guide (https://docs.google.com/spreadsheets/d/1vlxOuDOTsjsZ5W45Ri1kJKgp3waFo8r505LfZVg5wkU/edit#gid=1058843185) to run the ramp down 10 levels or so, and make that blueprint unhidden so it can be manually run repeatedly to extend the ramps down further as needed. Probably also want to rename it from 'stair_guide' to 'central_ramp'. Overall, this increases complexity for people who are trying to use dreamfort, but results in a better/safer fortress and exemplifies best practices. I'm very wary about making the blueprints any more difficult to apply, but in this case it's probably a good trade-off.Yeah, it is easy to FUBAR an embark with bad ramp placement. Since I've been doing ramps & quickfort a long time, what I generally do is designate my central ramp for the entire map first thing. Removing stairwells from level blueprints is of course critical to this. If I'm using a larger (I'm a fan of 3 wide so depot can go anywhere I want it) ramp then I will set it to mark only at a reasonable depth, but otherwise I find it useful to get a general idea of the map by digging until you hit an impasse, especially if not using reveal & prospect. I'm a fan of underground pasture too, so getting cavern breached for fungus ASAP is usually important. LOL, I'm a fan of underground in general, I usually even let everyone go cave-adapted. The killzone PeridexisErrant designed (https://df-walkthrough.readthedocs.io/en/latest/chapters/chap09-end.html#chapter09) has been pretty effective for my playstyle. I do like the idea of having a large surface fort for future-proofing though. It just needs to be able to be secured faster.
I'd had bad experiences with wheelbarrows in the past, but you're right that they can help here. I'll need to design a new feature for setting the wheelbarrow count for specific stockpiles, though, since the interface for setting wheelbarrows depends on whether you have the stockpiles plugin enabled (so I can't just do it in a #query blueprint). I currently just have a global setting for how many wheelbarrows to set by default for all quickfort stone stockpiles, but that's not flexible enough.The big thing with wheelbarrows is getting the stockpile settings right, but I never go without them. I've also never found the need to go past 3 per pile, so my designs are vanilla safe. I use "heavy feeders" in a 2x3 for stone and some (large & heavy) furniture. Coupled with 12 tile light receivers. Granted I also tend to be overly granular (AR?) with my stockpiles & workshop links. What I wound up doing with the Dreamfort was making the relevant feeders heavy and then I fit a 12 tile light around them. Also cut a 2x3 chunk out of large trash pile for corpses. Nothing worse than trying to haul some dead megabeast corpse up from the caverns without a wheelbarrow. Oh, you probably want to add sandbags to your metal feeder (furniture, forbid all types but sandbags at bottom, leave the rest).
we build lavish jail cells to keep criminals happy of course : ) It was my attempt to follow [some of the] advice on the wiki (https://dwarffortresswiki.org/index.php/DF2014:Jail). I'm open to suggestions, though.Having no experience with jails I'm clueless.
I could totally add walls. At one point I had a library planned out behind the jail cells and I was starved for space, but now that libraries have moved to the (relatively new) guildhall level, there's no reason why we can't make the jail cells more "celly".
I wanted to make them equally usable for players who fill their wells with a bucket brigade and those who fill them by routing flowing water. How do you think they could be improved?
Sigh...the baths have gone through so many design changes and caused so much trouble.. I should just take them out. You're right about the contaminants. There used to be a dwarven shower set up over the baths that would clean the contaminants, but it was just too complex to set up and keep running. It involved a ring mist generator (https://dwarffortresswiki.org/index.php/DF2014:Mist#Ring_generator) powered by a dwarven water reactor (https://dwarffortresswiki.org/index.php/DF2014:Water_wheel#Dwarven_Water_Reactor) and linked by controllable gears. It was awesome, but it added 3 more blueprint application steps to the services level. Moreover, the whole thing would randomly just stop working and need to be reset. When I removed the mist generator components, I forgot that the whole reason it was there was to clean contaminants.
On the plus side, removing the baths also gets rid of the most difficult manual step in all of dreamfort -- filling them up with water to exactly 3/7 depth.
I integrated the tombs into the apartment levels, since dorfs like looking at urns so much.
Sorry, I should add documentation for this. DF has a bug that prevents 'lye-containing items' from being used as a condition. You can *add* the condition, but it disappears when you save and reload, breaking the manager order that it was attached to. In the dreamfort automation orders, I have it set up so that soap making triggers lye making so lye exists for the *next* bar of soap, but you have to "prime the system" by manually making a few buckets of lye first.
The lower meltables stockpile is a superset of the upper, iron/steel-specific one. There are just two meltable stockpiles since dorfs prioritize melting the closest items, so this is how I have them prioritize melting iron and steel items. I didn't see any reason to exclude iron and steel from the lower stockpile -- if you have a lot of garbage iron and steel, you probably want to melt it all first anyway.
ugh, could you possibly try a run without zones? I could prepare a version of dreamfort that skips them.
You mean without having quickfort place the zones or without them altogether? I can modify the plans easy enough. Already been slowly customizing. If you mean play without zones altogether I don't really see how. I went and commented them out, along with the cut trees and gather plants (which I heavily suspect at the moment)Right - without having quickfort place the zones. Try a game manually placing them instead, and see if that stops the crashes. What's your operating system?
ironweapons: {metalweapons}{forbidmetalweapons}{permitironweapons}
copperweapons: {metalweapons}{forbidmetalweapons}{permitcopperweapons}
steelweapons: {metalweapons}{forbidmetalweapons}{permitsteelweapons}
You mean without having quickfort place the zones or without them altogether? I can modify the plans easy enough. Already been slowly customizing. If you mean play without zones altogether I don't really see how. I went and commented them out, along with the cut trees and gather plants (which I heavily suspect at the moment)Right - without having quickfort place the zones. Try a game manually placing them instead, and see if that stops the crashes. What's your operating system?
btw, to fix the bad config for the iron/steel meltables, you can add this to your aliases.txt file:Code: [Select]ironweapons: {metalweapons}{forbidmetalweapons}{permitironweapons}
copperweapons: {metalweapons}{forbidmetalweapons}{permitcopperweapons}
steelweapons: {metalweapons}{forbidmetalweapons}{permitsteelweapons}
Bah. after removing the baths on the services level, there is no longer enough room for magma, so I swapped the clothier and metalworker sections back to their original locations. I'll add a note to the walkthrough to suggest leaving an empty level underneath industry for magma purposes.
Bah. after removing the baths on the services level, there is no longer enough room for magma, so I swapped the clothier and metalworker sections back to their original locations. I'll add a note to the walkthrough to suggest leaving an empty level underneath industry for magma purposes.
Bah. after removing the baths on the services level, there is no longer enough room for magma, so I swapped the clothier and metalworker sections back to their original locations. I'll add a note to the walkthrough to suggest leaving an empty level underneath industry for magma purposes.
What about the necessary holes that need to be channeled for the magma workshops?
Oh, I looked on your google Myk, just make the corridors to hospital and tavern 2 blocks longer each, magma will fit in 11 blocks wide.fair enough. done. This let me reorganize the jail cells into a nicer pattern as well.
Voila!
If you leave the stairs out of level plans, it makes it much easier for me to update mine if I don't have to rip them out of every level ;)will do.
If you're thinking about early time spent mining exploratory stairs, then this is as good a time as any to introduce noobs to our good friend "Marker Only"I went back and forth on marker mode. I eventually decided against it for the reason you allude to -- newbies aren't familiar with it and it could frustrate them. Instead I went with dig priorities on the stair guide so miners would only dig down once there is nothing else to dig on the upper levels.
Piles working fine with new alias. More thought about them, I'd combine steel and bronze instead of iron, since if I can't make steel (perish the thought!) then I'm probably making my gear from bronze, not iron.so, upper meltables: steel and bronze, lower meltables: all metals other than steel and bronze?
So we made it almost until the end of the first season and then we crashed.This crashiness worries me. I've been through dreamfort dozens of times, and the only times I've gotten DF to crash are when I've recompiled DFHack and reinstalled it while the game is running. If this is a problem with quickfort (or with the DFHack library functions it calls), it's going to be hard to track it down. I'll try to reproduce it while playtesting the new dreamfort changes.
I was in the middle of using planning mode to build the ashery (because some workpile decided to snatch my barrel).barrel snatching stockpiles are the *worst*. I try to build industry before farming for that reason.
Industry2 gets a lot of job cancellations in general (lost or missing). I was trying to pre-empt by cancelling and designating normal builds. Actually I am getting the same lost/missing BS with regular jobs just as much. This feels like the worst version of DF ever.even with buildingplan enabled, you're still getting job cancellations? that's what buildingplan is supposed to prevent..
Awesome! Thanks!Oh, I looked on your google Myk, just make the corridors to hospital and tavern 2 blocks longer each, magma will fit in 11 blocks wide.fair enough. done. This let me reorganize the jail cells into a nicer pattern as well.
Voila!QuoteIf you leave the stairs out of level plans, it makes it much easier for me to update mine if I don't have to rip them out of every level ;)will do.
so, upper meltables: steel and bronze, lower meltables: all metals other than steel and bronze?That's what I went with. Iron is still better than bronze but I don't think I've ever not had flux and had iron, but I have had flux and no iron. If I didn't have iron on the map I would be recycling it from goblinite in all liklihood.
This crashiness worries me. I've been through dreamfort dozens of times, and the only times I've gotten DF to crash are when I've recompiled DFHack and reinstalled it while the game is running. If this is a problem with quickfort (or with the DFHack library functions it calls), it's going to be hard to track it down. I'll try to reproduce it while playtesting the new dreamfort changes.Yeah, it's been a nightmare. I have generated at least 7 worlds with 47.04 now and all have suffered the same fate. I haven't crashed again since reload with this one, mid-June, got first migrant wave, still going strong. I have plant gathering set on the surface zones, although hating it...the miners would rather pick fruit than mine even. I still suspect the plant gathering.
I've complained about that in the past. I see it still isn't fixed (I don't give a fuck what Mr "I don't play fortressmode" Toady says, I consider it an undesirable feature). Once again something from the old Quickfort; the small booze piles on every level. Worked great except each tied up an extra barrel. Somehow between the food and the booze pile on the surface 1 of them decided they needed an extra barrel. I think I made a really good case about why this was a worse issue than whatever it potentially was useful for but was shot down, and I let it go.QuoteI was in the middle of using planning mode to build the ashery (because some workpile decided to snatch my barrel).barrel snatching stockpiles are the *worst*. I try to build industry before farming for that reason.
on another note, buildingplan is the other potential source of crashes. I essentially rewrote the entire plugin for this release so it could support all the building types. It is *possible* that I have a bug somewhere in there. If only I could reproduce the crash, then I could run df in a debugger and get the stack trace.QuoteIndustry2 gets a lot of job cancellations in general (lost or missing). I was trying to pre-empt by cancelling and designating normal builds. Actually I am getting the same lost/missing BS with regular jobs just as much. This feels like the worst version of DF ever.even with buildingplan enabled, you're still getting job cancellations? that's what buildingplan is supposed to prevent..
just to clarify, quickfort uses buildingplan to build buildings regardless of whether "planning mode" is enabled for that building type. As long as the buildingplan plugin itself is enabled, quickfort will use it.
that sounds like the upper meltables should be steel, iron, and bronze then, no?so, upper meltables: steel and bronze, lower meltables: all metals other than steel and bronze?That's what I went with. Iron is still better than bronze but I don't think I've ever not had flux and had iron, but I have had flux and no iron. If I didn't have iron on the map I would be recycling it from goblinite in all liklihood.
I wish I could isolate it down to something repeatable. Other than the caravan crashes nothing is reproduceable. https://dffd.bay12games.com/file.php?id=15384 is a save that will crash reliably shortly after unpause. It's been verified on Linux as well.Thanks for that save. It's crashing due to stack overflow in the DF binary -- infinite recursion. I'm getting more suspicious of the "I'm my own grandparent" behavior that DFHack has with created zones. (see the bug (https://github.com/DFHack/dfhack/issues/1758#issuecomment-766181035) for more details)
Just took a peak at the latest, I think I'd push the cells up even further (even with the tavern rooms) and then maybe put a barracks for the city guard in between the cells and the stairs.I had intended the barracks to be built in the empty room across from the trade depot on the surface. Do we need another one down on the services level?
that sounds like the upper meltables should be steel, iron, and bronze then, no?so, upper meltables: steel and bronze, lower meltables: all metals other than steel and bronze?That's what I went with. Iron is still better than bronze but I don't think I've ever not had flux and had iron, but I have had flux and no iron. If I didn't have iron on the map I would be recycling it from goblinite in all liklihood.QuoteI wish I could isolate it down to something repeatable. Other than the caravan crashes nothing is reproduceable. https://dffd.bay12games.com/file.php?id=15384 is a save that will crash reliably shortly after unpause. It's been verified on Linux as well.Thanks for that save. It's crashing due to stack overflow in the DF binary -- infinite recursion. I'm getting more suspicious of the "I'm my own grandparent" behavior that DFHack has with created zones. (see the bug (https://github.com/DFHack/dfhack/issues/1758#issuecomment-766181035) for more details)QuoteJust took a peak at the latest, I think I'd push the cells up even further (even with the tavern rooms) and then maybe put a barracks for the city guard in between the cells and the stairs.I had intended the barracks to be built in the empty room across from the trade depot on the surface. Do we need another one down on the services level?
Well I had my discussion with the liason and am actually conducting a trade, no crash.I just verified this with the save you posted. Removing all zones before the merchants unload avoids the crash.
So I guess it was the zones. I'm glad I popped in this thread, the zones were the last thing I thought it might be.
I'm wondering now if I delete them from some of the other saves if they will stabilize.
Well I had my discussion with the liason and am actually conducting a trade, no crash.I just verified this with the save you posted. Removing all zones before the merchants unload avoids the crash.
So I guess it was the zones. I'm glad I popped in this thread, the zones were the last thing I thought it might be.
I'm wondering now if I delete them from some of the other saves if they will stabilize.
pull request with the fix: https://github.com/DFHack/dfhack/pull/1759
Thank you very much for finding this and helping me debug it!
Oh! You did go with my ramp :DYeah -- I haven't tested all these changes yet, but unless it causes unforeseen problems, I'm totally open to keeping it.
Add another channel/floor over farmers workshop (the rotten cheese incident).done
I like the smaller refuse pile, although still say corpses need wheelbarrows. I can make it work in that space though, so I can deal if you are deadset against it.not set against it at all, I just need to write the feature that will allow setting of wheelbarrow counts per stockpile, probably in the #place blueprint. the default for quickfort is 0 wheelbarrows, and I need to be able to set the wheelbarrow count regardless of whether the interface expects "www" or "w3{Enter}"
Some more work order stuff:I had reserved the tallow for soapmaking purposes since it's low value and eating it doesn't make dorfs happy. I'll work your suggestions in. Thanks!
Dwarven peanut butter (rock nut paste & oil, soap). I think I use the tallow for cooking instead of making soap, although I guess one could do both.
I'm guessing the auto-tailor works?Yeah, I've been happy with it in my long-running fortresses. It significantly reduced the complexity of the manager orders.
Also leather armor/shields? Meh! I never use leather armor. Since marksdorfs like to melee more than they should, I give them the same armor, also steel xbows. It also protects them from elite goblin archers sniping them through fortifications (It has happened to me more than I like). I do make leather gloves, hoods, shoes for civilian wear.I'd like to keep those in to cover players who use the "defaults". The orders only keep one in stock at a time so it's not too much waste for those who don't use them.
Oh, as far as the job cancellations, I did come across a note somewhere about job cancellations being caused by item scatter (from deconstructing workshops), highly likely I had some of that going on since I start removing the surface workstations before industry2 is done.that's very likely. I've run into the same thing when I disassemble the starter workshops on the surface. I call it out in the surface walkthrough (https://docs.google.com/spreadsheets/d/1vlxOuDOTsjsZ5W45Ri1kJKgp3waFo8r505LfZVg5wkU/edit#gid=1864520676), but it's a real annoyance.
Oh! You did go with my ramp :DYeah -- I haven't tested all these changes yet, but unless it causes unforeseen problems, I'm totally open to keeping it.
QuoteI'd like to keep those in to cover players who use the "defaults". The orders only keep one in stock at a time so it's not too much waste for those who don't use them.
Also leather armor/shields? Meh! I never use leather armor. Since marksdorfs like to melee more than they should, I give them the same armor, also steel xbows. It also protects them from elite goblin archers sniping them through fortifications (It has happened to me more than I like). I do make leather gloves, hoods, shoes for civilian wear.
#>
h d
` ` `
d h `
#>
#> # #
h d
`
d h
#> # #
d
h ` h
d
#> # #
bronzeweapons: {metalweapons}{forbidmetalweapons}{permitbronzeweapons}
forbidbronzeweapons: {weaponsprefix}{Right}{Down 2}{Right}{Down 6}&^
permitbronzeweapons: {forbidbronzeweapons}
bronzearmor: {metalarmor}{forbidmetalarmor}{permitbronzearmor}
forbidbronzearmor: {armorprefix}{Right}{Down 6}{Right}{Down 6}&^
permitbronzearmor: {forbidbronzearmor}
awesome -- I'm in the middle of rejiggering the surface level, but it should still work. surface3 is commented out at the moment, but the blueprints that were in there have been moved to surface2, so it should be fine. I haven't tested our changes yet, so keep an eye out for blueprint bugs.
What do you think of this design for the surface level? https://docs.google.com/spreadsheets/d/1vlxOuDOTsjsZ5W45Ri1kJKgp3waFo8r505LfZVg5wkU/edit#gid=232787567
compact enough?
It would make sense to share my embark too I guess. It's a variation off ye venerable craftlords & all it's variants.
It would make sense to share my embark too I guess. It's a variation off ye venerable craftlords & all it's variants.
Oh wow, is Craftlords venerable now? I feel honored! And old!
Have you seen the current "Annotated" version where I explain the design choices? (https://pastebin.com/2xNtgiqS)
I'm waiting for the next release to update it.
I tested the new layout and ironed out the obvious bugs, but I got distracted: since you've been seeing crashes, I've been running DF in a debugger while I playtested the new layouts, and I finally got it to crash. With lethosor's help, I think I tracked down the reason (https://github.com/DFHack/dfhack/issues/1762). It shouldn't be too hard to fix, but it might take me a few days to write and test the code. Once it's merged, you could pick up a dev build and overwrite your LNP version. Fewer crashes might be better for your psyche : )
I like how compact everything is now - it really makes it easier to get settled.
Btw, the new trade goods quantum needs a new alias: crafts. I'll post the definition when I get back to my computer (on phone).
If you're updating the automation orders in your fort, could you export the json and upload it somewhere (or post it here)? If you are already expanding the orders and updating the conditions, I'd hate to just be duplicating your work.
crafts: {finishedgoodsprefix}{Right}f{Right}{Down 9}{togglesequence 9}^
forbidcrafts: {finishedgoodsprefix}{Right 2}{Down 9}{togglesequence 9}^
permitcrafts: {forbidcrafts}
bronzeweapons: {metalweapons}{forbidmetalweapons}{permitbronzeweapons}
forbidbronzeweapons: {weaponsprefix}{Right}{Down 2}{Right}{Down 6}&^
permitbronzeweapons: {forbidbronzeweapons}
bronzearmor: {metalarmor}{forbidmetalarmor}{permitbronzearmor}
forbidbronzearmor: {armorprefix}{Right}{Down 6}{Right}{Down 6}&^
permitbronzearmor: {forbidbronzearmor}
tallow: {foodprefix}b{Right}{Down 13}{Right}stallow&p^
forbidtallow: {foodprefix}{Right}{Down 13}{Right}stallow&f^
permittallow: {foodprefix}{Right}{Down 13}{Right}stallow&p^
TODO:I think you should go ahead and add the piles, it's easy enough to manually add wheelbarrows until you get the code for them, but would save a lot of trouble. Cut the current feeder to 6 tiles. Make a 12 tile feeder for gems (build a 4x5 around the other piles, works out to 12 useable). Remove gems from stone. Metal just keeps the stones, everything else goes to the light feeder. Split the current trash feeder into 2 2x3. Corpses (both types) go into the lower pile, the refuse stays in the top. Add the 3 new piles to the hauling routes. Done. Even without the wheelbarrows it won't make anything any worse (other than the potential for more concurrent hauling jobs, which situationally can be good or bad).
- Heavy feeder stockpiles for corpses, boulders, and ores. this includes designing and implementing a mechanism for blueprints to specify (at stockpile creation time) how many wheelbarrows a particular stockpile should have
Notes:Yeah unfortunately. There's a few things in workorders I wish Toady would fix. Milkable animals another condition that doesn't work, I tried adding it to the autogenerated milking order. Material exclusions another thing I wish for (use any wood other than willow, any stone other than jet, specific plants, etc). Still it has come a long way.
- From your reports, it seems that the current lye-soap order chain is the best we can do (for now). is that right?
Oh that would be awesome. Would save me a lot of trouble. I run them frequently.
- It wouldn't be too difficult to extend combine-plants and combine-drinks to iterate over all stockpiles and automatically combine stockpiles that have the appropriate item types enabled. I suggest filing a feature request bug
That's awesome too. Was going to ask if there was any way to do that. Do I leave it open instead of "k-menu"?
- If you want walls/floors built out of a particular material, you can set the filter in buildingplan and quickfort will use it. for example, to set walls to be made out of quartzite: bCwPM{Right}quartizite{Enter}{Shift}{Enter}. you just have to set the filter before you run the quickfort blueprint.
Yeah, I realized that at some point after I mentioned it. Makes perfect sense.
- I forbid tallow in the cookables pile since it's enabled in the 'goods' quantum on the industry level (for use in soap). the kitchen will still use it, but with it stored so far away, all the higher-quality cookables will be used first.
That's a very discretionary item. Eventually I like to trade away EVERYTHING less than masterwork, other than most metal goods (higher than 33% return on melting). Obviously one cannot start out that way. My first caravan trade usually consists of 20-30 spiked wooden balls (which is pretty much enough to buy out the caravan, even giving them insane profit; happy carvan master==larger immigrant waves). As I said on another strategy-crafting thread once, DF trade is not like RL trade. It isn't to make a profit, it is to get rid of unwanted shit.
- Right now I only enable crafts in the trade depot QSP. are there any other item types we should add here?
If you've got something elaborate (or even just something cool), maybe with minecart tracks? (I'd love to see someone actually do something with them). I normally use reveal to find a patch of whatever I want and then just designate a large block/the entire vein as needed.
- I normally dig a quarry below the apartment levels for more stone for the masons. would this be useful to add to the blueprint set?
I actually caught a couple keas in them so I am now a big fan.
- The traps outside the main gate aren't very useful for sieges (since you can't protect them with bridges to reset them during the siege), but they're great capturing wildlife that are pathing past your fort in peacetime. I found they are excellent for harvesting wild meat.
Found that out the hard way lol.
- Barracks on the surface is in it's own stage, true, but the roof needs to be completed first, otherwise we can't place the beds (need to be "indoors"). When I split the roof construction, though, I can make sure the beds tiles are covered in an early stage
I can break anything. I am the reason error-trapping is a thing. ;)
- Re: I unsuspended jobs that didnt have materials ready for them -- yeah, this is buildingplan's bane. It's on my backlog to see if I can prevent buidlingplan-managed buildings from being manually unsuspended from the jobs list. They're already protected when querying the building itself, but, as you found, there are other ways to unsuspend.
I think you are right. For ease of designation it is fine to leave them. The few extra tiles probably doesn't make much difference (only for heavy things like stone does it really matter). I tend to get all granular with the piles, but even the master himself(https://www.reddit.com/r/MechGuides/) only uses 5 piles. I'm not sure the way I do them is worth the extra work, but workflow wasn't a thing back when I originally started using QSP.
- Sandbags in metal QSP - I'm having second thoughts about this one. I'm worried splitting furniture across two stockpiles will cause confusion. the current furniture QSP is really not that far away -- just 12 tiles (true, the metalworker QSP is only 4 tiles away, but is the increased efficiency for making glass worth the added complexity?)
New aliases needed in your aliases.txt:Ahhh, thanks for that!
(until the next DFHack release, when they'll be in the standard alias library)
[/list]Code: [Select]crafts: {finishedgoodsprefix}{Right}f{Right}{Down 9}{togglesequence 9}^
forbidcrafts: {finishedgoodsprefix}{Right 2}{Down 9}{togglesequence 9}^
permitcrafts: {forbidcrafts}
bronzeweapons: {metalweapons}{forbidmetalweapons}{permitbronzeweapons}
forbidbronzeweapons: {weaponsprefix}{Right}{Down 2}{Right}{Down 6}&^
permitbronzeweapons: {forbidbronzeweapons}
bronzearmor: {metalarmor}{forbidmetalarmor}{permitbronzearmor}
forbidbronzearmor: {armorprefix}{Right}{Down 6}{Right}{Down 6}&^
permitbronzearmor: {forbidbronzearmor}
I went through the automation orders. I saw a few repeats of Lye and soap, I think left over from the experiments. I kept only the original lye and soap from tallow, removing the soap from oil (which I saw had a bad condition -- the one forgotten when a game is reloaded).
You added steel breastplates and greaves. I had left those out since mail shirts and leggings are superior and cover the same body parts (or so I understand). Do we need breastplates and greaves as well?
Uploaded integrated/clean/categorized/alphabetized version here (https://drive.google.com/file/d/17WcN5mK-rnADOm2B_JFpPnByYgkYjxhb/view?usp=sharing)
Can you chain the orders? Like I will queue them all up, but like I will make surface6 jobs trigger when 5 is done, 5 when 4 is done, etc.That's on my backlog, but it will take quite a bit of time to design and implement. I have some ideas on how to do this, but don't expect it any time soon : )
It's true that constructed walls have a walkable top, but at the time that part of the roof is constructed, the walls below haven't been built yet. However, you make a good point about moving the roof access back into the pasture. Previously, the pasture staircase was temporary, just there so we could build the minimal roof over the central ramp. I deconstructed it in a later blueprint to clean it up, but it wasn't always getting deconstructed in time and it was interfering with the final roof. However, if we just make it permanent and stick a hatch on it, it solves that problem. I'll move that back. Thanks!
Add the needed walls instead of floors that need to be removed later?Fair point : ) I'll keep that in mind if it comes back up in later design changes.
Add the needed walls instead of floors that need to be removed later?Fair point : ) I'll keep that in mind if it comes back up in later design changes.
I'm really happy with how dreamfort has changed over the last week! There are still improvements to be made, but I just found out that DFHack 0.47.04-r5 is going to be released soon and I want to get dreamfort playtested, documented, and merged ASAP. We can always make further changes that will come out with DFHack 0.47.05. Updates to the automation orders can be done anytime, since they're just hosted on Google Drive and not part of the DFHack release.
The crash fixes have been merged into the main codebase. If you're willing to, could you possibly install the latest "unstable automated build" from https://dfhack.org/builds/ and give dreamfort one more run through? You still need the aliases in your dfhack-config/quickfort/aliases.txt (the recent alias fixes haven't been merged yet (https://github.com/DFHack/dfhack/pull/1760)), but you no longer need to fiddle with the zones or the stockflow plugin.
I've been refining the command checklist (https://docs.google.com/spreadsheets/d/13PVZ2h3Mm3x_G1OXQvwKd7oIR2lK4A1Ahf6Om1kFigw/edit#gid=1459509569), tweaking the high-level build order and adding guidance comments to the checklist items. I'd appreciate your thoughts on that as well.
I've also been putting together embark profile suggestions (https://docs.google.com/spreadsheets/d/13PVZ2h3Mm3x_G1OXQvwKd7oIR2lK4A1Ahf6Om1kFigw/edit#gid=149144025), and you might have some thoughts on how effective those suggestions are.
Ah, it looks like DFHack 0.47.04-r5 was just released (http://www.bay12forums.com/smf/index.php?topic=164123.msg8242609#msg8242609). This is good. The crash bugs needed to be fixed. The dreamfort updates (https://github.com/DFHack/dfhack/pull/1766) didn't make it in, but that just gives us a little more time to test and refine. DFHack 0.47.05 will be out soon, and we'll catch that train.
No need for you to grab a dev build, then, you can just use the official release (https://github.com/DFHack/dfhack/releases/tag/0.47.04-r5). I *think* this will clear up all the errors and stockpile configuration inconsistencies you were seeing. Remember to clear your aliases.txt file so the updated library aliases are used.
You can get an updated unified dreamfort.csv file from the PR (https://github.com/DFHack/dfhack/pull/1766/files). Click on the three dots to the right of "data/blueprints/library/dreamfort.csv", select "View file". Then select 'raw', then r-click and save as dreamfort.csv. Overwrite the dreamfort.csv in your blueprints/library folder in your DF installation.
masterworkonly: {prefix}{Right}{Up 2}f{Right}{Up 2}&^
artifactonly: {prefix}{Right}{Up 2}f{Right}{Up}&^
togglemasterwork: {prefix}{Right}{Up 2}{Right}{Up 2}&^
toggleartifact: {prefix}{Right}{Up 2}{Right}{Up}&^
masterworkfurniture: {masterworkonly prefix={furnitureprefix}}
artifactfurniture: {artifactonly prefix={furnitureprefix}}
forbidmasterworkfurniture: {togglemasterwork prefix={furnitureprefix}}
forbidartifactfurniture: {toggleartifact prefix={furnitureprefix}}
permitmasterworkfurniture: {togglemasterwork prefix={furnitureprefix}}
permitartifactfurniture: {toggleartifact prefix={furnitureprefix}}
masterworkammo: {masterworkonly prefix={ammoprefix}}
artifactammo: {artifactonly prefix={ammoprefix}}
forbidmasterworkammo: {togglemasterwork prefix={ammoprefix}}
forbidartifactammo: {toggleartifact prefix={ammoprefix}}
permitmasterworkammo: {togglemasterwork prefix={ammoprefix}}
permitartifactammo: {toggleartifact prefix={ammoprefix}}
masterworkfinishedgoods: {masterworkonly prefix={finishedgoodsprefix}}
artifactfinishedgoods: {artifactonly prefix={finishedgoodsprefix}}
forbidmasterworkfinishedgoods: {togglemasterwork prefix={finishedgoodsprefix}}
forbidartifactfinishedgoods: {toggleartifact prefix={finishedgoodsprefix}}
permitmasterworkfinishedgoods: {togglemasterwork prefix={finishedgoodsprefix}}
permitartifactfinishedgoods: {toggleartifact prefix={finishedgoodsprefix}}
masterworkweapons: {masterworkonly prefix={weaponsprefix}}
artifactweapons: {artifactonly prefix={weaponsprefix}}
forbidmasterworkweapons: {togglemasterwork prefix={weaponsprefix}}
forbidartifactweapons: {toggleartifact prefix={weaponsprefix}}
permitmasterworkweapons: {togglemasterwork prefix={weaponsprefix}}
permitartifactweapons: {toggleartifact prefix={weaponsprefix}}
masterworkarmor: {masterworkonly prefix={armorprefix}}
artifactarmor: {artifactonly prefix={armorprefix}}
forbidmasterworkarmor: {togglemasterwork prefix={armorprefix}}
forbidartifactarmor: {toggleartifact prefix={armorprefix}}
permitmasterworkarmor: {togglemasterwork prefix={armorprefix}}
permitartifactarmor: {toggleartifact prefix={armorprefix}}
https://github.com/thurin/df-twbt/releases/ has a 0.47.04-r5 build of TWBT now, by the way.
https://github.com/thurin/df-twbt/releases/ has a 0.47.04-r5 build of TWBT now, by the way.
The surface and services levels have been refined a bit. The important parts should be much faster to set up now. Updated dreamfort.csv in the PR (https://github.com/DFHack/dfhack/pull/1766)
https://github.com/thurin/df-twbt/releases/ has a 0.47.04-r5 build of TWBT now, by the way.
sorry it took me so long ;)
Those changes look great! Thank you so much for taking the time to go through them! I'll update the master copy.
And I found out what is making the farming level blueprint unhappy. It works fine in .csv. Apparently, when reading from an .xlsx, the value is modified to "3.0" by something in the reading stack. I'll get that fixed up.
I didn't add any hospital furniture in /services2 since I didn't want to delay placement of the dining room table that we need for a query anchor. /services3, which builds all the (functional) hospital furniture is run as soon as the table and chair are placed, which shouldn't take more than a game day.
It's a higher priority than the large dining room.Fair enough. done.
I don't think I have ever actually had papyrus before, here's an order to add. I'll get it in tomorrow.Sheets are good, but if we start creating rules for quires or scroll rollers, we need to figure out how to keep them out of the jugs stockpile. or maybe we could turn the jugs stockpile into a tools QSP so we don't have to worry about it.
Ok, let's:
- build the entire barracks in /surface5 (I just need to make a note that the player should check to ensure the little roof segment over the barracks beds has been finished. it's usually the long tail of /surface4)
- move the traps into /surface5 so they can be completed before all the walls/flooring show up
- /surface6 will be the labor-intensive step, but traps, levers, and bridges should be completed before it begins. Walls will get built first, then floors, then roof (thanks to buildingplan remembering the order in which constructions were planned, of course there's always some variation depending on when the "ready" tasks actually get picked up)
- /surface7 will be the extra trap corridor (and corresponding roof extension)
edit: done. playtesting the changes now.
I'm still nervous about that too. Does anyone know if the endless cycle of taking out books and putting them away is fixed?43.04 fix (https://www.bay12games.com/dwarves/mantisbt/view.php?id=9273).
I'm still nervous about that too. Does anyone know if the endless cycle of taking out books and putting them away is fixed?43.04 fix (https://www.bay12games.com/dwarves/mantisbt/view.php?id=9273).
I think just move the roof. Getting the walls done sooner rather than later is important.yeah, after playtesting, I agree. The bridges can get done if you wait to start /surface6 until after /surface5 is completely built (bridges, et. al.), but the roof distracts from finishing the walls. will move.
Updated automation.jsonThanks! I'll update the master.
` ` h7 d6 `
d ` d6 ` u
` d6 h7 ` `
#>
` d6 ` ` `
u h7 d6 h7 d
` ` ` d6 `
#>
...
I've been playtesting dreamfort a few more times, and I keep running an issue where miners channel themselves down through the ramp but haven't dug it out fully so they can't get back up, trapping themselves down below. setting priorities for the ramp to make sure it gets dug in the right order has been partially successful, but miners don't always do it exactly right, especially when there are multiple miners involved.
Currently, I have the dig tiles for the ramp at priority 6 and the channel tiles at priority 7. This, normally, causes the miners to dig out an entire level before, digging the ramp dig tiles and then finally digging the channel tiles (or at least one of them) before starting on the next level down. This normally works fine, but for the services level, the channel tiles for the wells provide an alternate route down to the next level, and the sequence gets messed up. I solved the problem for this particular level by adding a staircase up from the cistern to the main services level. On my latest runthrough, a single dig tile got canceled (dangerous terrain or something random like that) and my miners got stuck on the guildhall level.
Do you see issues like this with your ramps? how do you avoid them?
My initial thought is that we can build in a failsafe. I can build a staircase that goes up each level next to the ramp. Not a single column that would have the same danger as the original central staircase that we replaced with the ramp, but alternating staircases on the left and right of the ramp, like this:Code: [Select]` ` h7 d6 `
d ` d6 ` u
` d6 h7 ` `
#>
` d6 ` ` `
u h7 d6 h7 d
` ` ` d6 `
#>
...
thoughts?
` j7 `
u ` u
` j7 `
#>
` u `
j7 ` j7
` u `
#>
...
I was thinking more about the ramp -- I wouldn't want the side staircase to break the surface, so I was going to modify to handle that, then I got to thinking, why do we need a ramp at all? wouldn't it be both "fall to death safe" and "miner dig self into hole safe" if we just used a spiral staircase?Code: [Select]` j7 `
u ` u
` j7 `
#>
` u `
j7 ` j7
` u `
#>
...
This would allow miners to dig up or down from their current position. Is there any advantage to using a ramp over this design?
yeah, I haven't had much luck with mass pitting in recent versions. In a previous version of dreamfort, I had an automated goblin flinger where hostiles in the animal stockpile would get loaded into a minecart, pushed down a series of impulse ramps, and shot through a fortification, where they would drop, stunned, into the middle of my barracks. Made for lots of well-trained soldiers : ) I took it out of dreamfort, though, since it made the surface that much more complicated to build. I might put it back in someday as an extra, though, once dreamfort "settles down" a bit.
edit: ok, so I just read the ramps vs. stairs (http://www.bay12forums.com/smf/index.php?topic=67523.0) thread and the stairs vs. ramps (http://www.bay12forums.com/smf/index.php?topic=157441.0) thread, but I'm not so sure if ramps have the definitive advantage here.
another suggested approach is a vertical shaft of stairs with hatch covers every few levels.
sp_link: s{move}p{move_back}
sp_links: {sp_link}
quantumstop: ^hrn{name}&sn{stop_name}&&xxx{route_enable enter_sp_config={enter_sp_config_hauling}}{sp_links}^^q
corpses: {refuseprefix}b{Right}{Down}p^
forbidcorpses: {refuseprefix}{Right}{Down}f^
permitcorpses: {refuseprefix}{Right}{Down}p^
Updated to stairs, and no problems seen, so I removed the "escape route" stairway near the jail cells. Continuing to play test to refine the checklist (https://docs.google.com/spreadsheets/d/13PVZ2h3Mm3x_G1OXQvwKd7oIR2lK4A1Ahf6Om1kFigw/edit#gid=1459509569) order. I'm moving the automation import down until after the stairwell is protected on the surface and the hospital has basic functionality. Otherwise the dofs are too distracted to set up defenses on the surface. I'm also playing with the configuration of the starting dwarves to understand how much faster we can go with higher starting skills. Making the miners and masons proficient really seems to make a difference in how quickly we can get the basic fort up and running.
I working on updating (and documenting) the quantum hauling aliases so they can more easily handle multiple input stockpiles, needed for the heavy piles.
edit: Heavy piles done. I kept them small to keep the current footprint -- 3x3 refuse and corpse pile became 2x3 refuse and 1x3 corpse, 3x3 otherstone and gem became 2x3 otherstone and 1x3 gem, etc. We'll see if that's big enough or if we need more. Once my wheelbarrow-setting PR (https://github.com/DFHack/scripts/pull/254) is merged, I'll initialize them each with 2 wheelbarrows. quickfort orders will pick up that config as well and generate orders to build the wheelbarrows as well (this functionality is implemented, but it's built upon several unmerged PRs so I can't start the code review until the current crop of code reviews is done. Given the core team's focus on df-0.47.05, all this might not land until dfhack-0.47.05-r2, but we'll see)
Here is the most recent batch of alias updates:Code: [Select]sp_link: s{move}p{move_back}
sp_links: {sp_link}
quantumstop: ^hrn{name}&sn{stop_name}&&xxx{route_enable enter_sp_config={enter_sp_config_hauling}}{sp_links}^^q
corpses: {refuseprefix}b{Right}{Down}p^
forbidcorpses: {refuseprefix}{Right}{Down}f^
permitcorpses: {refuseprefix}{Right}{Down}p^
and, for the interested, here's the updated documentation for how to use the quantumstop alias (though the docs look better in HTML):Spoiler (click to show/hide)
I'm hacking on the automation orders a little. I've noticed that all my pig tails are getting mashed into slurry, despite the fact that I have a barrel full of the stuff. The order condition doesn't seem to be tracked properly. I might just take out the entire "sheet" chain for now.
I found an inverted condition in the make charcoal -- lignite should be at most 0, not at least 0
I was getting cancellation spam from leather and steel jobs, so I bumped up the thresholds where those jobs start getting enqueued.
I also tweaked the farming level a bit more, moving the dining hall further away from the kitchen. This makes booze less likely to get chosen as an ingredient for roasts.
Nice! I'm glad it found a new owner. I sent you a PR, trying to get it to run, though I ran into a missing file. I think it's going to need some work overall.
If anyone would like a sample dreamfort (https://docs.dfhack.org/en/latest/docs/guides/quickfort-library-guide.html#dreamfort) savegame to poke around in (fully built, >200 population), I uploaded one of my recent playthroughs to dffd: https://dffd.bay12games.com/file.php?id=15434
you mean in the DF game? the file is an archive of the region1 directory. you need to extract it in your save folder
Hey, I've learned not to make assumptions when fielding bug reports :-) The save was made with df 0.47.05? Have you upgraded to that version yet? Also, you're sure it didn't get extracted into region1/region1 or something?
[...]
I also wrote up some embark profile suggestions (https://docs.google.com/spreadsheets/d/13PVZ2h3Mm3x_G1OXQvwKd7oIR2lK4A1Ahf6Om1kFigw/edit#gid=149144025) for players looking to optimize their dreamfort experience.
[...]
lua ~df.global.cursor
Yeah, it seems something else is going on here. There might be two separate problems:
1. Whatever dreamfort blueprint you try to run, it always runs the first blueprint (as if you were running quickfort run library/dreamfort.csv -n /help)
2) Other blueprints you try to run think they're outside the map boundary
First things first, could you possibly update to a recent version of DHack? There have been a *lot* of changes to quickfort (and dreamfort) in the past few months, and it will be hard to debug this if we're running different code. You can get a recent development version from the "Build Artifacts" list on this page (https://buildmaster.lubar.me/applications/3/builds/build?buildId=9892). You can just overwrite the similarly-named files in your DF game directory. If you're not already running DF 0.47.05, you'll need to update to that version first.
Also, when you get the report that all tiles are outside the map boundaries, could you run the following command in the DFHack# console and report the result?Code: [Select]lua ~df.global.cursor
[DFHack]# lua ~df.global.cursor
<global.T_cursor: 0x19bfe60>
x = 108
y = 96
z = 129
:~/Applications/linux-dwarf-pack/df_47_05_linux/dfhack-config/orders$ ls
automation.json
:lua ~dfhack.filesystem.getcwd()
print~/Applications/linux-dwarf-pack/df_47_05_linux/
or something else? If something else (other than expanding "~"), then you should be looking in whatever folder it printed for the "dfhack-config" folder to edit. Alternatively, your pack might be setting the working directory incorrectly.Blueprint usabilityAwesome. I was thinking pretty much along the same lines. gui/mass-remove might be useful to reference for some of the UI flow, and there are probably others as well. I hadn't even thought of allowing the start position to be chosen, but that makes sense to me (maybe a default of the top left corner and/or a way to choose presets like the corner/center of a blueprint could be useful?).
This essentially comes down to adding an interactive visual interface. I'm thinking: use the cursor to select the boundaries of the blueprint area (complete with flashing blocks indicating the selected area) and then select the "start" position of the blueprint (where the cursor should be when replaying the blueprint). Other on-screen elements could allow other options to be set before the blueprint is generated.
Finally, I'd like to add a section to the quickfort user guide on how to create blueprints with the blueprint plugin and the bits of syntax you need to know to make finishing touches. A guide for creating blueprints with absolutely minimal effort.Thanks, that'd be great!
Should I re-implement blueprint in Lua? ... Blueprint is currently written as a C++ plugin, but there's nothing about the functionality that requires it to be a plugin instead of a native Lua script."Convential wisdom" is that map-based operations over a large area tend to be noticeably slow in Lua, with an extreme example being "reveal". I think most reasonably-sized blueprints wouldn't be too slow to create from Lua, but you might want to benchmark something dreamfort-sized and be open to implementing bottlenecks in
"Convential wisdom" is that map-based operations over a large area tend to be noticeably slow in Luaahh, ok. thanks! let me run some benchmarks to see what's feasible
Looks like I made a typo in my earlier post - I meant to suggest implementing slow parts of the logic in C++ and the rest in Lua.no worries, I understood what you meant : )
do you have an idea of which operations are slow in Lua (if there are any in particular)?I implemented blueprint dig in a number of ways, trying to determine the performance of different parts. The breakdown was:
A multiple-second slowdown isn't great, but also not likely for users to run into IMO. That said, I don't know for sure if we would want to support larger blueprints/snapshots down the line, so I'm hesitant to migrate pieces to Lua if they would only be migrated back to C++ later.yeah, that's fair. Let me think a bit about what bits of logic would really be useful to have in Lua and come up with an architecture.
... done with the interactive gui (the gui/blueprint script) and the commandline parsing changes to the blueprint plugin. I have some questions on details of the implementation...
Would DFHACK QuickFort be able to blueprint all the 48x48xDeep of the fortress?
How well do they work on 16x16 embarks?What sort of supercomputer do you have to that you can do 16x16 embarks! :o
How well do they work on 16x16 embarks?What sort of supercomputer do you have to that you can do 16x16 embarks! :o
Normally I prefer to play with nano-embarks of 1x1 with 48x48 tiles
quickfort run library/dreamfort.csv -n /guildhall1 and lay down another guildhall level.dig-now
=======
Instantly completes dig designations, modifying map tiles and creating boulders,
ores, and gems as if a miner were doing the mining or engraving. By default, all
dig designations on the map are completed and boulder generation follows
standard game rules, but the behavior is configurable.
Note that no units will get mining or engraving experience for the dug/engraved
tiles.
Currently, trees are not chopped down and any designated trees or roots will be
ignored. Engravings are also not automatically generated by this plugin as they
depend on the skill and creative choices of individual engravers.
Usage::
dig-now [<pos> <pos>] [<options>]
Where the optional ``<pos>`` pair can be used to specify the coordinate bounds
within which ``dig-now`` will operate. If they are not specified, ``dig-now``
will scan the entire map.
Any ``<pos>`` parameters can either be an ``<x>,<y>,<z>`` triple (e.g.
``35,12,150``) or the string ``here``, which means the position of the active
game cursor should be used.
Examples:
``dig-now``
Dig designated tiles according to standard game rules.
``dig-now --clean``
Dig designated tiles, but don't generate any boulders, ores, or gems.
``dig-now --dump here``
Dig tiles and dump all generated boulders, ores, and gems at the tile under
the game cursor.
Options:
:``-c``, ``--clean``:
Don't generate any boulders, ores, or gems. Equivalent to
``--percentages 0,0,0,0``.
:``-d``, ``--dump <pos>``:
Dump any generated items at the specified coordinates. If the tile at those
coordinates is open space or is a wall, items will be generated on the
closest walkable tile below.
:``-e``, ``--everywhere``:
Generate a boulder, ore, or gem for every tile that can produce one.
Equivalent to ``--percentages 100,100,100,100``.
:``-h``, ``--help``:
Show quick usage help text.
:``-p``, ``--percentages <layer>,<vein>,<small cluster>,<deep>``:
Set item generation percentages for each of the tile categories. The
``vein`` category includes both the large oval clusters and the long stringy
mineral veins. Default is ``25,33,100,100``.
:``-z``, ``--cur-zlevel``:
Restricts the bounds to the currently visible z-level.
This is certainly a "cheat" plugin, but I expect it to be useful for players who want to rapidly test quickfort blueprints.Excellent. Just in time for me to begin poking at this for real, instead of in my head.
[DFHack]# quickfort run /library/dreamfort.csv -n /surface1
applying blueprint: "/central_stairs"
applying blueprint: "/surface_clear_small"
applying blueprint: "/surface_zones"
applying blueprint: "/surface_name_zones"
...rtress 0.47.05/hack/scripts/internal/quickfort/query.lua:26: bad argument #1 to 'pairs' (table expected, got nil)
stack traceback:
[C]: in function 'pairs'
...rtress 0.47.05/hack/scripts/internal/quickfort/query.lua:26: in upvalue 'load_aliases'
...rtress 0.47.05/hack/scripts/internal/quickfort/query.lua:99: in field '?'
...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:54: in field 'do_command_internal'
...ortress 0.47.05/hack/scripts/internal/quickfort/meta.lua:52: in upvalue 'do_meta'
...ortress 0.47.05/hack/scripts/internal/quickfort/meta.lua:59: in field '?'
...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:54: in global 'do_command_internal'
...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:120: in function <...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:116>
[C]: in function 'dfhack.call_with_finalizer'
C:\data\PEPack\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:114: in field '?'
...PEPack\Dwarf Fortress 0.47.05/hack/scripts/quickfort.lua:221: in local 'script_code'
C:\data\PEPack\Dwarf Fortress 0.47.05\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
(...tail calls...) {
"amount_left" : 1,
"amount_total" : 1,
"frequency" : "Daily",
"id" : 180,
"is_active" : false,
"is_validated" : false,
"item_conditions" :
[
{
"condition" : "AtLeast",
"flags" :
[
"empty",
"bag"
],
"item_type" : "BOX",
"value" : 2
},
{
"condition" : "AtMost",
"flags" :
[
"sand_bearing"
],
"value" : 6
}
],
"job" : "CollectSand"
}I don't know if you want to add it to the main orders. In theory it should sit quietly until you build a glassworks. Still trying to get the soap cancellation spam to stop, seems like I am constantly ordering extra lye manually, but at least once we get full stock it will stop. I have been adjusting some of the orders to require n+1 of problematic inputs, which seems to help a bit.Hey Myk. The latest tweaks to the Dreamfort design have really helped speed it along, I will be on schedule for the 3rd migrant wave.Awesome! I've been pretty happy with it too. I think we've achieved a good balance of functionality and simplicity.
So far everything is fairly clean and trouble-free.
The new stairwell design doesn't suffer from the job cancellation issues the ramps had. I think the digging priority needs adjustment from 7 to 5 (and leave the 4 at 4) because I have noticed the lower priority tasks aren't just lower than other similar tasks, but all tasks (such as hauling;I don't use designated haulers, everyone hauls when they aren't otherwise busy). 5 will keep them from being dug before any 4s, even ones halfway across the map.Hummmm. I'll need to give this some thought. Lowering the priority of the stairwell tiles will make it trickier to dig the well cisterns on the services level. I might be able to do it with the stairwell at priority 6, but I need priority 5 to force the miners to dig the cistern tiles in the correct order. Otherwise we could end up with messy ramps or undug tiles on the main service level. Would raising the priority of the stair tiles to 6 be enough? An alternative would be to change *all* the default 4 dig tiles to 3 and move everything up a notch. I think that would make the blueprints unacceptably messy, though, and they'd be less useful as the "copyable examples" I'd want them to be.
I found a way to cheat and add empty bag to sand collection (in-game it won't let you) by copy-pasta and importing order:Nice. I'll add it in.
Still trying to get the soap cancellation spam to stop, seems like I am constantly ordering extra lye manually, but at least once we get full stock it will stop.
I have been adjusting some of the orders to require n+1 of problematic inputs, which seems to help a bit.Yeah, I've been playing with that as well. The issue seems to be:
autobutcher target 4 1 1 1 BIRD_TURKEY
autobutcher target 50 50 14 2 BIRD_GOOSE
autobutcher target 2 1 4 2 ALPACA SHEEP LLAMA PIG
autobutcher target 1 1 1 1 CAT
autobutcher target 1 1 0 0 HORSE YAK DONKEY WATER_BUFFALO GOAT
autobutcher target 0 0 0 0 CAVY BIRD_DUCK BIRD_GUINEAFOWL
autobutcher unwatch DOG[
{
"amount_left" : 1,
"amount_total" : 1,
"frequency" : "Daily",
"id" : 84,
"is_active" : false,
"is_validated" : true,
"item_conditions" :
[
{
"condition" : "AtLeast",
"item_type" : "BAR",
"material" : "INORGANIC:PLATINUM",
"value" : 5
},
{
"condition" : "AtLeast",
"item_type" : "BAR",
"material" : "COAL",
"value" : 100
},
{
"condition" : "AtMost",
"item_subtype" : "ITEM_WEAPON_HAMMER_WAR",
"item_type" : "WEAPON",
"material" : "INORGANIC:PLATINUM",
"value" : 10
}
],
"item_subtype" : "ITEM_WEAPON_HAMMER_WAR",
"job" : "MakeWeapon",
"material" : "INORGANIC:PLATINUM"
},
{
"amount_left" : 1,
"amount_total" : 1,
"frequency" : "Daily",
"id" : 86,
"is_active" : false,
"is_validated" : true,
"item_conditions" :
[
{
"condition" : "AtLeast",
"item_type" : "BAR",
"material" : "INORGANIC:PLATINUM",
"value" : 5
},
{
"condition" : "AtLeast",
"item_type" : "BAR",
"material" : "COAL",
"value" : 100
},
{
"condition" : "AtMost",
"item_subtype" : "ITEM_WEAPON_MACE",
"item_type" : "WEAPON",
"material" : "INORGANIC:PLATINUM",
"value" : 10
}
],
"item_subtype" : "ITEM_WEAPON_MACE",
"job" : "MakeWeapon",
"material" : "INORGANIC:PLATINUM"
}
]Muahahahahahaha.Making the best weapons possible with whatever materials are available makes sense, but at this level of sophistication, I'm thinking the orders will be easier to maintain as code rather than as a static JSON file. That way we can tweak values across many orders without having to make lots of manual changes. We can also make some things configurable.
If you make an expanded set of orders in JSON, I could use it as a guide to write some orders generation code. How does that sound?
{
"condition" : "AtLeast",
"value" : 1
}
{
"condition" : "AtLeast",
"flags" :
[
"lye-containing"
],
"value" : 1
}is what I believe the condtion should look like, but importing it throws an error. Nothing else I could think of worked, it didn't throw errors, but it just showed up as 1 blank item.Ok, some progress to report. The build-now script is in pretty good shape. I've tested it fairly thoroughly, though I'm sure there are still corner cases to discover and address.
Now that I have both dig-now (https://github.com/DFHack/dfhack/pull/1853) and build-now (https://github.com/DFHack/scripts/pull/310), I can test dreamfort without any explicit dwarven effort (except for tree cutting, which dig-now doesn't handle yet). As a happy side effect, I can finally get some clean screenshots without force-dumping everything in my fort : )
Behold!Spoiler (click to show/hide)
(by the way, if anyone has a talent for creating readable annotated screenshots, I'd be grateful for something that looks nicer than the images that I cobbled together)
Now to take a closer look at the manager orders for fort automation.
I believe it will only work on DFHack 0.47.05-r2 and newer.
That isn't a DFHack version that exists. Running "help" in the DFHack console will tell you what DFHack version you have. It should also be displayed in the top left corner of the title screen.I believe it will only work on DFHack 0.47.05-r2 and newer.
I'm on r03.
That isn't a DFHack version that exists. Running "help" in the DFHack console will tell you what DFHack version you have. It should also be displayed in the top left corner of the title screen.I believe it will only work on DFHack 0.47.05-r2 and newer.
I'm on r03.
{
"amount_left" : 1,
"amount_total" : 1,
"frequency" : "Daily",
"id" : 546,
"is_active" : true,
"is_validated" : true,
"item_conditions" :
[
{
"condition" : "AtLeast",
"item_type" : "BAR",
"material" : "ASH",
"value" : 2
},
{
"condition" : "AtLeast",
"flags" :
[
"empty"
],
"item_type" : "BUCKET",
"value" : 2
},
{
"condition" : "AtMost",
"item_type" : "LIQUID_MISC",
"material" : "LYE",
"value" : 5
}
],
"job" : "MakeLye"
},Nice. I like where you're taking this. I uploaded a new version of automation.json with tweaked balance. Now all orders produce no more than 1 item (except for charcoal, which is needed by too many other orders to just keep at 1). Orders now also depend on 5 source items being available before they become active. With these changes, I have seen very little cancellation spam.
I'm digging into the issue with dfhack orders not being able to export the "lye-containing" trait. It seems to be stored in an unnamed variable ("anon_3"). When the "lye-containing" trait is there, anon_3 = 24. This is either a bitfield of 16+8 or an enum. I'll have to experiment more to find out which it is.
on-new-fortress autobutcher target 50 50 4 2 BIRD_GOOSE BIRD_PEAFOWL_BLUE BIRD_CHICKEN BIRD_TURKEY). I've never had any issues with seedwatch as far as I know, I've used it for a long time. Pig tails (or any seeds really) can have their own individual thresholds set, but of course there is the ingame max of 200 per (which can be adjusted in the d_init file if necessary). The autobutcher targets are correct but they are being set to unwatched. This https://pastebin.com/rKDggfY6 (https://pastebin.com/rKDggfY6)Thanks! integrated. Could you check the json files here (https://drive.google.com/drive/folders/1lLGgWaoVdgIZ22FNBhkQDWU7NbPL_9WN) to make sure I incorporated your feedback and additions properly (except perhaps for the items discussed below)?
doesn't help that I had to put my old dog down recently either.I've been there. I'm sorry about that.
Autobutcher start should probably not have on-new-fortress?Surprisingly, it's fine. I verified that autobutcher's enabled status gets saved and restored automatically along with the rest of its settings.
autobutcher target 50 50 4 2 BIRD_GOOSE BIRD_PEAFOWL_BLUE BIRD_CHICKEN BIRD_TURKEY
I made my own annotated embark profile for Dreamfort
Oh, or is that one that needs the new plugin?That's the one. "Make mead" as well for the contains [ "honey" ]. PR is here (https://github.com/DFHack/dfhack/pull/1906) if you can build locally.
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.
prioritize -a StoreItemInVehicle PullLever DestroyBuilding RemoveConstructionprioritize ConstructBuildingprioritize -a StoreItemInVehicle PullLever DestroyBuilding RemoveConstruction RecoverWounded FillPond DumpItem SlaughterAnimal
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 (https://github.com/DFHack/scripts/blob/b262fa3672bbff9b9143b2a51e6d9b170939bbeb/prioritize.lua).
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.
quickfort run,orders library/dreamfort.csv -n /suites2
quickfort orders library/dreamfort.csv -n "/surface2, /farming2, /surface3, /farming3, /industry2, /surface4, /services2"
{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.One quick question:
Does quickfort offer a placement mode that works similar to the way workshops are placed (I.e. with X’s, or something, to show where everything would go)?
Uhhh, just noticed cloak is 9 down. Got leather robes added to uniforms. The wierd thing is I swore this was working earlier.ah, so it's not just me. I thought I got it working, but on my next test I got tunics added instead of cloaks. It looks like the list is non-static, which is bad news. I might have to back out that particular uniform change (the others seem to work reliably) until I can figure out a better way to do it.
| Workshop | Labor |
| Ashery | Lye Making |
| Bowyer's workshop | Bowyery |
| Butcher's shop | Butchery |
| Butcher's shop | Small Animal Dissection |
| Carpenter's workshop | Carpentry |
| Clothier's Shop | Clothesmaking |
| Craftdwarf's workshop | Stonecrafting |
| Craftdwarf's workshop | Bone Carving |
| Craftdwarf's workshop | Woodcrafting |
| Craftdwarf's workshop | Strand Extraction |
| Craftdwarf's workshop | Bookbinding |
| Craftdwarf's workshop | Waxworking |
| Dyer's Shop | Dyeing |
| Farm plot | Farming |
| Farmer's workshop | Gelding |
| Farmer's workshop | Plant Processing |
| Farmer's workshop | Milking |
| Farmer's workshop | Cheese Making |
| Farmer's workshop | Spinning |
| Farmer's workshop | Paper Making |
| Farmer's workshop | Shearing |
| Fishery | Fish Cleaning |
| Fishery | Fish Dissection |
| Glass furnace | Glassmaking |
| Jeweler's workshop | Gem cutting |
| Jeweler's workshop | Gem setting |
| Kennel | Trapping |
| Kiln | Pottery |
| Kiln | Glazing |
| Kitchen | Cooking |
| Leather works | Leatherworking |
| Loom | Weaving |
| Mason's workshop | Masonry |
| Mechanic's workshop | Mechanics |
| Metalsmith's forge | Weaponsmithing |
| Metalsmith's forge | Armoring |
| Metalsmith's forge | Blacksmithing |
| Metalsmith's forge | Metalcrafting |
| Quern | Milling |
| Screw press | Pressing |
| Siege workshop | Siege Engineering |
| Smelter | Furnace Operating |
| Soap-maker's workshop | Soaping |
| Still | Brewing |
| Tanner's shop | Tanning |
| Wood furnace | Wood Burning |
| Wood furnace | Potash Making |
| Profession | Workshops | Labors (grouped by workshop) |
| Profession 1 | none | mining |
| Profession 2 | mason | (masonry) |
| Profession 3 | craftdwarf | (stonecrafting) |
| Profession 4 | none | woodcutting |
| Profession 5 | carpenter | (carpentry) |
| Profession | Workshops | Labors (grouped by workshop) |
| Profession 1 | none | mining |
| Profession 2 | mason | (masonry) |
| Profession 3 | craftdwarf | (stonecrafting) |
| Profession 4 | mechanic | woodcutting, (mechanics) |
| Profession 5 | carpenter | (carpentry) |
| Profession 6 | still | farming, (brewing) |
| Profession | Workshops | Labors (grouped by workshop) |
| Profession 1 | none | mining |
| Profession 2 | mason | (masonry) |
| Profession 3 | craftdwarf | (stonecrafting, bone carving, woodcrafting) |
| Profession 4 | mechanic | woodcutting, (mechanics) |
| Profession 5 | carpenter | (carpentry) |
| Profession 6 | still, butcher, tannery, farmer's | farming, (brewing), (butchery), (tanning), (plant processing, spinning, shearing) |
| Profession 7 | kitchen | (cooking) |
| Profession 8 | bowyer, forge | (bowyery), (weaponsmithing, armoring) |
| Profession 9 | clothier, dyer, leather, loom | (clothesmaking), (dyeing), (leatherworking), (weaving) |
| Profession 10 | smelter | (furnace operating) |
| Profession 11 | none | hauling |
| Profession | Workshops | Labors (grouped by workshop) |
| Miner | none | mining, stone detailing |
| Mason | mason | (masonry) |
| Craftsdwarf | craftdwarf, jewler | (stonecrafting, bone carving, woodcrafting, strand extraction, bookbinding, waxworking), (gem cutting, gem setting) |
| Outdoorsdwarf | mechanic, kennel | woodcutting, animal training, plant gathering, beekeeping, gather wounded, (mechanics), (trapping) |
| (subsumed into Craftsdwarf) | carpenter | (carpentry) |
| Farmer | still, butcher, tannery, farmer's, fishery, query, screw press | farming, (brewing), (butchery, small animal dissection), (tanning), (plant processing, spinning, shearing, gelding, milking, cheese making, paper making), (fish cleaning, fish dissection), (milling), (pressing) |
| Chef | kitchen | (cooking) |
| Smith | bowyer, forge, glass, kiln, siege | (bowyery), (weaponsmithing, armoring, blacksmithing, metalcrafting), (glassmaking), (pottery, glazing). (siege engineering) |
| Clothier | clothier, dyer, leather, loom | (clothesmaking), (dyeing), (leatherworking), (weaving) |
| Unskilled | smelter, ashery, soap, wood furnace | (furnace operating), (lye making), (soaping), (wood burning, potash making) |
| Hauler | none | hauling, architecture |
| Doctor | none | animal care, suturing, surgery, setting bones, dressing wounds, diagnosis |
| Fisherdwarf | none | fishing |
You really need to cut down on tanners, it is a special skill because while it has no effect on quality it is a moodable skill. I shudder to imagine 20 legendary tanners running around my fort and all the leather artifacts that could have been good metal weapons or armor. I'd remove it from both farmers and unskilled and probably put it on the clothiers.This is a good idea. I had given it to so many dwarves because it is a time-sensitive task, and the farmers (who originally were the only ones assigned) didn't always process the rawhides before they rotted. The clothiers are usually not so busy that they can't run upstairs to tan hides, and it would fit in well with their skillset. I might change my recommendation from 2 to 3 clothiers to compensate. If I can figure out how to automatically prioritize tanning jobs, I'll drop that recommendation back down to 2.
I imagine at a minimum that you restrict the mechanics shop to skilled or better. I do like the idea of the haulers resetting traps but I wouldn't want them all making mechanisms.This is exactly what I do. I didn't document this in the dreamfort help because I didn't want newbies to get overwhelmed, but I can mention this in the professions docs.
The farmers have an awful lot of labors enabled. I'm leery. Maybe offload some of their tasks to the unskilled. Granted I don't use some of them at all (both dissection), some are used very rarely (gelding) and then of course shearing/spinning/milking/cheesing are like once per season. [...] I guess they might be ok. Especially running 5 or so of them.Yeah, most of the Farmer's labors are rarely used, but they need somebody free to do them when they need doing. Moreover, it's useful to have 5 farmers at peak planting/harvest season, but they need something to do the rest of the time.
It's unfortunate that fisher dwarfs can't handle their own cleaning and this is the next best group to do it.I just checked if prioritize can handle this, and it turns out it can! I'll add PrepareRawFish and ExtractFromRawFish to the "automatically prioritize" list in onMapLoad_dreamfort.init and move these labors to the fisherdwarves.
Miner is missing alchemy. [...] Animal care should be removed from Outdoorsdwarf, it will level up their doctor skills if used and we've already got the dr profession.Those changes should already be in the most recent professions definitions, just merged. You can pick them up by pulling from the DFHack repo now, and I'll remove the old ones from the shared drive. You still have to manually copy the updated professions from hack/examples/professions/ to professions/ to use them in manipulator, though.
I forgot if I mentioned or not, running setup after F1 runs without error.I fixed the alias in the /setup blueprint to automate that step, so it *should* run reliably now regardless of where the wagon is on your screen (as long as you don't redefine the {F1} hotkey before running the /setup blueprint).
Probably all the jobs should have [Alchemist]? I converted the professions over to DT by hand (they're just text files) and autohauler does not care about the professions set hauling labors. I don't know if dfhack manipulator works any differently than DT since I haven't tried it yet. Actually it doesn't seem like autohauler is respecting the alchemy setting either. I'm at a loss but this is my first time trying it.I included hauling labors in the professions so they'd be useful for players regardless of whether they are using autohauler. I expect them to get overridden if autohauler is active. However, I need to double-check to make sure all the hauling labors are set correctly for each profession. Sometimes autohauler decides to change the labors just as I'm saving changes in manipulator and I don't notice.
on-new-fortress buildingplan set boulders false; buildingplan set logs false
on-new-fortress enable autohauler
on-new-fortress autohauler FEED_WATER_CIVILIANS allow; autohauler RECOVER_WOUNDED allow
enable dwarfvet
dwarfvet enable
on-new-fortress autobutcher target 0 0 0 0 new
the autohauler lines let me manually manage those two labors. I'll make a note of that at the end of the professions docs.Move small animal disection from farmer to outdoorsdwarf, he has most of the ranger skills anywayI try to keep labors associated with a particular workshop together. I could move both butchery and small animal dissection to the Outdoorsdwarf, though... I'll have to playtest that to see how well that works. Sometimes the Outdoorsdwarves are outside chopping trees for a long time, but butchery and dissection isn't exactly super-time sensitive.
Kinda dangerous to only have a handful feeding prisoners/patients. I usually leave that on.It's on for Doctors, Haulers, and Outdoorsdwarves. Is that not enough? Haulers might be too busy, which is why I added it specifically to the other two professions.
Mixed feelings about the recovering wounded too, normally I keep the civilians on lockdown until it's clear anyway. OTOH the ones that get wounded by wild animals in the caverns...hmmm...yeah, would be better to have armed dorfs on recovery. Maybe add it to the miners too, picks are deadly.Yeah, it was the caverns that inspired me to only give this to armed dwarves. Good idea to include miners.
Can probably remove beekeeping from farmers, the outdoorsdwarfs are better suited being armed.I had added this to farmers to ensure the beehive products were promptly gathered -- the beehives themselves are normally populated from outside hives at the beginning of the game. Or so I thought. After some observation, I do see dwarves continuing to go outside to repopulate drained hives, despite having two hives inside the fort reserved for population splitting. Ok, removed from farmers.
Papermaking is considered a craftsdwarf skill, another to unload from farmer. Prefer grouping in DF categories to keep # of guilds from getting out of hand. Pottery, glazing, glassmaking are also considered craftsdwarf. Glassmaking being the only moodable out of these. Technically the textile skills are also craftsdwarf but I think they are a good split. Jeweler are also their own skillsI'd be happy to reallocate labors, but we do need to ensure dwarves don't block on each other due to workshop conflict. You make a good point about guilds. The opposing issue I'm trying to balance is complexity of workshop layout and the resulting brittleness of the blueprint set:
Carpenter, bowyer, woodcutter all considered 1 group. Would probably make carpenter/bowyer its own profession or possibly roll into outdoorsdwarf. Siegecraft goes with Mechanic, although I tend to not use it anyway.
I don't want to get in the way of your research, but here are some quick responses/reactions:
- I had put glassmaking with the smiths since at that time I really didn't understand how powerful glassmaking was. I'm all for moving it to a better-suited profession.
- Agree that "Unskilled" is a terrible name. +1 for any of your other suggestions
- I have civilian skills (like mechanics) on the soldiers since it is useful to set all squads to inactive right after a siege so they can help haul cages, reset traps, and dump prisoner equipment. Then I set them back to active and start "live training" on the caged invaders. I'm considering adding my "prisoner recycling" setup to dreamfort, but I wasn't sure if it was too me-specific. I have a caged prisoner quantum stockpile in my barracks that is also a pasture. After I strip the equipment from the prisoners, I just set them all to be assigned to the pasture that the cages are already sitting on top of. Haulers come and free the caged prisoners one by one, and as soon as they are freed, all my soldiers who are training in the barracks jump on them and body parts go a'flying.
Startmanager - still deciding what to do with this guy, honestly until we have someone to actually do a job do we really need their workplace built? he will never do 90% of these labors. Probably just going to dump him.If we can cut the number of professions down, I'm for it. The potential drawback here is that a workshop that is planned but not built ties up an item with TSK. In this case, the items are likely to be blocks and they're likely to be inside the surface starter mason's workshop. I wrote guidance (https://docs.google.com/spreadsheets/d/1vlxOuDOTsjsZ5W45Ri1kJKgp3waFo8r505LfZVg5wkU/edit#gid=1864520676) on how to "safely" decommission those workshops, but for players who don't read/heed the guidance, the longer we let TSK blocks stay in those workshops, the more likely it will be that the workshop will get deconstructed, the item will get scattered, and the unbuilt workshops will get canceled and disappear. This is a bad player experience, and is really the whole reason for the StartManager to exist.
Remove blocks from misc, no need to haul them an extra time.this is probably useful for everyone. added.
I remove refuse-corpses from that pile; early surface vermin corpses not a concern.Is this just for this embark, or would you always remove refuse/corpses from the cloth stockpile? I believe I added it at your request : ) I'm fine with removing it or keeping it. The corpse/refuse quantum stockpile on Farming gets set up so quickly anyway.
Since I was too lazy to pull the new files, I have to run orders 1 by 1. I actually prefer that anyway since it seems like otherwise construction bogs down and I run into hauling issues.you mean with the "preloaded" orders? I actually thought these were quite minimal. what do you think we could improve here? Maybe move orders for /services2 later?
I like a bigger guard dog pasture, I delete the existing and make it 5x5, removing the 2 stairwell tiles.The only reason I didn't do this by default is because I use those adjacent gate control levers during sieges *a lot* and clicking on them with the mouse is the fastest way to use them. if there's a dog on top of it, a click goes to 'view dog' instead of 'query lever'.
I'm really not sure about the autohauler and alchemy, although it at least isn't assigning the miners any hauling jobs, it did remove their assigned ones (remove/pull lever/vehicle) from DT.I expect you probably don't want vehicle hauling labors on your miners. since "store item in vehicle" jobs get their priority boosted, your miners will constantly be abandoning their mining to go put things into minecarts.
I think food-hauling needs to be made high priority. Can it be done?it probably *can* be done, I just need to find the time to dig into it. I believe I can get a reference to the item being hauled, and if the item is a food, I can likely deduce that it's a haul food labor. I might be able to use this same technique to identify tanning jobs. Then I just need to expose this feature in the prioritize script so it doesn't look like the hacky wart I expect it to be.
I suspect because I turned off global planning momentarily to do some manual construction and it lost the settings for the floors?buildingplan shouldn't lose material settings if you just disable and re-enable planning for floors. It *will* lose its config if you quit and reload, though. I have it on my backlog to persist materials configs across reloads. It's relatively easy to do, if anyone reading this wants a starter project.
I was going to relocate the kilns up top right, but decided the complexity of stone distribution wasn't worth it, besides I may want more masons and probably jewelers up there. Also some wierdo may come along and want a kennel to train vermin pets, and that would be the last spot left.eep. I just did some redesign to get another two craftsdwarf's workshops in the industry level, and I ended up moving the siege workshop to the upper right. Feedback on the new layout would be appreciated.
It's time to orders import basic and also...I might be able to trim this down a bit, but it's important to call out the roof over the barracks. If /surface5 is run before that section is complete (and it's usually the last to be completed) then the barracks beds can't get placed. the blueprint won't fail, the beds just won't show up. It's an easy mistake to make.
"quickfort run,orders library/dreamfort.csv -n /surface5 # Run when all marked trees on the surface are chopped down and walls and floors have been constructed, including the roof section over the future barracks." Would have been more concise to say after surface4 is completed :P
!!!***!!! prioritize CustomReaction !!!***!!!I should run a fort with CustomReaction just always prioritized and see how that goes. Maybe using that sledgehammer to prioritize tanning jobs is good enough.
guess who that be, I mean tan a hide is the only reaction missing from the entire friggin list...you can even prioritize beat a prisoner, I love it!
Autobutcher is a fucking disaster! It butchered everything so fast that half the shit sat and rotted, even with me manually running do now when I could.I've been running into this as well. Maybe this problem will go away when I figure out how to prioritize hauling food. Otherwise, we could maybe shift building the butchery until later when there are more haulers.
I've started implementing some of the changes we're discussing, though I'm holding off doing too much to the professions until you've formed some more solid opinions. You can pull the updated files from:
https://github.com/DFHack/dfhack/pull/1930 (https://github.com/DFHack/dfhack/pull/1930)
Startmanager - still deciding what to do with this guy, honestly until we have someone to actually do a job do we really need their workplace built? he will never do 90% of these labors. Probably just going to dump him.If we can cut the number of professions down, I'm for it. The potential drawback here is that a workshop that is planned but not built ties up an item with TSK. In this case, the items are likely to be blocks and they're likely to be inside the surface starter mason's workshop. I wrote guidance (https://docs.google.com/spreadsheets/d/1vlxOuDOTsjsZ5W45Ri1kJKgp3waFo8r505LfZVg5wkU/edit#gid=1864520676) on how to "safely" decommission those workshops, but for players who don't read/heed the guidance, the longer we let TSK blocks stay in those workshops, the more likely it will be that the workshop will get deconstructed, the item will get scattered, and the unbuilt workshops will get canceled and disappear. This is a bad player experience, and is really the whole reason for the StartManager to exist.
I did ask for it yes, just need the useful refuse products though, in case of surface butchering (which I am probably no longer doing). The main things on surface piles are getting stuff that will rot (food) if you yoink the wagon and/or create them (butcher, cook, fish, etc) and a stone pile with wheel barrows. Everything else can probably just sit where it is until you can get it underground. Granted if you let it sit out too long aQuoteI remove refuse-corpses from that pile; early surface vermin corpses not a concern.Is this just for this embark, or would you always remove refuse/corpses from the cloth stockpile? I believe I added it at your request : ) I'm fine with removing it or keeping it. The corpse/refuse quantum stockpile on Farming gets set up so quickly anyway.
Yes. No, services2 is fine where it is. I like to get the hospital started sooner rather than later, since it takes some time to stock. What I usually wind up doing if I queue all those orders (which I often do anyway) is add order conditions to each set tied to the last set (usually the blocks being done) so that stuff gets done in sequence, but that is a real PITA. Still I find a hard pause in between useful, so that some hauling gets caught up on. Especially since mason cancellation spam is a near constant thing until 2nd migrant wave for me (I force workshops to get from piles). I think just chaining them individually with their run command is probably best like "quickfort run,orders library/dreamfort.csv -n /services2" although possibly chaining the next one with the prior may work in some cases. Like surface2 orders won't get done before workshops are built, the blocks are redundant at that point and I remove them, but those 2 wheelbarrows are absolute top priority. Up to surface5 I may want the orders done before designation. surface6+ I don't (they are larger and more complex and tie up significant labor at that point).QuoteSince I was too lazy to pull the new files, I have to run orders 1 by 1. I actually prefer that anyway since it seems like otherwise construction bogs down and I run into hauling issues.you mean with the "preloaded" orders? I actually thought these were quite minimal. what do you think we could improve here? Maybe move orders for /services2 later?
Excellent point. I'll just go back to moving the puppers to the main pasture when they are born.QuoteI like a bigger guard dog pasture, I delete the existing and make it 5x5, removing the 2 stairwell tiles.The only reason I didn't do this by default is because I use those adjacent gate control levers during sieges *a lot* and clicking on them with the mouse is the fastest way to use them. if there's a dog on top of it, a click goes to 'view dog' instead of 'query lever'.
QuoteI'm really not sure about the autohauler and alchemy, although it at least isn't assigning the miners any hauling jobs, it did remove their assigned ones (remove/pull lever/vehicle) from DT.I expect you probably don't want vehicle hauling labors on your miners. since "store item in vehicle" jobs get their priority boosted, your miners will constantly be abandoning their mining to go put things into minecarts.
Yeah, after perusing the prioritize list, I saw how the hauling is handled. Probably going to be a lot of work. Right now I am opening up the list frequently and looking for store in cookable food orders and manually prioritizing them just to try to get it done. Oh, also saw clean self in there, might be a good idea. Infection is forever in DF, and leading cause seems to be untreated minor wounds because the dipshits won't go to hospital to get them treated.QuoteI think food-hauling needs to be made high priority. Can it be done?it probably *can* be done, I just need to find the time to dig into it. I believe I can get a reference to the item being hauled, and if the item is a food, I can likely deduce that it's a haul food labor. I might be able to use this same technique to identify tanning jobs. Then I just need to expose this feature in the prioritize script so it doesn't look like the hacky wart I expect it to be.
I am not really sure what happened with the build orders. I know about the non-persistence, but I don't think I reloaded at that point (It was a long day so I can't say for certain). I know I did specify walls, levers, trackstops, even the ramp. It is still possible I skipped the floors I guess.QuoteI suspect because I turned off global planning momentarily to do some manual construction and it lost the settings for the floors?buildingplan shouldn't lose material settings if you just disable and re-enable planning for floors. It *will* lose its config if you quit and reload, though. I have it on my backlog to persist materials configs across reloads. It's relatively easy to do, if anyone reading this wants a starter project.
Lemme look. Yes, that works. We can just as easily put more jewelers/masons on the now vacated west side. If the kennel ever became relevant there's probably a better place than industry for it anyway. Dunno why I didn't think of moving siege. Actually, I'd add 1 more next to the dyer as the catchall. Make next to the loom bone only. So we've got stone/wood/bone/everything else. I could see paper/bookmaking becoming busier late fort (the earlier bugs with libraries being a major reason I stopped playing for a bit...the endless pick things up and put them down cycle), and possibly more instrument making. This way they don't have to contend with ammo & pots for space.QuoteI was going to relocate the kilns up top right, but decided the complexity of stone distribution wasn't worth it, besides I may want more masons and probably jewelers up there. Also some wierdo may come along and want a kennel to train vermin pets, and that would be the last spot left.eep. I just did some redesign to get another two craftsdwarf's workshops in the industry level, and I ended up moving the siege workshop to the upper right. Feedback on the new layout would be appreciated.
Lol, no the job itself is fine. I was poking fun at the description. Literally it would be easier and less open for interpretation to say finish the job before queing the next one. As you have it, I start looking around and then realize by the end of reading that it all needs to be done anyway.QuoteIt's time to orders import basic and also...I might be able to trim this down a bit, but it's important to call out the roof over the barracks. If /surface5 is run before that section is complete (and it's usually the last to be completed) then the barracks beds can't get placed. the blueprint won't fail, the beds just won't show up. It's an easy mistake to make.
"quickfort run,orders library/dreamfort.csv -n /surface5 # Run when all marked trees on the surface are chopped down and walls and floors have been constructed, including the roof section over the future barracks." Would have been more concise to say after surface4 is completed :P
Considering I didn't lose any of the 7 hides although I did lose a lot of food, I'd say the customreaction is working well. I added it to my config.Quote!!!***!!! prioritize CustomReaction !!!***!!!I should run a fort with CustomReaction just always prioritized and see how that goes. Maybe using that sledgehammer to prioritize tanning jobs is good enough.
guess who that be, I mean tan a hide is the only reaction missing from the entire friggin list...you can even prioritize beat a prisoner, I love it!
I think we have to suck up and deal with it. We still want to get to butchering before 1st caravan or we are in danger of running out of meals. It was the timing for me; I got 5 large animals plus the 2 I already had. That is a ton of meat. It's also not the typical 1st or 2nd migration wave. Cookie was also busy updating stockpile records or likely would have flowed into kitchen better. In hindsight I should have temporarily disabled autobutcher and probably bookkeeping as well. They just came off migrant status when all this happened.QuoteAutobutcher is a fucking disaster! It butchered everything so fast that half the shit sat and rotted, even with me manually running do now when I could.I've been running into this as well. Maybe this problem will go away when I figure out how to prioritize hauling food. Otherwise, we could maybe shift building the butchery until later when there are more haulers.
I love the playlog! I'm tweaking things as I read through.
I've made progress (that is, I've succeeded) in prioritizing just food-related StoreItemInStockpile jobs. As a by-product, I've identified a bug in the DFHack hauler_type enum value definitions. The enum was defined more than 9 years ago, so it's likely that the values have changed over the years. PR here (https://github.com/DFHack/df-structures/pull/435).
I haven't finished testing the new prioritize script, but I put it up here (https://github.com/DFHack/scripts/pull/327) if you'd like to give it a try. The command to run would be:
prioritize -a --hauler-type=Food StoreItemInStockpile
but since the enum values are incorrect, the command is currently:
prioritize -a --hauler-type=Bin StoreItemInStockpile
Once the fix is made to df-structures, hauler-type will be "Food" as expected.
What I usually wind up doing if I queue all those orders (which I often do anyway) is add order conditions to each set tied to the last set (usually the blocks being done) so that stuff gets done in sequence, but that is a real PITA.the technique I've been using is to set the mason workshop to only accept 2 orders at a time (down from the default of 5). This makes them focus on the blocks and other "long tail" orders more without having to do too much manual poking.
Oh, also saw clean self in there, might be a good idea.added.
Actually, I'd add 1 more next to the dyer as the catchall.done.
Oh, also move the quicklime pile over there on that wall.That pile is milk of lime, not quicklime. Quicklime is stored in bags in the furniture stockpile, and I'm not sure we can separate them out easily.
Also, I'm still bewildered by why "lye" works for me but not you. In my last fort the new orders actually screwed me over, because I have like 11 lye in a barrel and "lye-containing" only sees it as 1 of course. Being as a barrel probably holds 30 (we know it holds 30 booze) that is a real problem."lye" works fine as a stop condition. I was using "lye-containing" as an assurance against potential cancellation spam (all lye in one barrel means that if it gets hauled back from the shop while the next job is starting, it's not available for the job and the job gets canceled). In my first tests, it looked like each barrel could only hold 7 lye, and I thought 3*7 = 21 wasn't so bad. My current fort shows a barrel with -- let me double check this -- *98* units of lye! I have about 200 units in those three barrels together. That's..too much.
maybe even bump [the guildhall sections under the cisterns] dig priority to 3 in the plans (the stairs 6 above will still preserve level integrity).good idea. done.
I use the pump and dump method.I'm going to give this a try. I've been growing frustrated with 100+ z-level magma pump stacks. They're finicky to build. One out of order and a whole section of the stack can deconstruct, leaving parts in inaccessible tiles. They also take a lot of power. I've built windmill farms on the roof of the surface fort and routed power down through the pasture. This last fort I built 10 dwarven water reactors. They certainly look cool, but they take forever to set up.
So juggling workshops around, I think even better would be move the bowyer up next to the wood/carpentry craftshop, put the misc craftsdwarf shop where the bowyer was (it is more central to cloth and metal piles)done. I also swapped the wood craftsdwarf's workshop with the soaper's so the craftsdwarf's workshop is in the "main" cluster.
Goblets need to be removed from the goods feeder.you know, I've been doing this manually every game and I didn't think about adding it to the blueprint for some reason. done. but this required a new alias to be added to aliases-common.txt, so be sure to pull that from the PR (https://github.com/DFHack/dfhack/pull/1930) if you use the updated blueprints.
You forgot "prioritize -a CustomReaction" I'll put it in my override for now.This was intentional, for now at least. I want to run a few tests to see what else gets lumped in. I added some help text to the prioritize script to explain why prioritizing CustomReaction might be a good idea, and what the caveats are.
[lye and milk of lime] stockpiles should be 1 tile.Is this to save on the unused pot? How about if I just set the number of pots on that stockpile to 2? That has the nice side effect of creating manager orders for a few more pots when quickfort orders is run on /industry2.
http://dwarffortresswiki.org/index.php/DF2014:Magma#Minecarts Design 3: Minimalist magma moving.Nice. I'll give this a try on my next runthrough.
Random thought, hatches on the down stairs on each level for containment. They actually can't be broken by building destroyers on the level below them.I had that in one of my early versions, but I thought the hatch covers clogged up the early game too much. We could potentially work it into a later stage, though.
Happy to report the new food hauling priority is working.Yay! I'm looking forward to seeing this in action.
Combine-drinks otoh, is priceless. It would be great if it could run on booze piles automagicaly.I don't see why this can't be done. Iterate through all stockpiles and combine. Maybe file a feature request? This would be a good starter project for some aspiring new contributor.
Should probably add [cages] into basic.I'm going to have to test this. What happens when a low-volume repeating order for an item is at a higher priority than a one-time high-volume order? Will they get in the way of each other? My fear is that the low-volume cage order in basic would take precedence, create all needed cages one per day, and then deactivate, allowing the high-volume order for 40 cages to make...40 unneeded cages. Like I said, need to test to see what actually happens.
I can't imagine there are any other jobs on that, the list is so comprehensive. So far no issues, but it could still happen. Worst case though, we're talking some rare niche jobs that would it be a bad thing if they got prioritized?You forgot "prioritize -a CustomReaction" I'll put it in my override for now.This was intentional, for now at least. I want to run a few tests to see what else gets lumped in. I added some help text to the prioritize script to explain why prioritizing CustomReaction might be a good idea, and what the caveats are.
Yes. I hate the unused pots. They were a pointless idiotic design choice that creates more problems than they solve.Quote[lye and milk of lime] stockpiles should be 1 tile.Is this to save on the unused pot? How about if I just set the number of pots on that stockpile to 2? That has the nice side effect of creating manager orders for a few more pots when quickfort orders is run on /industry2.
Curious how it works out. Hopefully you don't run into the issues I did. I have done this on many forts and never had a problem.Quotehttp://dwarffortresswiki.org/index.php/DF2014:Magma#Minecarts Design 3: Minimalist magma moving.Nice. I'll give this a try on my next runthrough.
It's only 2 hatches per level(4 for services because the well maintenance level) per level. It could go on the later stages for sure. They become more important when you breach the caverns or go to the circus. It can't go on the stairwell dig itself because you need an adjacent tile dug out to be able to place a hatch (they need room to work), otherwise you get no access message.QuoteRandom thought, hatches on the down stairs on each level for containment. They actually can't be broken by building destroyers on the level below them.I had that in one of my early versions, but I thought the hatch covers clogged up the early game too much. We could potentially work it into a later stage, though.
I don't think it would be an issue, the low-volume order should get finished and the high-volume order should start. It isn't going to cycle fast enough to keep going, especially if we just have it make 1 at a time. I've still got surface8 to do, so I'll let you know how it works out. I think 10 empty is a reasonable start.QuoteShould probably add [cages] into basic.I'm going to have to test this. What happens when a low-volume repeating order for an item is at a higher priority than a one-time high-volume order? Will they get in the way of each other? My fear is that the low-volume cage order in basic would take precedence, create all needed cages one per day, and then deactivate, allowing the high-volume order for 40 cages to make...40 unneeded cages. Like I said, need to test to see what actually happens.
Since uniforms are so important, yet so hard to script with quickfort, I'm thinking we need some new tools. Maybe a "uniforms" plugin that can import and export JSON, like the orders plugin. Maybe also a script that can assign minecarts to routes. What other manual steps could be solved with better tools?
services place & query jail we could add making the 3 inn rooms into dorms.We could, but do we need dorms at that point? The first apartments level will have been built by the time /services4 is run. What's the benefit?
Auto pasture grazing livestock & wardogsThis might be doable with the existing zone plugin (https://docs.dfhack.org/en/latest/docs/Plugins.html#zone). I might be able to extend it by indicating a zone by name instead of numeric id. Might need some other filters as well.
Auto-lever. Links levers to bridges/floodgates/etc with the same name?brilliant. it can scan for levers with names and ensure there is a link to all linkable buildings with the same name. it will fail if there aren't enough mechanisms, but that's ok. it can be re-run until there are no more links to make. I had thoughts in my head about a "jobplanner" plugin that will create jobs when conditions are met (like item availability) -- essentially buildingplan for jobs -- but the design for such a plugin eluded me. A more specific use case like this is more tractable.
A utility to automate the magma-hauling process? That would be really useful, I don't know if it's feasible.Yeah, I'll have to play around with magma hauling to see if any automation ideas strike me.
or if you find some way to isolate certain tasksI think I've found a way. For CustomReaction jobs, there is a reaction_name field that has usable data, such as "TAN_A_HIDE", "BREW_DRINK_FROM_PLANT", "PIG_IRON_MAKING", "MILL_SEEDS_NUTS_TO_PASTE", "PRESS_HONEYCOMB", "MAKE_MEAD", "PROCESS_PLANT_TO_BAG", "MAKE_WAX_CRAFTS", etc. This seems viable, though I'll need to extend the "prioritize --registry" command to list all the available reaction names. No way I'll be able to list them all in the static help text (they might change with mods anyway). Luckily, I generalized the data model when I added support for filtering StoreItemInStockpile by hauling labor, and I can copy logic from the orders plugin where it validates reaction names, so this addition won't be quite so difficult.
Probably a good suggestion to say "after upgrading to magma (or just whenever you want to ramp up production), add more wheel barrows"Added a note to /industry_help
I'm starting to think the melt piles should be QSP too lol.I've considered this too. I kind of like having the visual of how many items are in the "meltable queue", though..
Stone blocks should really be up in the stone QSP. I think I've already mentioned metal furniture belonging in metal QSP. We probably don't want the bone and wood bolts down hereI agree with all of this, but I'm wary about making the industry stockpile configuration too complex. In particular, I want to avoid splitting an item category across two stockpiles. The stone/ore split is, I think, not an issue (it meets the "obviousness" test), but I don't want to make players have to think too much about where everything is stored. I'd be happy to split up the goods feeder stockpile, though, to get the furniture into wheelbarrows. We could improve it further by splitting heavy from light furniture, but that will take some alias work.
So the next question is how many smelters do we really want/need? [...] Is this making it too complicated? It feels like it.Yeah, I think it's best to leave late-game modifications up to the player. Requirements tend to get more customized at that point, and I don't want to over-specify Dreamfort.
the bar feeder needs to be largeragreed. done.
I expand to the empty space on the right for more magma-using furnaces, but late game I've actually been happy with just what can fit on the existing industry level.
2 masons (or 4 if I'm building something crazy on the surface)
2 forges
2 glass
6 smelters
once the initial surge of meltables dies down, I replace a few smelters with other options, depending on what I'm doing at the time.
Early game, this produces all the volume I can handle, and late game, the dwarves are so skilled that they don't need any more workshops to produce high volume.
Haha, well, you've certainly given me a lot to think about and refine this cycle! Give me some time to catch up.
I'm almost done with the modifications to prioritize (supporting specific reaction names) and I'm exploring what a uniforms plugin might look like. I also need to update the professions and the related documentation.
There is actually already a script that can clone an existing uniform. See gui/clone-uniform (https://docs.dfhack.org/en/latest/docs/_auto/gui.html#gui-clone-uniform).
Ok, changes to the dreamfort blueprints, aliases, init script, professions, orders, and documentation have been merged. I need to go back through this thread and add what I missed to my backlog so I can address them in the next wave of updates. Filtering by reaction name in the prioritize script is in the PR (https://github.com/DFHack/scripts/pull/327) but hasn't been merged yet since Lethosor is still actively reviewing. It's fully covered by unit tests, though, so I'm pretty confident that the code is solid. There will be a new release of DFHack soon (for some value of "soon"), so I'm going to do one or two more runthroughs of dreamfort, but I won't make any more changes for now unless I find serious issues.
After some more testing, I've found that the "keep a small stock"-style manager orders do keep the larger one-time orders from ever getting scheduled in the workshops. This is bad, since it absolutely kills fort efficiency, but the fix is relatively simple. I added a "sort" command to the orders plugin. Running the command on repeat once a game day keeps things running smoothly. PR here (https://github.com/DFHack/dfhack/pull/1950)
...aaaand it's merged! Thanks lethosor!
Did you find a way to get the magma-proof wheel-barrows to be used for the magma hauling?it's fiddly, but no more than the rest of the "minimalist magma moving" procedure:
I haven't really noticed any issues with the job prioritization running your default settings.It may be nothing. Evidence is anecdotal at this point. I need to write a monitoring script that keeps time-to-completion stats for all jobs so I can do some proper analysis.
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()}
I just finished working on a feature request (https://github.com/DFHack/dfhack/issues/1998) 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.
#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
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
Thanks! Done.
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.
#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.
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.
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".
So the new UI is in the latest release (DFHack 0.47.05-r5), but I totally forgot to add it to the release notes :! Oh well, there's more improvements to make anyway. I'll make a grand announcement for the next release ; )
Very cool! I love it.Thanks! Once I get blueprint transformations in, gui/quickfort will be feature complete, and then I can work on performance issues for larger blueprints.
Strand extraction should be done in Stonecrafter since the raw adamantine is going there and we don't want it carried halfway across the workshop by hand.done.
Metal thread needs to go to the bar/military feeder so that it can be used to make wafers (if locking down smelter input, see below). Will also keep it from being dyed.done. this required an update to the common aliases file, so be sure to update that if pulling the new dreamfort.csv!
I'm finding it essential to issue give orders for certain stockpiles to workshops-I feel your pain, but I'm going to hold off on this change for two reasons:
Smelters, which are a pain because the list is long but metalworker quantum, ore/clay feeder, flux, coal, both melt piles to all smelters. Otherwise they haul from all over with no wheelbarrow.
Dyer from cloth/bones quantum & feeder.Done. Also moved the dye from the goods quantum to the cloth quantum. Food won't rot in a refuse stockpile, just clothes and armor (according to the wiki (http://dwarffortresswiki.org/index.php/DF2014:Refuse))
Also remove all refuse>hair/wool>except sheep, llama, alpaca, troll from the feeder. Add them to the trash feeder.I updated the "craftrefuse" alias to include this restriction for hair/wool. Thanks!
I've also had issues with the dye items condition being too high, 3 seems to work better since it counts bags instead of amount of dye.done
Useful to put a storage pile under the dump on services leveldone. I kept it unconfigured, though, so the simple workflow of unforbid all and haulers will grab things still works as expected.
On a side note, it was a lot of fun loading up one of your saves where shortly after unpausing the captain of the guard goes and rams his fist through someones head.Ha! Is this the save on dffd (https://dffd.bay12games.com/file.php?id=15434) right now? I didn't even notice that!
I think it's time to add more jail cells, 2 more would fit easily on top at least.How about combining these ideas into a room off the side of the barracks, above the hospital:
1 room,mass chains and cages.
Guard captain's office should probably be on services level too since it is used for "interviews" , saves walking to/from noble level.
j ` ` ` j
` ` c ` `
v ` t ` v
` ` c ` `
j ` ` ` j
Ok, PR is up (https://github.com/DFHack/dfhack/pull/2162) for the Dreamfort improvements. Not sure if anyone wants to review, but I'll let it sit there for a few days just in case. Full list of improvements in the PR description.
Time to get some of my other PRs cleaned up and merged. I've got just a few too many open at the moment!
quickfort set force_marker_mode true#dig step 1: dig the top level
,d(5x3)
#dig step 2: smooth the walls
s,s,s,s,s,s,s
s, , , , , ,s
s, , , , , ,s
s, , , , , ,s
s,s,s,s,s,s,s
#dig step 3: channel the floor
,h(5x3)
#dig bottom level: remove ramps
,z(5x3)
#dig bottom level: smooth walls and floor
s(7x5)
How does something like this sound?
quickfort orders bp.csv -n/furniture --order-materials=wood,rock
Where you can specify the order of preference for materials used in the generated orders?
``--order-materials <spec>``
When generating manager orders, use materials according to the given spec
instead of the default "rock,wood,cloth,iron". Valid values are: rock, wood,
cloth, silk, yarn, leather, glass, and the names of any metals. You can
additionally override the materials preference for specific types of items
by adding comma-separated elements to the spec in the format
``<type>=<material``. For example, ``BOX=leather`` will produce leather bags
instead of the default rock coffers when a container is specified on a
blueprint.
quickfort orders myblueprint.csv --order-materials DOOR=wood,BED=wood,CABINET=wood
Now one thing is it still doesn't seem to discourage them eating and drinking the prisoners supplys.Yeah, I think you're right. I thought I saw an improvement, but further testing doesn't seem to bear it out. On the plus side, those are pretty nice rooms to eat in..
Suites level I set the doors since there are 2 in each room and this will discourage cross traffic. It probably all could use a bit more experimentation and observation.This is a good idea. I'll add it in.
Oh, I wasn't aware we had to put in special handling for the silver and platinum (I guess I forgot).It was a more recent discussion. See here: https://github.com/DFHack/dfhack/issues/2718
[link]Thanks! I'll get this integrated as part of https://github.com/DFHack/dfhack/issues/3367
Yeah, the 5 each of 4 kinds of meat I bring on embark makes 20 lavish meals.Nice. Ok, easy meals are gone then.
I've noticed a little wierdness on the orders export, conditions not always exporting. Like I specify unused dyed silk cloth in my cloaks order, but the export just captured cloth, I manually changed it to silk cloth. I think I caught and fixed everything though.I couldn't reproduce this particular problem. I created an order for a silk cloak, set the conditions to count "unused dyed silk cloth", exported, and got this, which is what I expected:
[
{
"amount_left" : 10,
"amount_total" : 10,
"frequency" : "Daily",
"id" : 10,
"is_active" : false,
"is_validated" : true,
"item_conditions" :
[
{
"condition" : "GreaterThan",
"flags" :
[
"dyed",
"silk"
],
"item_type" : "CLOTH",
"min_dimension" : 10000,
"value" : 10
}
],
"item_subtype" : "ITEM_ARMOR_CLOAK",
"job" : "MakeArmor",
"material_category" :
[
"silk"
]
}
]
Your changes looked good to me. You can see the what the final diff looked like here: https://github.com/DFHack/dfhack/pull/3385
Dreamfort changes are here: https://github.com/DFHack/dfhack/pull/3386
The changes will be in the next DFHack release, but of course Dreamfort doesn't fully apply yet in v50 until quickfort us updated (see https://github.com/DFHack/dfhack/issues/2974)
Did you learn anything more about those stuck jobs?
// allowing single groups
restrict=members
restrict=citizens
restrict=residents
restrict=visitors
// allowing multiple groups
restrict=citizens+residents // could use a different separator then ‘+’?
// allowing everyone
restrict=all
// maybe use ‘allow’ instead of ‘restrict’?