Falling nodes not updating as before

[paramat]

Find some tunnels in a beach in mgv7 and try collapsing some unsupported sand, it will often update in small 2x2 or 3x3 columns or in larger sections but without updating some adjacent sections unsupported sand.
In latest master e661d8b

[sofar]

Adjacent how? Are they diagonally separated or actually touching faces?

[kwolekr]

@paramat, are you filing a bug report on this because falling node behavior isn't exactly the same as it was before, or is the new behavior actually causing problems with gameplay? We expected the behavior to be different.

[paramat]

Nodes that are touching faces often do not update, i did remember that diagonals will now not update by design and i'm fine with that. The intended 'update through faces only' seems unreliable.

Indeed i considered whether it was acceptable, but no longer do we get a beautiful chain-reaction of a large volume of nodes, which is a lot of fun. Often just a single column or a single plane will fall, or a limited section like 2x2 or 3x3, often without updating face-connected unsupported nodes. It's just a little too tame now.

[sofar]

In order to discuss, we should really have something the same to look at, preferably a video.

[sofar]

I'm actually OK with it being a little more tame.

As for things falling all at once, just youtube search for "snowboarder cause avalanche" and look at how the snow starts off falling all at once as a single massive block.

The old code inserted timer events, but as noted before these cause more overhead and by themselves will degrade performance drastically. There's also the difficulty of deciding when to insert timer steps, as they don't fit in the current algorithm (at all). Even if we'd insert timers there's a high probability that we'd visit the node through the walking algorithm before it would get visited by the timer event.

[PilzAdam]

I'm actually OK with it being a little more tame.

I am not. I would have 👎'd your PR if I knew that it would be more "tame".

I observed that a structure of sand floating in the air like this:

XXX
X

won't completely fall down if the player digs the rightmost node. This is not doesn't make much sense, since the all nodes are floating in the air.

I'm not sure if your new algorithm is fixable. Maybe always check down a few nodes more? At least in this case it would cause the node in the top-left corner to update the node below it, so that the complete structure falls down.

[est31]

I don't like tame fire and I don't like tame falling nodes.

[paramat]

I observed that a structure of sand floating in the air like this:

XXX
X

won't completely fall down if the player digs the rightmost node. This is not doesn't make much sense, since the all nodes are floating in the air.

This happened to me too, only 1 node fell.
Go test for yourselves with a tunnel in a mgv7 beach.
Perhaps no need for all 26 neighbours to be updated, maybe just a few more. However even updating through the 6 face-connected nodes very often fails.

[Ekdohibs]

Hm, didn't the bug exist before with such a configuration then? (When the player dug the rightmost node)

XXX
X
X

[sofar]

Off the top of my head, the old algorithm would have made all the nodes fall in this case:

(Z) is the node updated (e.g. torch attached)

XXZ
X

But it would not have in this case:

MXZ
N
O

That is because from Z it would move to X and then attempt to drop M and N, and both would be stuck, at which point it would never get to O, so only X and Z would fall.

I'm actually OK with re-adding the downwards diagonals back into the matrix so that the first scenario would see all nodes falling. But the second scenario isn't fixed unless you walk the full extent of nodes that are falling, which could be endless

[sofar]

#3995

[paramat]

#3995 is merged.