Print

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

[myk]

Quickfort doesn't autodig, it applies blueprint files like this one. For a #dig blueprint, quickfort designates the tiles for digging and then exits. It's not actually active while your dwarves are digging out the designated tiles. If you run a #dig blueprint and dig into a cavern because of it, the game responds as it usually does - the tiles that you now know to be in mid-air are undesignated, and everything else is up to you to fix. There is a quickfort undo command, at least, to quickly undesignate the tiles that you now don't want dug out.

Your question makes me think, though, there is no reason why quickfort can't monitor progress through a blueprint and automatically apply the next blueprint at the right time. For example, it could detect when you're done digging out a #dig blueprint and then automatically apply corresponding #build and #place and #query blueprints. This...is an interesting idea. I'll have to think about how this might be accomplished.

[A_Curious_Cat]

has blueprint been properly extended to work with the new version of quickfort and it's features?

[myk]

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):

• Support remaining building types

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.

• Specify blueprint modeline metadata

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

• Multi-type stockpiles

at least pick up all the top-level enabled categories. recording full stockpile configuration will take a lot more work, though

• Non-rectangular stockpiles

• Zone blueprints (incl. detailed settings)

• Room configuration

more than just the current if room then "r+". I'm thinking actual room sizes, justice settings, door settings, etc.

• Stockpile links (give/take)

If they're within the same blueprint

And then I'm thinking blueprint needs some usability features too:

• Select target area with cursor

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.

I don't have this work scheduled for myself yet, but it is on my radar.

[A_Curious_Cat]

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):

• Support remaining building types

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.

• Specify blueprint modeline metadata

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

• Multi-type stockpiles

at least pick up all the top-level enabled categories. recording full stockpile configuration will take a lot more work, though

• Non-rectangular stockpiles

• Zone blueprints (incl. detailed settings)

• Room configuration

more than just the current if room then "r+". I'm thinking actual room sizes, justice settings, door settings, etc.

• Stockpile links (give/take)

If they're within the same blueprint

And then I'm thinking blueprint needs some usability features too:

• Select target area with cursor

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.

I don't have this work scheduled for myself yet, but it is on my radar.

I've been looking through the guide that you posted a link to and it doesn't mention anything about you or your accomplishments.  It also refers to quickfort as a script.  I thought the new version was a plugin.  Are you sure this is the latest documentation?

[lethosor]

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, 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.

it doesn't mention anything about you or your accomplishments

I'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, and changes are listed in the changelog (including some quickfort changes).

[A_Curious_Cat]

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, 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.

it doesn't mention anything about you or your accomplishments

I'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, and changes are listed in the changelog (including some quickfort changes).

Ah.  Thank you.

Btw, does anyone know if quickfort can designate areas for dumping (i.e. d-b-d )?  Or do I have to do that by hand?

[myk]

Yeah, all actions in the (d)esignate menu are implemented, including traffic, forbidding, and dumping. '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.

[A_Curious_Cat]

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.

Thank you.  Designating stuff by hand is getting tedious.  Especially when I have to designate the same stuff over and over again.

[A_Curious_Cat]

One thing I've noticed is that the Quickfort User Guide only briefly glosses over aliases.  I had to read aliases.txt and aliases-common.txt (and data/init/interface.txt and the associated article on the wiki) to figure out how they work.

Is there any way that you could expand upon the information that the guide gives concerning aliases (i.e. make a section explaining syntax, how to make one's own alias, etc)?

[myk]

Yeah, Python Quickfort had its alias documentation in aliases.txt, so originally I just continued that tradition. It was only a few lines long anyway. Now that the documentation is much more complete and you have more advanced features like aliases including other aliases, aliases that act as functions with optional parameters, etc., it's starting to make sense to move the documentation to the user guide. I'll add that to my list to do for the next release (DFHack 0.47.04-r5, since -r4 is already in code freeze).

On another note, although you *can* use any named keycode from data/init/interface.txt, it should be very very rare that you need to. What information could I have included in the guide or syntax documentation that would have made you decide that it wasn't worth spending time reading data/init/interface.txt or the keycode wiki article? And since you did read them, did you find any useful information there that I should include directly in the quickfort documentation?

[A_Curious_Cat]

Yeah, the reason I went to interface.txt was because I was referred there by aliases.txt.  I then used the wiki to try and make sense of the syntax of interface.txt.  As for what I think should be included in the guide:  Basic syntax, an overview of all of the features and how to use them.  Also, a guided example.  And, of course, a list of all of the possible named keycodes.

[myk]

I snuck in a few more tiny features before the -r4 release:

• 'c' is now valid stockpile type. you can use it to indicate that you want a blank, unconfigured stockpile
• aliases can now have dashes and underscores in their names
• added some new aliases focused on naming in the aliases-common.txt "standard library": 'givename' and 'namezone'

You can use those last two in your blueprints like this:
{givename name="some name"} when over a building or stockpile
{namezone name="some name"} when over an activity zone

I also allowed the 'quantum' alias to take a 'name' parameter. So now you can do stuff like succinctly set up a quantum stockpile and give all the parts useful names like this:

Code: [Select]

#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"}

the quantumstopfromwest name names the hauling route and the quantum name names the quantum stockpile itself. Remember that names have a maximum length of 20 characters!

-r4 is almost done. Lethosor and I have been finding and squashing a few bugs and inconsistencies with the new buildingplan behavior. I have to say, Lethosor is an excellent leader for this project. He is extremely supportive of both contributors and players, and he works very hard to make sure DFHack maintains a high standard of quality.

[myk]

Ok, time to think about what's next. I'm focusing on feedback and refining the user experience right now, so no major new features. Just quality-of-life stuff. Here's my shortlist:

• Move alias documentation from aliases.txt to the user guide

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.

• more flexible script commandline argument parsing

Right now the parsing function we're using is overly strict about parameter order. For example, quickfort list dreamfort -l is legal syntax but quickfort list -l dreamfort is not. The second form is a more natural ordering and should totally be valid.

• quickfort GUI entry point at gui/quickfort

Essentially add gui/quickfort as another way to call quickfort gui so people who look for gui-driven scripts in the gui/ directory can find quickfort.

• Hotkey to enable buildingplan for all building types

When buildingplan only supported a few building types, it wasn't such a big deal to enable buildingplan for each building type you want to use it for. Now that there are so many supported building types, though, we need a quick way to just enable everything.

• Set buildingplan global settings from DFHack prompt

Implement 'buildingplan set [settingname] [value]' so settings can be initialized from dfhack.init or onMapLoad.init. I'm personally going to use this to configure buildingplan to enable all building types and only use blocks (and not logs, boulders, or bars) when finding items for buildings that require generic construction materials:

Code: [Select]

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.

• Scrollable message boxes in gui

Without this it is impossible to read long messages when using quickfort gui. This came up because the dreamfort help text has been getting longer and longer, and now is longer than my screen can accommodate.

• new blueprint mode: #ignore

For stuff that shouldn’t be visible to quickfort, like personal development notes. These "blueprints" won't appear in quickfort list

• Write walkthrough checklist for dreamfort

Dreamfort has a good, thorough walkthrough, but it is kinda long. I think it could use a condensed checklist that basically says: "here are the commands you need to run, in the order you need to run them in (see walkthough for details)". It will include all quickfort commands as well as calls to other scripts (like

Code: [Select]

orders import)

• Give descriptive names to dreamfort levers, bridges, and stockpiles

So dreamfort is more usable and understandable.

• --pretend mode for quickfort commands

So players can error-check blueprints and get statistics on what would be done, but not actually change any game state.

• Don’t require a game cursor for #notes blueprints

Right now, quickfort requires a game cursor before it will "run" a blueprint. Otherwise it wouldn't know where on the map to apply it. This made sense when the only blueprint types affected the map, but #notes blueprints just display help text. Requiring a cursor when running these blueprints is just annoying.

• File-scoped aliases

This is the only complex new feature I'm planning for the next wave. It will define a new blueprint mode: #aliases. Aliases defined in that "blueprint" can be used by any #query blueprint in the same file (i.e. a multi-blueprint .csv file or any sheet in an .xlsx file). With file-scoped aliases, players can share their blueprints on the forums/wikis and be sure that they will work correctly for other people, even if the blueprints use aliases that are not found in the DFHack aliases-common.txt "standard library".


Ok, that's it for now. Happy quickforting!

[PeridexisErrant]

• Move alias documentation from aliases.txt to the user guide

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.

The ".. include::" directive might help with that; it's how documentation is pulled out of scripts and it should work for aliases.txt too.  That means you don't have to worry about keeping two versions in sync, and still get to see all the docs while editing the file 

[myk]

I'd like to be able to do that, but there is still the issue that the docs in a player's aliases.txt won't be up to date unless they delete their aliases.txt file every time they update DFHack. I think it will be necessary to replace the help text in aliases.txt with a pointer to the online docs. Maybe keep basic docs in aliases.txt and just have more complete docs with advanced usage examples in the guide.