Extending Structure Limits

When you open a Structure Block UI in-game, the text fields clamp the size you type to a maximum of 64 on the X axis, 384 on the Y axis (spanning the full build height from -64 to 320), and 64 on the Z axis. The offset fields are similarly clamped between -64 and 64. These numbers are purely an interface and command-parser restriction, not a limit of the file format itself.

Inside your behavior pack's `BP/structures/` folder, `.mcstructure` files are stored as uncompressed, little-endian NBT binaries. The root compound contains a `size` tag made of three 32-bit integers (`TAG_Int`) representing the X, Y, and Z dimensions, followed by a `structure` compound that holds the block indices and palette. Because the format uses standard 32-bit integers, the game engine can read and place `.mcstructure` files that are well over 64 blocks wide—until the file grows so large that reading it stalls the server thread.

If you want a single `.mcstructure` file that exceeds 64 blocks in width or length, you have to bypass the in-game UI clamping. Place a Structure Block in the world, set it to Save mode, and enter a structure name, then close the world. Open the world's `db/` folder in an external Bedrock-compatible NBT editor and locate the chunk containing your Structure Block.

Inspect the block entity data for that `structure_block`. You will find three integer tags that control the bounding box dimensions: `xStructureSize`, `yStructureSize`, and `zStructureSize`, alongside the offset tags `xStructureOffset`, `yStructureOffset`, and `zStructureOffset`. Change the size integers to your desired dimensions (for example, `128` for both X and Z) and save the world database.

When you reopen the world, do not edit the numbers in the text boxes, or the UI may re-clamp them. Instead, open the Structure Block and immediately click the Export button (on Windows or mobile) to write the `.mcstructure` file to disk, or power the block with redstone to save the oversized region into memory. Keep in mind that every loaded block has to sit inside an active ticking area during both saving and loading, so wrap the area with `/tickingarea add` before capturing anything larger than a few chunks.

Modifying world NBT is inconvenient if you iterate on your builds frequently, and single massive `.mcstructure` files can cause severe lag spikes when placed all at once. The cleaner add-on workflow is to slice a large build into a grid of 64x64 footprints, export each slice normally to `BP/structures/`, and assemble them at runtime using exact relative coordinates.

To assemble a 128x128 structure split into four quadrants (`nw`, `ne`, `sw`, `se`), place a single function file in your behavior pack. Because `/structure load` places the file's minimum X, Y, Z corner at the target coordinate, offsetting the East and South quadrants by 64 blocks on their respective axes aligns the seams without gaps or overlaps.

tickingarea add ~ ~ ~ ~128 ~ ~128 fortress_load true
structure load mypack:fortress_nw ~ ~ ~
structure load mypack:fortress_ne ~64 ~ ~
structure load mypack:fortress_sw ~ ~ ~64
structure load mypack:fortress_se ~64 ~ ~64
tickingarea remove fortress_load

If your add-on already uses the `@minecraft/server` module, the `StructureManager` class (accessed through `world.structureManager`) gives you programmatic control over placing `.mcstructure` files from your behavior pack or generating them in memory. While `createFromWorld` still enforces size boundaries during capture, `place` makes it trivial to loop through a 2D or 3D array of structure slices and calculate the offsets dynamically.

You can also spread the `place()` calls across multiple ticks using `system.runTimeout` if a massive build causes a noticeable hitch when placed on low-end devices.

import { world, system } from "@minecraft/server";

export function placeFourQuadrants(dimension, origin) {
    const slices = [
        { id: "mypack:fortress_nw", dx: 0, dz: 0 },
        { id: "mypack:fortress_ne", dx: 64, dz: 0 },
        { id: "mypack:fortress_sw", dx: 0, dz: 64 },
        { id: "mypack:fortress_se", dx: 64, dz: 64 }
    ];

    slices.forEach((slice, index) => {
        system.runTimeout(() => {
            const target = {
                x: origin.x + slice.dx,
                y: origin.y,
                z: origin.z + slice.dz
            };
            world.structureManager.place(slice.id, dimension, target);
        }, index * 2);
    });
}

When generating custom structures naturally in the world, you should never rely on a single oversized `.mcstructure` file. World generation runs per-chunk; if a single `minecraft:structure_template_feature` extends far outside the currently generating chunk and its immediate neighbors, parts of the build will either fail to place or get overwritten as adjacent chunks generate.

For predictable, non-random multi-part structures in worldgen, combine several `minecraft:single_block_feature` or `minecraft:structure_template_feature` files using a `minecraft:aggregate_feature` alongside `minecraft:scatter_feature` files that apply fixed coordinate offsets. For randomized, sprawling structures like dungeons or towns, place Jigsaw blocks on the edges of your 64x64 slices so the engine links them together piece by piece as chunks generate.

{
  "format_version": "1.13.0",
  "minecraft:structure_template_feature": {
    "description": {
      "identifier": "mypack:fortress_west_slice_feature"
    },
    "structure_name": "mypack:fortress_nw",
    "adjustment_radius": 0,
    "facing_direction": "south",
    "constraints": {}
  }
}

Applies to Bedrock Edition 1.18.0 and later (where build height expanded to 384 blocks). The `world.structureManager` API is stable in `@minecraft/server` 1.12.0 and later (Bedrock 1.21.0+) and requires no experimental toggles.

Read out of the game itself, so the ids match the version you are building for.