Print

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

[ldog]

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?

Ahhh, no, forgot about that. Was still running '04

[myk]

Ok, now that dfhack-0.47.05-r1 is drawing near, it's time for a quick summary of what's recently changed and what's in the pipeline. A lot has gone in since my last summary (see the DFHack core and scripts changelogs for the definitive list), but here are the highlights:

• A good number of bugs were found and fixed.

Quickfort got a lot of testing this cycle, both from me doing normal development (plus seemingly endless dreamfort runs) and from members of the community. Thank you cjhammel and ldog for helping me isolate the #zones crash bug, and thank you Grumalg for helping me find the issue that was preventing stockpiles from being placed in empty regions within the bounds of other stockpiles. Special thanks as well to lethosor, who is always there to point me in the right direction when I get lost in DF's (and DFHack's) internals. Now that I'm more confident in quickfort's stability, I've gone ahead and deprecated DFHack's digfort script and fortplan plugin, which partially handled #dig and #build blueprints, respectively. I've added documentation to help digfort and fortplan users transition to quickfort (essentially: move your blueprints to the blueprints/ folder and replace the words "digfort" and "fortplan" with "quickfort run" on the commandline).

• Dreamfort is now 1000x better

That's a subjective measurement of course, but really, with ldog's feedback and assistance, dreamfort has come a long way. The individual levels are much more efficiently designed and the fort as a whole is much faster to get up and running, making it work just as well in dangerous embark sites. The automation orders have been tuned to cover a greater variety of fortress needs while greatly reducing cancellation spam. The help documentation is far more complete, and there is now a checklist of commands so players can just copy/paste their way to victory. I also wrote up some embark profile suggestions for players looking to optimize their dreamfort experience.

• Better GUI dialog

The quickfort GUI dialog got some love. It now gives feedback when you generate manager orders. You can also set the string filter as well as the --hidden and --library flags from the commandline instead of having to set them with hotkeys after the dialog is shown. For example, quickfort gui --library dreamfort notes will start the dialog with the dreamfort walkthrough blueprints already shown.

• Set container counts in #place blueprints

You can now set exactly how many bins, barrels, and/or wheelbarrows a stockpile should have when creating them with #place blueprints. This also hooks into the manager orders generation, so running quickfort orders on a #place blueprint will now enqueue orders for any explicitly set number of (wooden) bins, (stone) pots, and (wooden) wheelbarrows.

• Buildingplan is more convenient to use

Now that all building types are supported by buldingplan, it can be annoying to enable each type individually when you just want planning mode everywhere. Now there is an "enable all" option in buildingplan's global settings dialog to switch all building types to planning mode. You can now also set buildingplan global settings from the console, for example: buildingplan set boulders false. Buildingplan global filter settings (like boulders, logs, bars, etc.) are persisted in the savegame, so you don't need to set them every time you load a game. "Mode" settings (like the new "enable all" setting) are not persisted, but they can be set from onMapLoad.init if you want them on all the time.

• Bundle aliases with blueprints

One of my long term goals for this project is to make community blueprints super easy to share and use so players can learn from other players. Having aliases separate from the blueprints that use them is a barrier to sharing them easily. With aliases in a separate file, there are two steps for using someone else's blueprints: (1) copy their aliases into your dfhack-config/quickfort/aliases.txt file and then (2) run the blueprint. Now with the new #aliases sections, you can declare your aliases right in the blueprint file. This means players can use shared blueprints without any manual steps, which should result in far fewer "it doesn't work" complaints.


So what's next?

I'm finally getting around to the automated regression test framework. After all the manual testing that went into the current version of quickfort, it seems silly not to "lock in the quality". I would hate to inadvertently break something in the future and not notice because it's too much work to manually test everything after every change. Automated tests will give me a lot more confidence that I can make disruptive changes safely.

While I'm writing quickfort tests, I plan to focus on buildingplan for actual feature work. There are still a lot of usability enhancements I'd like to get done for buildingplan, like persisting the item filter settings in the savegame, setting all related filters at once (e.g. setting all constructions to use a particular color of stone blocks), resetting all filters to defaults, etc. I also want to tweak the item matching algorithm so that pickier filters are satisfied first, and I want to give players the ability to move specific buildings up in priority so important buildings get their items matched ASAP.

At some point I'd also like to overhaul the blueprint plugin so it produces more complete and more usable blueprints, too.

[clinodev]

[...]

I also wrote up some embark profile suggestions for players looking to optimize their dreamfort experience.

[...]

Are you familiar with my Annotated Craftlords embark profile(s)?

When DF looks at an embark profile, it just ignores anything not in [square brackets] so it's possible to include up to a full tutorial.

If you'd like to pretty up an embark profile, (annotated or not) and have it included with the Packs, let me know.

[myk]

That would be awesome - something that players can use more directly would be very useful

[myk]

w00t! DFHack-0.47.05-r1 is out! With the bugs ironed out of quickfort and the improvements to dreamfort, I'm really excited about this release.

Formal testing is going well. I got code coverage reporting integrated into DFHack and I've fully unit tested the quickfort parser functions. Found and fixed a few small bugs in previously unexplored corner cases, but nothing that significant. Testing should get more interesting as I create integration tests that modify game state.

I'm going to start looking at updating wikis and making DFHack quickfort more well known. I'm confident now that it's ready for widespread use.

[Mir]

I'm having some trouble figuring out how to use the Blueprint plugin to create the blueprints I want to later replay.

I've got a small 5x5 block of random designations in place... some up stairs, some down stairs, and some dig squares.

I've tried placing my cursor at the center of it with all of q, d, k and then running 'blueprint 5 5 1 test dig`.
It creates the test-dig.csv I'd expect, and it's got quickfort style blueprint data in it... but it's designating nothingness for every square.

Doesn't seem to matter where I place the cursor, or how I 'get' the cursor. Hell I've tried centering with the mouse cursor even and using the ctrl+shift+p dfhack console to issue the command and keep the mouse in place... nothing.

I'm sure I'm overlooking something simple, but I just can't sort it. Any advice?

This is via PeridexisErrant's Starter Pack 0.47.05-r02, which is running Dwarf Fortress 0.47.05 and DFHack 0.47.05-r1 (release).

[myk]

Blueprint needs some usability work, I will not deny.

It would certainly be cool if blueprint could read designations, and I have this feature in mind for the future. For now, though, blueprint reads the *actual* shape of the tile, not the designation. This means that you have to actually dig the tiles out before blueprint will create a proper blueprint from them.

Also, blueprint expects the cursor to be at the top left of the target area. Allowing a flexible start position is another idea I have for blueprint's future.

[Mir]

Oh! Well that makes a lot of sense.
Thanks for the help!

[bassmannate]

Just making sure I'm not missing anything about getting this to work. I'm using the GUI to select my blueprints. If I don't have a cursor on the screen, it give me an error to place the cursor at the start location. If I bring up literally any cursor such as "look" or "designate" it will bring up the notes for that blueprint but doesn't appear to do anything.

[myk]

What's probably happening here is that you're running the first blueprint in the file, and that blueprint happens to be the help text blueprint. To actually do something to the map, be sure to select the blueprint with the proper label within the file.

For example, library/dreamfort.csv contains many blueprints. The first one is /help, which gets run by default if you don't specify a -n parameter on the commandline (e.g. quickfort run library/dreamfort.csv) or if you run the first dreamfort blueprint in the gui. If you want to run the dreamfort blueprint that, say, digs a central stairwell and sets up surface zones (among other things), you'd run quickfort run library/dreamfort.csv -n /surface1 or select that line in the quickfort gui.

I'm making some assumptions here about what's happening, so if this isn't useful, maybe take a screenshot of the quickfort gui screen so I can see what you're seeing. Then I can give better advice. If this post *is* useful, though, what could I change in the documentation or in quickfort itself to make things more obvious?

Btw, in the latest release of DFHack (0.47.05-r1), a cursor is no longer required to run help text (i.e. #notes) blueprints.

[bassmannate]

No, I've double checked it. I've tried the surface-1 blueprint as well as some of the older quick fortress blueprints. When I do it through the console using the run command, it tells me that "Tiles outside map boundary: X I just tried that with the embark.csv and it told me 12.

[myk]

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

[bassmannate]

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

I'll give it a shot here later. I'm not sure if it's worth mentioning but I'm running this under the LinuxDwarfPack version of the Lazy Newb Pack. I'll see if I can get a separate install with DFHack going or even see if I can put the latest version of DFHack into the system installation directory since I installed this with a DEB package.

Here's the output of that lua command after I ran the embark.csv:

Code: [Select]

[DFHack]# lua ~df.global.cursor
<global.T_cursor: 0x19bfe60>
x                      = 108
y                      = 96
z                      = 129


[bassmannate]

Alright, instead of risking my system install, I simply copied it all over to my home directory and extracted the newer build of DFHack over that install. My initial try looks promising. I did the quickfortress dig1 blueprint from the gui and it did designate a number of channeling tiles. I'll mess with it some more and report back here but it may be that the version of DFHack in that pack is just old despite it being released only a month ago.

[bassmannate]

Alright, new problem. I'm following dreamfort to learn how it all works. The guide says to run automation.json but despite having it where it's saying to put it, it's still telling me that dfhack-config/orders/automation.json could not be found.

Code: [Select]

:~/Applications/linux-dwarf-pack/df_47_05_linux/dfhack-config/orders$ ls
automation.json

Any thoughts? Am I missing something obvious?