Print

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

[A_Curious_Cat]

Btw, the link labeled “quickfort command reference” at the top of the first post leads to a page that says “This page does not exist yet.”

[lethosor]

Sorry about that - DFHack is in the middle of a documentation reorganization. https://docs.dfhack.org/en/latest/docs/tools/quickfort.html is the new page. (If you select an older documentation version, it should have the page at the old URL, like https://docs.dfhack.org/en/stable/docs/_auto/base.html#quickfort or https://docs.dfhack.org/en/0.47.05-r6/docs/_auto/base.html#quickfort)

[A_Curious_Cat]

I’ve just noticed a problem with gui/blueprint and gui/quickfort.  There’s no way to capture and play back smoothing designations.  Is there any way that this could be added?

[myk]

Quickfort supports smoothing, but blueprint actually ignores them by design (since it's usually not a step you want to wait for before applying the next blueprint when playing them back with quickfort), but there's no reason we can't add a flag to give you the choice. We have a similar flag for capturing/ignoring engravings (which does capture the smoothing step separately, incidentally).

[A_Curious_Cat]

Also.  When I used ‘o’ to queue up the orders, it gave me rock doors.  I didn’t want that.  I wanted wooden doors like I had in the section that I used gui/blueprint on.  Is there any way to fix that?  Also, what about dumping?

[myk]

The blueprint code for dumping is bd on a #dig blueprint. It works the same as any other designation. The blueprint plugin, however, never generates it. Is there a way that the plugin could know that you want an area dumped? Right now you have to create dump blueprints manually.

Modifying the materials preference of the generated orders is possible with a medium amount of work. Right now the kinds of orders it generates are fixed. Let me record the feature request on GitHub and I see if I can get that in the next release (not the release going out today, the one after).

[A_Curious_Cat]

Note, btw,that I don’t care what kind of wood the doors are made of (though some people might care).  I only care that they’re made out of wood.  Similarly, if I wanted rock doors, I wouldn’t really care what type of rock they were made of.  Same for metal, etc.

[myk]

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?

[A_Curious_Cat]

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?

 Sounds good.  However, I’d like to be able to use it to set up 3x3 bedrooms with each having a wooden door, a bed, a rock coffer, and a wooden cabinet.

It’d be nice if there was a switch for blueprint to capture either exact materials or general materials (or none, defaulting to none if unspecified).

Perhaps this could be done by having blueprint create separate build blueprints for each material (or general material class).

[myk]

With the current version, if you want doors or other furniture of a specific material/material class, you'd configure buildingplan before applying the blueprint. You'd have to adjust the generated orders accordingly, though.

Controlling the materials in a blueprint is something that I've been thinking about for a long time, but I've been worried about causing confusion/frustration with such a feature. It might be possible to create blueprints that are impossible to build in other fortresses due to resource differences.

I'd kind of like to keep materials assignment in buildingplan where it is now, but that's not as convenient as encoding materials in a blueprint, especially when the player has a specific pattern of materials usage in mind.

In short, I'd love to add more support for materials, but I need to think through potential usability issues.

[myk]

Looking at the order materials option again, how does this sound instead?

Code: [Select]

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

That would allow you to specify, for example,

Code: [Select]

quickfort orders myblueprint.csv --order-materials DOOR=wood,BED=wood,CABINET=wood


[Dr. Hieronymous Alloy]

I suppose it'll be "a while" before we see this working in the steam version?

I've got so many old .csv fort plans to re-create!

[myk]

You and me both : )

Yes, quickfort, blueprint, and all the other design tools are on my priority list to get working with the Steam version as soon as possible. Basic work on the DFHack core modules, though, will have to be completed first, and that might take, as you said, "a while".

[Dr. Hieronymous Alloy]

Understood, thanks for all your work. Maybe I can figure out a way to just convert these old .csv quickfort plans i have and make them work in the meanwhile.

[myk]

The steam version will bring some challenges that we'll need to figure out how to overcome. For example, hotkeys have changed, and not all blueprint items even *have* hotkeys anymore.

At least in the short term, I don't plan to change anything about the blueprint language. This will ensure existing blueprints continue to function. Blueprints may have to start supporting a "hotkey agnostic" language, though. for example, right now to place a nestbox, you'd write "N" in a blueprint cell. Should "ofn" now be accepted to mean nestbox? What about "nestbox"? things could get confusing quickly.