Snapping SBB Children

[ikabod-kee]

Demonstration:

The crimson SBBs have a "gravitate" feature, as specified in the zig.zon file.

When generated in the world, they will snap directly to the terrain.

[ikabod-kee]

This would be perfect for multi-structures like fairy rings, groves, fallen trees, and etc.

[Argmaster]

I would suggest calling it snap and allow all directions of snapping so it can be used also for stuff hanging from ceiling, maybe something sticking out of a wall. As a first step I would want it as a command on Blueprint, then we will see. But that's after masks and substitutions.

[Argmaster]

Actually, I changed my mind about bluepirnt snap command, it is irrelevant, it has to be separate implementation, but the name should remain.

[IntegratedQuantum]

maybe something sticking out of a wall.

Note that this is significantly more expensive than up and down snapping, so I'd suggest to limit it to those two.

[Argmaster]

In caves it should not be, and for other use cases we can discard them in review, while addons can do whatever they like.

I need to think what will be the restrictions on snapped blueprints, remember that after loading we no longer have child blocks in the blueprint, so it has to use SBB metadata for that, hence it won't snap all the blocks in blueprint, so what it should do if replacing non-air/non-food block in blueprint? I would prefer to restrict those to only have void, child and origin blocks and have them as separate category called generators. This would give context and rules to aggregator structures @ikabod-kee created in #1382, they should not paste their blueprints to avoid wasting time, instead they can snap, rotate children and would immediately start pasting children instead. This would also resolve problem with rotation of children of children, you would allow random rotation only for generator children.

[IntegratedQuantum]

In caves it should not be, and for other use cases we can discard them in review, while addons can do whatever they like.

Accessing the ceiling/floor is O(1), finding the wall is O(n), where n is the distance to the wall.

[IntegratedQuantum]

hence it won't snap all the blocks in blueprint

It would just move the entire child structure of the snapped block to the snapped location.

[IntegratedQuantum]

I don't quite get what you propose here, or why it's needed. To me it seems like it would needlessly add a bunch of basically one-block entries in the sbb-tree.

[Argmaster]

I am not proposing much, mainly observing what users do with SBBs, and they are doing that: https://github.com/PixelGuys/Cubyz/blob/cb5262067747bafeca2598ce80c387add01c9cea/assets/cubyz/sbb/tree/birch/birch_forest_generator.zig.zon