.. _quickfort-user-guide: .. _quickfort-blueprint-guide: Quickfort Blueprint Guide ========================= `Quickfort ` is a DFHack script that helps you build fortresses from "blueprint" .csv and .xlsx files. Many applications exist to edit these files, such as MS Excel and `Google Sheets `__. Most layout and building-oriented DF commands are supported through the use of multiple files or spreadsheets, each describing a different phase of DF construction: designation, building, placing stockpiles/zones, and setting configuration. The original idea came from :wiki:`Valdemar's ` auto-designation macro. Joel Thornton reimplemented the core logic in Python and extended its functionality with `Quickfort 2.0 `__. This DFHack-native implementation, called "DFHack Quickfort" or just "quickfort", builds upon Quickfort 2.0's formats and features. Any blueprint that worked in Python Quickfort 2.0 should work with DFHack Quickfort. DFHack Quickfort interacts with Dwarf Fortress memory structures directly, allowing for instantaneous blueprint application, error checking and recovery, and many other advanced features. This guide focuses on DFHack Quickfort's capabilities and teaches players how to understand and create blueprint files. Some of the text was originally written by Joel Thornton, reused here with his permission. For those just looking to apply existing blueprints, check out the `quickfort command's documentation ` for syntax. There are many ready-to-use blueprints available in the ``blueprints/library`` subfolder in your DFHack installation. Browse them on your computer or :source:`online `, or run ``quickfort list -l`` at the ``[DFHack]#`` prompt to list them, and then ``quickfort run`` to apply them to your fort! Before you become an expert at writing blueprints, though, you should know that the easiest way to make a quickfort blueprint is to build your plan "for real" in Dwarf Fortress and then export your map using the DFHack `blueprint` plugin. You can apply those blueprints as-is in your next fort, or you can fine-tune them with additional features from this guide. See the `Links`_ section for more information and online resources. .. contents:: Table of Contents :local: :depth: 2 Features -------- - General - Manages blueprints to handle all phases of DF construction - Supports .csv and multi-worksheet .xlsx blueprint files - Near-instant application, even for very large and complex blueprints - Blueprints can span multiple z-levels - You can package all blueprints and aliases needed for an entire fortress in a single file for easy sharing - "meta" blueprints that simplify the application of sequences of blueprints - Undo functionality for dig, build, place, and zone blueprints - Automatic cropping of blueprints so you don't get errors if the blueprint extends off the map - Can generate manager orders for everything required by a build blueprint - Includes a library of ready-to-use blueprints - Verbose output mode for blueprint debugging - Dig mode - Supports all types of designations, including dumping/forbidding items and setting traffic settings - Supports setting dig priorities - Supports applying dig blueprints in marker mode - Handles carving arbitrarily complex minecart tracks, including tracks that cross other tracks - Build mode - Fully integrated with DFHack buildingplan: you can place buildings before manufacturing building materials and you can use the buildingplan UI for setting materials preferences - Designate entire constructions in mid-air without having to wait for each tile to become supported - Automatic expansion of building footprints to their minimum dimensions, so only the center tile of a multi-tile building needs to be recorded in the blueprint - Tile occupancy and validity checking so, for example, buildings that cannot be placed on a target tile will be skipped instead of messing up the blueprint. Blueprints that are only partially applied for any reason (e.g. you need to dig out some more tiles) can be safely reapplied to build the remaining buildings. - Relaxed rules for farm plot and road placement: you can still place the building even if an invalid tile (e.g. stone tiles for farm plots) splits the designated area into two disconnected parts - Intelligent boundary detection for adjacent buildings of the same type (e.g. a 6x6 block of ``wj`` cells will be correctly split into 4 jeweler's workshops) - Place and zone modes - Define stockpiles and zones of shape, not just rectangles - Configurable numbers of bins, barrels and wheelbarrows assigned to created stockpiles - Automatic splitting of stockpiles and zones that exceed maximum dimension limits - Fully configurable zone settings, such as pit/pond and hospital supply counts - Query mode - Send arbitrary keystroke sequences to the UI -- *anything* you can do through the UI is supported - Supports aliases to simplify frequent keystroke combos - Includes a library of pre-made and tested aliases to simplify most common tasks, such as configuring stockpiles for important item types or creating named hauling routes for quantum stockpiles. - Supports including aliases in other aliases for easy management of common subsequences - Supports repeating key sequences a specified number of times - Skips sending keys when the cursor is over a tile that does not have a stockpile or building, so missing buildings won't desynchronize your blueprint - Instant halting of query blueprint application when keystroke errors are detected, such as when a mistake in a key sequence leaves us stuck in a submenu, to make query blueprints easier to debug Editing blueprints ------------------ We recommend using a spreadsheet editor such as Excel, `Google Sheets `__, or `LibreOffice `__ to edit blueprint files, but any text editor will do. The format of Quickfort-compatible blueprint files is straightforward. The first line (or upper-left cell) of the spreadsheet should look like this:: #dig The keyword ``dig`` tells Quickfort we are going to be using the Designations menu in DF. The following "mode" keywords are understood: ============== =========== Blueprint mode Description ============== =========== dig Designations menu (:kbd:`d`) build Build menu (:kbd:`b`) place Place stockpiles menu (:kbd:`p`) zone Activity zones menu (:kbd:`i`) query Set building tasks/prefs menu (:kbd:`q`) ============== =========== If no modeline appears in the first cell, Quickfort assumes that it's looking at a ``#dig`` blueprint. There are also other modes that don't directly correspond to Dwarf Fortress menus, but we'll talk about those `later `. If you like, you may enter a comment after the mode keyword. This comment will appear in the output of ``quickfort list`` when run from the ``DFHack#`` prompt. You can use this space for explanations, attribution, etc. :: #dig grand dining room Below this line begin entering keys in each spreadsheet cell that represent what you want designated in the corresponding game map tile. For example, we could dig out a 4x4 room like so (spaces are used as column separators here for readability, but a real .csv file would have commas):: #dig d d d d # d d d d # d d d d # d d d d # # # # # # Note the :kbd:`#` symbols at the right end of each row and below the last row. These are completely optional, but can be helpful to make the row and column positions clear. Once the dwarves have that dug out, let's build a walled-in bedroom within our dug-out area:: #build Cw Cw Cw Cw # Cw b h Cw # Cw Cw # Cw Cw Cw # # # # # # Note my generosity - in addition to the bed (:kbd:`b`) I've built a chest (:kbd:`c`) here for the dwarf as well. You must use the full series of keys needed to build something in each cell, e.g. :kbd:`C`:kbd:`w` indicates we should enter DF's constructions submenu (:kbd:`C`) and select walls (:kbd:`w`). I'd also like to place a booze stockpile in the 2 unoccupied tiles in the room. :: #place Place a food stockpile ` ` ` ` # ` ~ ~ ` # ` f f ` # ` ` ` # # # # # # This illustration may be a little hard to understand. The two :kbd:`f` characters are in row 3, columns 2 and 3. All the other cells are empty. QF considers both :kbd:`\`` (backtick -- the character under the tilde) and :kbd:`~` (tilde) characters within cells to be empty cells; this can help with multilayer or fortress-wide blueprint layouts as "chalk lines". QF is smart enough to recognize this as a 2x1 food stockpile, and creates it as such rather than as two 1x1 food stockpiles. Quickfort treats any connected region of identical designations as a single entity. The tiles can be connected orthogonally or diagonally, just as long as they are touching. Lastly, let's turn the bed into a bedroom and set the food stockpile to hold only booze. :: #query ` ` ` ` # ` r& ` # ` booze # ` ` ` ` # # # # # # In row 2, column 2 we have ``r&``. This sends the :kbd:`r` key to DF when the cursor is over the bed, causing us to "make room" and :kbd:`Enter`, represented by special ``&`` alias, to indicate that we're done setting the size (the default room size is fine here). In column 2, row 3 we have ``booze``. This is one of many alias keywords defined in the included :source:`aliases library `. This particular alias sets a food stockpile to accept only booze. It sends the keys needed to navigate DF's stockpile settings menu, and then it sends an Escape character to exit back to the map. It is important to exit out of any menus that you enter while in query mode so that the cursor can move to the next tile when it is done with the current tile. If there weren't an alias named ``booze`` then the literal characters :kbd:`b`:kbd:`o`:kbd:`o`:kbd:`z`:kbd:`e` would have been sent, so be sure to spell those aliases correctly! You can save a lot of time and effort by using aliases instead of adding all key seqences directly to your blueprints. For more details, check out the `Quickfort Alias Guide `. You can also see examples of aliases being used in the query blueprints in the :source:`DFHack blueprint library `. You can create your own aliases by adding them to :source:`dfhack-config/quickfort/aliases.txt` in your DFHack folder. Area expansion syntax ~~~~~~~~~~~~~~~~~~~~~ In Quickfort, the following blueprints are equivalent:: #dig a 3x3 area d d d # d d d # d d d # # # # # #dig the same area with d(3x3) specified in row 1, col 1 d(3x3)# ` ` ` # ` ` ` # # # # # The second example uses Quickfort's "area expansion syntax", which takes the form:: keys(WxH) Note that area expansion syntax can only specify rectangular areas. If you want to create extent-based structures (e.g. farm plots or stockpiles) in different shapes, use the first format above. For example:: #place L shaped food stockpile f f ` ` # f f ` ` # f f f f # f f f f # # # # # # Area expansion syntax also sets boundaries, which can be useful if you want adjacent, but separate, stockpiles of the same type:: #place Two touching but separate food stockpiles f(4x2) # ~ ~ ~ ~ # f(4x2) # ~ ~ ~ ~ # # # # # # As mentioned previously, :kbd:`~` characters are ignored as comment characters and can be used for visualizing the blueprint layout. This blueprint can be equivalently written as:: #place Two touching but separate food stockpiles f(4x2) # ~ ~ ~ ~ # f f f f # f f f f # # # # # # since the area expansion syntax of the upper stockpile prevents it from combining with the lower, freeform syntax stockpile. Area expansion syntax can also be used for buildings which have an adjustable size, like bridges. The following blueprints are equivalent:: #build a 4x2 bridge from row 1, col 1 ga(4x2) ` # ` ` ` ` # # # # # # #build a 4x2 bridge from row 1, col 1 ga ga ga ga # ga ga ga ga # # # # # # Automatic area expansion ~~~~~~~~~~~~~~~~~~~~~~~~ Buildings larger than 1x1, like workshops, can be represented in any of three ways. You can designate just their center tile with empty cells around it to leave room for the footprint, like this:: #build a mason workshop in row 2, col 2 that will occupy the 3x3 area ` ` ` # ` wm ` # ` ` ` # # # # # Or you can fill out the entire footprint like this:: #build a mason workshop wm wm wm # wm wm wm # wm wm wm # # # # # This format may be verbose for regular workshops, but it can be very helpful for laying out structures like screw pump towers and waterwheels, whose "center point" can be non-obvious. Finally, you can use area expansion syntax to represent the workshop:: #build a mason workshop wm(3x3) # ` ` ` # ` ` ` # # # # # This style can be convenient for laying out multiple buildings of the same type. If you are building a large-scale block factory, for example, this will create 20 mason workshops all in a row:: #build line of 20 mason workshops wm(60x3) Quickfort will intelligently break large areas of the same designation into appropriately-sized chunks. Multilevel blueprints ~~~~~~~~~~~~~~~~~~~~~ Multilevel blueprints are accommodated by separating Z-levels of the blueprint with ``#>`` (go down one z-level) or ``#<`` (go up one z-level) at the end of each floor. :: #dig Stairs leading down to a small room below j ` ` # ` ` ` # ` ` ` # #> # # # u d d # d d d # d d d # # # # # The marker must appear in the first column of the row to be recognized, just like a modeline. .. _quickfort-dig-priorities: Dig priorities ~~~~~~~~~~~~~~ DF designation priorities are supported for ``#dig`` blueprints. The full syntax is ``[letter][number][expansion]``, where if the ``letter`` is not specified, ``d`` is assumed, and if ``number`` is not specified, ``4`` is assumed (the default priority). So each of these blueprints is equivalent:: #dig dig the interior of the room at high priority d d d d d # d d1 d1 d1 d # d d1 d1 d1 d # d d1 d1 d1 d # d d d d d # # # # # # # #dig dig the interior of the room at high priority d d d d d # d d1(3x3) d # d ` ` ` d # d ` ` ` d # d d d d d # # # # # # # #dig dig the interior of the room at high priority 4 4 4 4 4 # 4 1 1 1 4 # 4 1 1 1 4 # 4 1 1 1 4 # 4 4 4 4 4 # # # # # # # Marker mode ~~~~~~~~~~~ Marker mode is useful for when you want to plan out your digging, but you don't want to dig everything just yet. In ``#dig`` mode, you can add a :kbd:`m` before any other designation letter to indicate that the tile should be designated in marker mode. For example, to dig out the perimeter of a room, but leave the center of the room marked for digging later:: #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 # # # # # # # Then you can use "Toggle Standard/Marking" (:kbd:`d`:kbd:`M`) to convert the center tiles to regular designations at your leisure. To apply an entire dig blueprint in marker mode, regardless of what the blueprint itself says, you can set the global quickfort setting ``force_marker_mode`` to ``true`` before you apply the blueprint. Note that the in-game UI setting "Standard/Marker Only" (:kbd:`d`:kbd:`m`) does not have any effect on quickfort. Stockpiles and zones ~~~~~~~~~~~~~~~~~~~~ It is very common to have stockpiles that accept multiple categories of items or zones that permit more than one activity. Although it is perfectly valid to declare a single-purpose stockpile or zone and then modify it with a ``#query`` blueprint, quickfort also supports directly declaring all the types in the ``#place`` and ``#zone`` blueprints. For example, to declare a 20x10 stockpile that accepts both corpses and refuse, you could write:: #place refuse heap yr(20x10) And similarly, to declare a zone that is a pasture, a fruit picking area, and a meeting area all at once:: #zone main pasture and picnic area nmg(10x10) The order of the individual letters doesn't matter. If you want to configure the stockpile from scratch in a ``#query`` blueprint, you can place unconfigured "custom" stockpiles with (:kbd:`c`). It is more efficient, though, to place stockpiles using the keys that represent the categories of items that you want to store, and then only use a ``#query`` blueprint if you need fine-grained customization. .. _quickfort-place-containers: Stockpile bins, barrels, and wheelbarrows ````````````````````````````````````````` Quickfort has global settings for default values for the number of bins, barrels, and wheelbarrows assigned to stockpiles, but these numbers can be set for individual stockpiles as well. To set the number of bins, barrels, or wheelbarrows, just add a number after the letter that indicates what type of stockpile it is. For example:: #place a stone stockpile with 5 wheelbarrows s5(3x3) #place a bar, ammo, weapon, and armor stockpile with 20 bins bzpd20(5x5) If the specified number exceeds the number of available stockpile tiles, the number of available tiles is used. For wheelbarrows, that limit is reduced by 1 to ensure there is at least one non-wheelbarrow tile available in the stockpile. Otherwise no stone would ever be brought to the stockpile since all tiles would be occupied by wheelbarrows! Quickfort figures out which container type is being set by looking at the letter that comes just before the number. For example ``zf10`` means 10 barrels in a stockpile that accepts both ammo and food whereas ``z10f`` means 10 bins. If the stockpile category doesn't usually use any container type, like refuse or corpses, wheelbarrows are assumed:: #place a corpse stockpile with 3 wheelbarrows y3(3x3) Note that if you are not using expansion syntax, each tile of the stockpile must have the same text. Otherwise the stockpile boundaries will not be detected properly:: #place a non-rectangular animal stockpile with 5 wheelbarrows a5,a5,a5,a5 a5, , ,a5 a5, , ,a5 a5,a5,a5,a5 Running ``quickfort orders`` on a ``#place`` blueprint with explicitly set container/wheelbarrow counts will enqueue manager orders for the specified number of containers or wheelbarrows, even if that number exceeds the in-game size of the stockpile. For example, ``quickfort orders`` on the following blueprint will enqueue 10 rock pots, even though the stockpile only has 9 tiles:: #place f10(3x3) Zone detailed configuration ``````````````````````````` Detailed configuration for zones, such as the pit/pond toggle, can also be set by mimicking the hotkeys used to set them. Note that gather flags default to true, so specifying them in a blueprint will turn the toggles off. If you need to set configuration from multiple zone subscreens, separate the key sections with :kbd:`^`. Note the special syntax for setting hospital supply levels, which have no in-game hotkeys:: #zone a combination hospital and shrub (but not fruit) gathering zone gGtf^hH{hospital buckets=5 splints=20}(10x10) The valid hospital settings (and their maximum values) are:: thread (1500000) cloth (1000000) splints (100) crutches (100) powder (15000) buckets (100) soap (15000) To toggle the ``active`` flag for zones, add an :kbd:`a` character to the string. For example, to create a *disabled* pond zone (that you later intend to carefully fill with 3-depth water for a dwarven bathtub):: #zone disabled pond zone apPf(1x3) Minecart tracks ~~~~~~~~~~~~~~~ There are two ways to produce minecart tracks, and they are handled very differently by the game. You can carve them into hard natural floors or you can construct them out of building materials. Constructed tracks are conceptually simpler, so we'll start with them. Constructed tracks `````````````````` Quickfort supports the designation of track stops and rollers in ``#build`` blueprints. You can build a track stop with :kbd:`C`:kbd:`S` and some number of :kbd:`d` and :kbd:`a` characters for selecting dump direction and friction. You can build a roller with :kbd:`M`:kbd:`r` and some number of :kbd:`s` and :kbd:`q` characters for direction and speed. However, this can get confusing very quickly and is very difficult to read in a blueprint. Moreover, constructed track segments don't even have keys associated with them at all! To solve this problem, Quickfort provides the following keywords for use in build blueprints:: -- Track segments -- trackN trackS trackE trackW trackNS trackNE trackNW trackSE trackSW trackEW trackNSE trackNSW trackNEW trackSEW trackNSEW -- Track/ramp segments -- trackrampN trackrampS trackrampE trackrampW trackrampNS trackrampNE trackrampNW trackrampSE trackrampSW trackrampEW trackrampNSE trackrampNSW trackrampNEW trackrampSEW trackrampNSEW -- Horizontal and vertical roller segments -- rollerH rollerV rollerNS rollerSN rollerEW rollerWE Note: append up to four 'q' characters to roller keywords to set roller speed. E.g. a roller that propels from East to West at the slowest speed can be specified with 'rollerEWqqqq'. -- Track stops that (optionally) dump to the N/S/E/W -- trackstop trackstopN trackstopS trackstopE trackstopW Note: append up to four 'a' characters to trackstop keywords to set friction amount. E.g. a stop that applies the smallest amount of friction can be specified with 'trackstopaaaa'. As an example, you can create an E-W track with stops at each end that dump to their outside directions with the following blueprint:: #build Example track trackstopW trackEW trackEW trackEW trackstopE Note that the **only** way to build track and track/ramp segments is with the keywords. The UI method of using :kbd:`+` and :kbd:`-` keys to select the track type from a list does not work since DFHack Quickfort doesn't actually send keys to the UI to build buildings. The text in your spreadsheet cells is mapped directly onto DFHack API calls. Only ``#query`` blueprints send actual keycodes to the UI. Carved tracks ````````````` In the game, you carve a minecart track by specifying a beginning and ending tile and the game "adds" the designation to the tiles in between. You cannot designate single tiles. For example to carve two track segments that cross each other, you might use the cursor to designate a line of three vertical tiles like this:: ` start here ` # ` ` ` # ` end here ` # # # # # Then to carve the cross, you'd do a horizonal segment:: ` ` ` # start here ` end here # ` ` ` # # # # # This will result in a carved track that would be equivalent to a constructed track of the form:: #build ` trackS ` # trackE trackNSEW trackW # ` trackN ` # # # # # To carve this same track with a ``#dig`` blueprint, you'd use area expansion syntax with a height or width of 1 to indicate the segments to designate:: #dig ` T(1x3) ` # T(3x1) ` ` # ` ` ` # # # # # "But wait!", I can hear you say, "How do you designate a track corner that opens to the South and East? You can't put both T(1xH) and T(Wx1) in the same cell!" This is true, but you can specify both width and height, and for tracks, QF interprets it as an upper-left corner extending to the right W tiles and down H tiles. For example, to carve a track in a closed ring, you'd write:: #dig T(3x3) ` T(1x3) # ` ` ` # T(3x1) ` ` # # # # # Which would result in a carved track simliar to a constructed track of the form:: #build trackSE trackEW trackSW # trackNS ` trackNS # trackNE trackEW trackNW # # # # # .. _quickfort-modeline: Modeline markers ~~~~~~~~~~~~~~~~ The modeline has some additional optional components that we haven't talked about yet. You can: - give a blueprint a label by adding a ``label()`` marker - set a cursor offset and/or start hint by adding a ``start()`` marker - hide a blueprint from being listed with a ``hidden()`` marker - register a message to be displayed after the blueprint is successfully applied The full modeline syntax, when all optional elements are specified, is:: #mode label(mylabel) start(X;Y;STARTCOMMENT) hidden() message(mymessage) comment Note that all elements are optional except for the initial ``#mode`` (though, as mentioned in the first section, if a modeline doesn't appear at all in the first cell of a spreadsheet, the blueprint is interpreted as a ``#dig`` blueprint with no optional markers). Here are a few examples of modelines with optional elements before we discuss them in more detail:: #dig start(3; 3; Center tile of a 5-tile square) Regular blueprint comment #build label(noblebedroom) start(10;15) #query label(configstockpiles) No explicit start() means cursor is at upper left corner #meta label(digwholefort) start(center of stairs on surface) #dig label(digdining) hidden() managed by the digwholefort meta blueprint #zone label(pastures) message(remember to assign animals to the new pastures) .. _quickfort-label: Blueprint labels ```````````````` Labels are displayed in the ``quickfort list`` output and are used for addressing specific blueprints when there are multiple blueprints in a single file or spreadsheet sheet (see `Packaging a set of blueprints`_ below). If a blueprint has no label, the label becomes the ordinal of the blueprint's position in the file or sheet. For example, the label of the first blueprint will be "1" if it is not otherwise set, the label of the second blueprint will be "2" if it is not otherwise set, etc. Labels that are explicitly defined must start with a letter to ensure the auto-generated labels don't conflict with user-defined labels. Start positions ``````````````` Start positions specify a cursor offset for a particular blueprint, simplifying the task of blueprint alignment. This is very helpful for blueprints that are based on a central staircase, but it helps whenever a blueprint has an obvious "center". For example:: #build start(2;2;center of workshop) label(masonw) a mason workshop wm wm wm # wm wm wm # wm wm wm # # # # # will build the workshop *centered* on the cursor, not down and to the right of the cursor. The two numbers specify the column and row (or X and Y offset) where the cursor is expected to be when you apply the blueprint. Position ``1;1`` is the top left cell. The optional comment will show up in the ``quickfort list`` output and should contain information about where to position the cursor. If the start position is ``1;1``, you can omit the numbers and just add a comment describing where to put the cursor. This is also useful for meta blueprints that don't actually care where the cursor is, but that refer to other blueprints that have fully-specified ``start()`` markers. For example, a meta blueprint that refers to the ``masonw`` blueprint above could look like this:: #meta start(center of workshop) a mason workshop /masonw .. _quickfort-hidden: Hiding blueprints ````````````````` A blueprint with a ``hidden()`` marker won't appear in ``quickfort list`` output unless the ``--hidden`` flag is specified. The primary reason for hiding a blueprint (rather than, say, deleting it or moving it out of the ``blueprints/`` folder) is if a blueprint is intended to be run as part of a larger sequence managed by a `meta blueprint `. .. _quickfort-message: Messages ```````` A blueprint with a ``message()`` marker will display a message after the blueprint is applied with ``quickfort run``. This is useful for reminding players to take manual steps that cannot be automated, like assigning minecarts to a route, or listing the next step in a series of blueprints. For long or multi-part messages, you can embed newlines:: "#meta label(surface1) message(This would be a good time to start digging the industry level. Once the area is clear, continue with /surface2.) clear the embark site and set up pastures" The quotes surrounding the cell text are only necessary if you are writing a .csv file by hand. Spreadsheet applications will surround multi-line text with quotes automatically when they save/export the file. .. _quickfort-packaging: Packaging a set of blueprints ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A complete specification for a section of your fortress may contain 5 or more separate blueprints, one for each "phase" of construction (dig, build, place stockpiles, designate zones, and query adjustments). To manage all the separate blueprints, it is often convenient to keep related blueprints in a single file. For .xlsx spreadsheets, you can keep each blueprint in a separate sheet. Online spreadsheet applications like `Google Sheets `__ make it easy to work with multiple related blueprints, and, as a bonus, they retain any formatting you've set, like column sizes and coloring. For both .csv files and .xlsx spreadsheets you can also add as many blueprints as you want in a single file or sheet. Just add a modeline in the first column to indicate the start of a new blueprint. Instead of multiple .csv files, you can concatenate them into one single file. This is especially useful when you are sharing your blueprints with others. A single file is much easier to manage than a directory of files. For example, you can store multiple blueprints together like this:: #dig label(bed1) d d d d # d d d d # d d d d # d d d d # # # # # # #build label(bed2) b f h # # # n # # # # # # #place label(bed3) # f(2x2) # # # # # # # # #query label(bed4) # booze # # # # # # # # #query label(bed5) r{+ 3}& # # # # # # # # # Of course, you could still choose to keep your blueprints in single-sheet .csv files and just give related blueprints similar names:: bedroom.1.dig.csv bedroom.2.build.csv bedroom.3.place.csv bedroom.4.query.csv bedroom.5.query2.csv The naming and organization is completely up to you. .. _quickfort-other-modes: Other blueprint modes ~~~~~~~~~~~~~~~~~~~~~ There are a few additional blueprint modes that become useful when you are sharing your blueprints with others or managing complex blueprint sets. Instead of mapping tile positions to keystroke sequences like the basic modes do, these "blueprints" have specialized, higher-level uses: ============== =========== Blueprint mode Description ============== =========== meta Link sequences of blueprints together notes Display long messages, such as help text or blueprint walkthroughs ignore Hide a section from quickfort, useful for scratch space or personal notes ============== =========== .. _quickfort-meta: Meta blueprints ``````````````` Meta blueprints are blueprints that script a series of other blueprints. For example, many blueprint sets follow this pattern: 1. Apply dig blueprint to designate dig areas #. Wait for miners to dig #. **Apply build buildprint** to designate buildings #. **Apply place buildprint** to designate stockpiles #. **Apply query blueprint** to configure stockpiles #. Wait for buildings to get built #. Apply a different query blueprint to configure rooms Those three "apply"s in the middle might as well get done in one command instead of three. A ``#meta`` blueprint can encode that sequence. A meta blueprint refers to other blueprints in the same file by their label (see the `Modeline markers`_ section above) in the same format used by the `quickfort` command: ``/