It's recommended to enable the blueprintbuildmode setting in the MineColonies server config file; this makes it a bit easier to do certain things without creating a colony.

Scans are saved in ../minecolonies/scan/new/....

Once the scans are saved, they need to be moved to the ../structurize/schematics/(folder)/file if they are a custom hut.

Scans are saved in */blueprints/<yourplayername>/scans.

Once the scans are saved, they need to be placed in a style pack, preferably in the correct folder. See the style packs chapter for more details.

Once you have scanned a structure, you can use the Build Tool to have your Builder build it for you. Once you right-click with the build tool, you will have to select "My Schematics" (in the left dropdown menu) and on the right dropdown menu you will see the scans that you have made. There is also a Rename button where you can change the name of the scan. You can also delete any of your saved scans.

The scanned structure can be found in the Build Tool under the style pack with your own name. Click "Switch Pack" -> "<yourplayername>" (icon looks like the Scan Tool ) -> "scans".

Style packs

Styles are now structured in so-called style packs. This is similar to a resource pack or data pack, in that it has a file with some metadata about the style (the name, a description, optionally a link to an image, etc.), and a folder structure with the actual files.

Stylepacks live in the blueprints folder, within your Minecraft folder. This folder already contains one style pack: One with your player's name. This style pack will contain your scanned files, and can be used to test schematics. In order to make a new style, you need to make a new schematic pack.

The pack.json

This json file contains metadata describing the style:

You have to increase the version number whenever you release your pack for others to use. You don't need to increase it when testing changes purely in single-player. In particular, whenever the pack is installed on a server, it must have a higher version than what other players already have, or they won't be sent the updates automatically.

The folder structure

There are several folders, separating the buildings and decorations in categories. Each of the folders at the highest level can have a couple of icons, named icon.png and icon_disabled.png. Those are shown in the button bar right above the hot bar.

You can download a template folder structure from github (template.zip), which contains the icons used for the official styles already. That github page also contains examples how different styles are structured. An overview with which buildings go into which folders can also be found here.

With a few specific exceptions, you don't have to strictly follow the standard folder structure -- but it's recommended to stick to it when possible to make it easier for others to find specific buildings and decorations. But you're free to make extra folders to help group separate but related sets together, especially if you don't want them to appear directly as alternate buildings. E.g. if you have two styles of roads, one for early game and one for later game, you could put them in infrastructure/roads/simple/ and infrastructure/roads/nice/.

Note: It's strongly recommended to have each folder only contain files or subfolders, but not both. While it is possible to mix them, the build tool doesn't display it as nicely.

Those custom schematics go in */structurize/schematics. Unzip the zip you downloaded, and put all subfolders in the schematics folder. That folder should contain folders like <stylename>, decorations, walls, supplycamps etc. (depending on which style you installed)

The style pack goes in the "blueprints" folder. Unzip the zip, and find the folder containing the pack.json (either the unzipped folder, or a folder directly under it, depending on how the zip was made). This folder needs to be placed in */blueprints directly, not any subfolder thereof -- i.e. you should have "blueprints/onestyle/pack.json", "blueprints/anotherstyle/pack.json", etc.

This is a client-side-only directory which is located in Minecraft's folder under: */structurize/scans/. Freshly scanned schematics can be found in */structurize/scans/new/ unless they have been renamed in-game. (If they aren't there, look in */minecolonies/scans/new.) This directory is shared between all your singleplayer games and multiplayer games.

This is located in your own style pack in Minecraft's folder under: */blueprints/<yourplayername>/scans/. This folder is shared between all your singleylayer and multiplayer games.

Custom schematics need to be copied inside the schematic folder. For both singleplayer and multiplayer games, the folder is under */structurize/schematics/.

Custom schematics need to be placed in a (custom) style pack. For more information about that, look there.

When playing on a server, the server needs to send the schematics to the players so that the build tool's preview works. Those schematics are saved in Minecraft's directory under */structurize/{ServerUUID}/cache/, where ServerUUID is the unique identifier of the server. Those directories can be safely removed as they are automatically created by the server when needed.

This was previously used to save schematics from a server and was automatically created as needed. However, this is no longer needed in 1.19.2 and later, so this folder can be removed safely.

I have a "/blueprints/clients/" folder, what is that for?

On a server, this folder holds a cached copy of the decorations and shapes used by your players -- possibly even including entire style packs that they've installed themselves (though note that for game balance purposes they won't be able to make functional buildings this way; these must be installed "properly" on the server to be usable).

You can delete these folders at any time (though preferably when the player is not logged in); they will be re-created as needed.

The scans' filenames need to follow the naming convention: {StyleName}/{HutName}{HutLevel}.blueprint. For example, for the Builder's Hut with the MyOwn style, we would have:

myown/builder1.blueprint myown/builder2.blueprint myown/builder3.blueprint myown/builder4.blueprint myown/builder5.blueprint

• Note: In the Build Tool , the extension is hidden. HutName can be any of the listed huts below. The maximum level is 5 (except for the Tavern ; its max level is 3).

Alternative designs can be placed under a style name like "myownalternative", or a subfolder like myown/alt/*.

The naming for the buildings is not strict anymore. The only things that are important are that they are named consistently, that their names end with the hut level, and that you only use lowercase letters in the hut names (avoid capitals, spaces, or other punctuation). Alternate designs can just have a different name than the primary one. E.g. if you named the level 1 Builder's Hut "builder1", an alternative version could be called "altbuilder1" or "builderalt1" or even something completely different ("constructionworker1"). Don't use numbers anywhere in the name except right at the end for the level. E.g. "alt1builder1" won't work as expected.

Once ready, you need to make a style pack out of them. The schematics are visible in the build tool without the hut block, but you can't view them in survival mode (their button is greyed out, with an error message that you need to have the hut block).

As previously noted, you don't need to stick to these names if you have something better, as long as you're consistent at each level.

So, for example, the path would be structurize/schematics/wildwest/builder1 for the Builder's Hut level 1 and structurize/schematics/supplycamp/wildwestsupplycamp for the supply camp.

So, for example, the path would be blueprints/wildwest/fundamentals/builder1 for the Builder's Hut level 1 and blueprints/wildwest/decorations/supplies/supplycamp for the supply camp.

Because these have a fixed name, you can't have more than one per style and type.

Plantation Fields

In 1.19.2 and beyond, the plantation has been changed to include fields, just like the Farmer . However, unlike the Farmer , these fields can be completely free-form and created by the style designers. Each field has certain requirements for the Planter to do their work successfully.

Each plant has 2 separate tags: a field tag and a work tag. The field tags are given to the plantation field block to define what plants this field handles. The work tag is given based on the implementation of the field.

A field can have as many field tags as you want, but not 2 of the same.

The Planter will always attempt to walk to any adjacent air block around the planting position. If none of the adjacent positions are air, the planter will attempt to walk to the block itself. This prevents the Planter from standing on the block itself whilst, for example, placing a block down like cactus, after which the Planter would be standing inside of the plant.

Note: Make sure that the Planter can always get within about 4 blocks of the desired position. If not, they will teleport around to reach the position, which may not always work.

Note: Kelp is an exception to this behaviour. To prevent planters from diving into the water, the planter will walk to the first air block above the work tagged block and look up 26 blocks from the work tagged block. If this is not possible, they will not be able to harvest this plant, so ensure there is air above the water above the work tagged block.

• The red X is the position where the planter will walk to in the example image.
• The blue X is the position where the work tag of the block is.

For downwards-growing plants, the planter will attempt to stand above the work tagged block and harvest below them. Make sure the planter can reach the top of the stem.

Vertically Growing Plants (Upwards and Downwards)

A "vertically growing plant" is a plant that grows in a single line, either upwards or downwards; for example, Sugar Cane is a vertically growing plant that grows upwards. These plants always break fully when their root blocks are broken. The planter will break these at the second block from the root.

Each of these plants have a minimum and sometimes a maximum growth height. The planter can only harvest them when they reach the minimum. If plants have a maximum height, the planter will have an increasingly higher chance to harvest the plant the taller it gets. Plants are only required to grow to the minimum height within the bounds of the schematic.

Treeside Plants

Treeside plants grow directly on the sides of trees. For these plants, you only need to tag the tree's stem; the working positions will automatically be set to every horizontally adjacent block of the tagged stem. Currently this is only used for Cocoa beans.

Note that this means that the amount of tags you can actually place is the amount of working positions divided by 4!

Bonemealed Fields

Bonemealed fields will tell the planter to use bonemeal somewhere on the ground to grow plants as if the player had used bonemeal.

The amount of planting positions on these fields are usually unlimited because bonemealing the ground has a set area of effect. However, it is suggested not to make the fields too big; an area around 7x7 is lightly suggested.

Every bonemealed plant works slightly differently.

Plant	Work tag location
Seagrass	The block directly below the water should tagged; the planter will bonemeal the tagged block itself. Red Xs are where the planter will attempt to walk. Blue Xs are the blocks that are tagged with the work tag.
Sea pickles	The block directly below the water should tagged. The planter will initially place the pickles, then bonemeal the pickles to let them grow. Red Xs are where the planter will attempt to walk. Blue Xs are the blocks that are tagged with the work tag.
Crimson plants	Tag all the nylium ground blocks where the plants are supposed to grow.
Warped plants	Tag all the nylium ground blocks where the plants are supposed to grow.

Percentage-based Harvesting

Percentage based harvesting fields will attempt to place a minimum percentage of plants down on given spots. These plants — such as vines — should then naturally spread to their surroundings without the player's help. The planter has no involvement in this process.

Simply create a schematic file with the same style/name. For instance, to override the Builder's Hut wooden level 1, create a schematic file name called wooden/builder1.blueprint.

Unfortunately, this is not possible, unless you override the entire style (make a style pack with the same name as an existing style pack, in that case).

However, you can create an "addon pack" with only a few buildings and/or decorations, intended to be used with the original pack; players will be able to mix'n'match from all packs.

The custom huts need to be copied in the schematics folder.

The custom huts need to be copied into a style pack.

Add the Decoration Controller somewhere in the schematic with the name of the schematic, where you'll put it in the file directory, and its level. Make sure to actually put the decoration in that file path, but only after scanning - don't include the path in the scan name.

Put the Decoration Controller somewhere in the schematic, and make sure the name of the schematic ends with a number while scanning. The decoration controller will automatically find the decoration in the same folder with the next number.

Contrary to the image below, you don't need to enter anything into the deco controller's GUI before scanning any more -- but the rest of that image is still useful.

The custom mineshafts need to be at schematics/yourstyle/miner/*.

The custom mineshafts need to be at `blueprints/yourstyle/infrastructure/mineshafts/*.

It's recommended that you use the Tag Anchor to make the mineshafts invisible. Take care that the anchor is in the same position as in the original mineshafts -- the very center bottom block.

The top parts must be named simplequarry1 and mediumquarry1, and the corresponding bottom parts are simplequarryshaft1 and mediumquarryshaft1.

The top part can be in any folder and name that you like (and you can have more than one alternate), but the canonical names are infrastructure/mineshafts/simplequarry1 and infrastructure/mineshafts/mediumquarry1. Players will usually expect to find them in this folder.

The bottom part should usually be in the same folder and with the matching name but with shaft before the number -- e.g. infrastructure/mineshafts/simplequarryshaft1 and infrastructure/mineshafts/mediumquarryshaft1.

Alternatively, you can put a shaft= tag on the top part's Quarry block to specify a different name -- e.g. shaft=bighole1 to look for bighole1 in the same folder as the quarry, or shaft=decorations/quarrypit1 to look in a different folder.

Nope.

Using the Tag Tool , you can place one or more job= tags on the hut block to limit which jobs can actually work there. Currently, the only sensible combinations are:

• Guard tower : one or more of job=knight, job=ranger, job=druid. You can use these if you want to decorate your towers with specific themes (e.g. archery motifs).
• Mine : one of job=miner or job=quarrier. You can use this if you want to make a large building with a mineshaft for the Miner and a smaller one without for the Quarrier .

Since you can only have one version of each building in each folder, combinations should be used very sparingly. The parent and child need to be in the same folder.

To place the child hut in the parent, you can simply shift-click it, just like when placing it in the child itself. Be sure to get the location and rotation correct -- the child hut will be built with the matching orientation relative to that.

The parent and child need to be in the same folder. This doesn't mean that you can't combine buildings that are normally in different folders -- just that the version that's intended to be the child must be in the same folder as the parent. You may still have another version of the child (to be used by itself, not as a child) in the original folder if you like.

It's not supported to have a child contain additional children of its own -- you're limited to just the two layers (though the parent can contain multiple children of either the same or different types).

Regardless of which method you use to build, be sure to get the location and rotation of the child hut correct when placing it in the parent -- the building will be built with the matching orientation relative to that.

If you've used the default folder and filenames for your child, then you can simply shift-click the child hut to place it into the parent, similar to older versions. However this is not the most recommended way to do things any more.

The preferred method is to make another level of your child containing only the hut block, giving it the same folder and name as your actual child, but level 0 (e.g. craftsmanship/storage/mycourier0). You can make it the same size as your real child (surrounded by Placeholder s) if you wish, but scanning a 1x1x1 is fine too. After scanning, you need to move this to its final location in your actual style pack, and then paste it from there (not from your scans!) into your parent. It doesn't matter whether you use schematic or constructed paste. Paste the same level 0 into all levels of the parent. After it's pasted, you can delete the level 0 blueprint -- it should not be included in your final released style pack. (Note that when you go to paste it, the build tool labels it as "level 1" of 6. You can confirm you have the right one by checking the tooltip name.)

Another option is called "auto-levelling". This is where instead of making and pasting a level 0 into each level of the parent, you instead paste the actual matching child level (i.e. level 1 child in the level 1 parent, level 2 child in the level 2 parent, etc). Again it doesn't matter whether you use schematic or constructed paste, but either way you'll probably have to fix up some of the overlapping blocks afterward. You do still need to include the child hut's blueprints in your released style pack, and you do still have to paste it from your actual style pack and not your scans folder.

With auto-levelling, the builder will upgrade the child at the same time as upgrading the parent, instead of the player needing to explicitly build or upgrade one after the other. While this may sound simpler, there are some downsides: the biggest is that won't work well for child buildings that have required functional blocks (such as beds, furnaces, racks, etc), although purely decorative ones are fine. You also should not use this where the child is locked behind research, unless you can be absolutely certain that it's already unlocked (e.g. if the parent is unlocked after the child -- though still be careful of loops). The "level 0" method doesn't have these issues.

Since you can have multiple alternates of buildings (in the same or separate folders), it's possible to make a particular building type have both a standalone version as well as a version embedded as a child. It's strongly recommended to use the Tag Tool to mark any blueprint intended for use only as a child (in the child schematic itself) as invisible so that it doesn't show up for building standalone -- especially as child versions are often simpler or cheaper and may be missing walls or other things intended to be provided by the parent, so won't look good on their own or might break game balance. It's also possible to have each child of a parent be its own unique blueprint -- but that requires even more scans and more care when pasting to use the right alternate.