Support a "void block" as part of the palette

[octylFractal]

Right now the schematic format is limited to cuboids, as the region of blocks is only defined by a length, width, and height. This limits WorldEdit from storing custom shapes of regions into the schematic, resulting in a lossy storage format (clipboards in WorldEdit support non-cuboid regions). The alternative we are thinking of fixing this in WorldEdit is storing WorldEdit metadata into the schematic representing the region, but there is also a more generic proposal that might fit into the specification.

I propose that a special block type be added to the format that represents the same as Minecraft's structure_void does for structures -- an element of the palette that should not be considered part of the content to be pasted, modified, etc. This would be stored as if it were a real block, but it would simply be ignored when actually using the block data. I think that either sponge_schematic:void or !void (to emphasize it's non-block identity) would be reasonable choices.

This would allow WorldEdit to simply persist this void block outside of the region, and filter it out upon loading as well.

Alternatives

• WorldEdit could just store the region in custom metadata
• WorldEdit could implement this proposal using worldedit:void, but then it would likely become a de-facto standard regardless, but now "tainted" with a specific implementation's name
• The format could define regions instead, but this would be a much more complex specification than just "if block == void, drop it"
• The format could define masks, but this is even more complicated than regions 😛

[gabizou]

Thinking about this, I'd prefer a more refined solution:

Block pos mapping of "replacement types" something akin to the following:

• Void Replace this block with whatever exists in the world
• LiquidReplacement Replace this block if there exists a liquid in place already
• SolidReplacement Replace this block if a solid already exists
• MaterialSameness Somewhat fuzzy but essentially based on the tag system in Minecraft, if a block of the same tag exists, replace with that block, otherwise retain schematic defined block

This would drastically or potentially be either a list of pos -> replacement strategy or a full blown array much like the schematic itself. Likely dependent on the schematic size, but as you can imagine, I'm inclined to maintain the list of replacements being the approach, since this has no bearing over the in-memory/platform dependent models.