Multiblocks, take 2

[kpreid]

The currently partially implemented scheme of multi-block structures is that each one is a Block which contains the entire structure, and when it is placed in the world, a Zoom modifier is used to create each individual block. This has several disadvantages.

• Most fundamentally, it limits the (size × resolution) of the structure to the maximum Block resolution.
• Evaluating the structure blocks potentially involves repeatedly evaluating the entire structure, if there is no intervening evaluation cache. This could be addressed in part by adding a region-of-interest to the EvalFilter so that the rest isn't needed.
• If the multiblock has repeated elements, they have to be distinct Blocks even if their evaluations are identical.

Considering all these factors, I think we need a different system. It should still be possible for a single Block to stand in as a proxy for the whole, but the multiblock placement should be based on explicitly configured data. I'm not sure exactly how that should work yet, or even where the data lives — should it be an attribute? a modifier? a primitive? Should there be a MultiBlockDef universe member type?

We also need to actually design and implement multiblock placement rules; right now, everywhere it's done is a hand-coded operation in worldgen, not a game rule.

[kpreid]

Most fundamentally, it limits the (size × resolution) of the structure to the maximum Block resolution.

Revisiting the definition of Zoom, I see I intended that it would optionally take voxels directly from some Space. This would mean no resolution constraint or extra evaluation costs, but needs the placement rule to know that Space in particular to create the Zoom instances.