Pistons and movestones damage unloaded blocks

[numberZero]

From #411:

• Piston:
  • A piston that extends or withdraws in an inactive block still pushes or pulls nodes in that block.
  • A piston can’t try to extend or withdraw while it, itself, lives in an unloaded node, because the conductor would have loaded its > block.
  • A piston that tries to extend its pusher into an unloaded block loads the block part way through processing, but the pusher > replaces, rather than pushing, the block it finds there; it doesn’t actually invoke that node’s destructor, either; it just unceremoniously wipes it from existence (this happens because ignore is considered MVPS-replaceable, replaceables are not included in the stack to push, and then piston_on uses set_node (which seems to load the block) to place the pusher) and replaces it with the pusher.
  • A piston that tries to withdraw its pusher from inside an unloaded block loads the block from which it is withdrawing. If the piston is sticky, it pulls the next node.
  • A piston whose pusher does not enter an unloaded block, but tries to push a node into an unloaded block, acts like the piston extending into unloaded block case above, unceremoniously wiping the node that used to exist in the unloaded block from existence and replacing it with the pushed node.
  • An extended sticky piston whose pusher is touching an unloaded block, on withdrawing, doesn’t pull anything, instead unsticking itself from the node it would normally have pulled. If it later extends and the adjacent block is loaded, it resticks.
  • If an extended piston whose pusher is in an inactive or unloaded block retracts, the node that stops being supported does not fall. If the pusher then extends with the block still being inactive or unloaded, the node remains on top of the pusher. If the block becomes active while the pusher is withdrawn, the node falls (I’m not sure why this last sentence happens, but it does).
• A movestone works like a piston with the following differences:
  • There is no pusher, so everything that refers to the piston and pusher being in different blocks is irrelevant.
  • If a movestone tries to move from a loaded block to an unloaded block, it unceremoniously wipes from existence the node whose space it moves into, rather than pushing it.
  • A sticky movestone that tries to pull a node from an unloaded block leaves it behind, whether the block is directly or indirectly attached.

[Desour]

I guess making ignore to a mvps stopper could maybe help. But that wouldn't help with the sickies. Perhaps add mvps pull stoppers and make ignore one of them?

[numberZero]

Someone too clever included significant changes in a merge commit c98805a. Namely, he set ignore to be replaceable.

[numberZero]

mvps pull stoppers

Don’t current stoppers prevent pulling as well?

[Desour]

I'm not sure but I thought the stack is split.

[numberZero]

Tested. The stack is not split but left behind entirely.

[Desour]

Ah, good to know.

So, the pistons and movestones should have another behavior for this cases. Movestone is easy, just don't move but the piston should not really stay open without a signal.

[numberZero]

1. Both are using the same code for pulling nodes.
2. Either way, things will go out of sync.

The “correct” solution is to load the surrounding blocks as necessary. That way, things will always work properly. But there are disadvantages as well:

1. That’s lag-prone.
2. For movestones, a block has to be loaded continuously and not only on signal change. That’s very lag-prone, and effectively gives the possibility to anchor a block (not in active state, fortunately). Otherwise, things will lose sync anyway.

[fluxionary]

Though neither PR fully handles buildable_to nodes that are MVPS stoppers (or conditional stoppers), that's probably fine, IMO.

One thing that isn't handled, however, is that you can still e.g. blow up the ignore nodes w/ tnt and then push blocks into them. That might be considered a bug w/ the default tnt mod, though.

[numberZero]

When you blow nodes up they become air, I suppose, so pushing into that is totally expected.

[fluxionary]

Except that the nodes are now outside the loadable world, and players or admins can't interact w/ them normally. It's still possible to excavate a "tunnel" to the actual s16 world limits using TNT & mesecons.

[numberZero]

@fluxionary That is actually engine bug that it allows accessing nodes outside the map limit (aka MAX_MAPGEN_LIMIT round down to block size)

[fluxionary]

This seems to be the existing status of that issue:

https://github.com/minetest/minetest/issues/8909

[numberZero]

Fixed with #545.