Ok, more progress. I'm pretty happy with how meta blueprints came out. You can now apply a bunch of blueprints with a single command. I also implemented a "hidden()" marker for blueprints that are managed by meta blueprints so the lower-level blueprint doesn't clutter up the quickfort list output.
Also done is a #zone mode for placing zones, similar to the existing #place mode for stockpiles.
BTW, the user manual is now up! For now, you can view it
here, but eventually we'd like to integrate it into the DFHack docs on
https://docs.dfhack.org/. I've written explanations for all the features I've completed so far (including a few which are done but haven't been merged yet). Please give it a read and tell me if anything isn't clear!
I've been working on a large-scale end-to-end example to stress test all these features, and the biggest issue I'm running into is complexity management. You have a long list of blueprints in quickfort list. Which one do you apply next? At what point should you run quickfort orders to queue up the manager orders so you can apply build blueprints? And which "meta" blueprints refer to build blueprints such that running quickfort orders is worthwhile?
It makes me think more about blueprint packaging and user experience. Now that we have meta blueprints to manage all the lower-level blueprints, do we need something even higher level than meta?
One feature I just added was the ability for a blueprint to output a message when it completes. For example, if you require a manual action after the blueprint runs, this message could give you details. For example, if a #zone blueprint just designated a pasture, the message could remind you to assign animals to it. Perhaps a series of meta blueprints with "next step" messages would be a good way to keep track of what's next. I'll try that with my example fort (which has 23 steps) and see how it goes.