White-Gandalf
Refugee
- Version
- 2.0 (b285)
- Platform
- Windows
Like the stability bug that was fixed in A19, this bug goes about a missing stability calculation propagation. This time the bug looks like an exact inverse of that old one:
While up to A19, when you built DOWN (thereby changing blocks beneath something already existing above it), the stability update was not propagated upwards - unless you changed some block above the added lower block,...
...in Release V2, when you build UP (thereby changing blocks above something already existing beneath it), the stability update is not propagated downwards - unless you change some block beneath the added block above.
In the latter (and newer) case, the problem is, of course, relevant only for columns of blocks that have no bedrock support. (If they have bedrock support, all blocks in the growing column have, of course, perfect stability.)
In my case, the problem arises for some construct that is hanging (with quiet sufficiently - about 1000% - overpowered weight support) between support walls.
I have two videos that have documentation about that bug, currently rendering. I will add links to them as soon as they are uploaded.
At first, i attributed the behavior to the limit on allowed hanging blocks (of 15), but that is not fitting: If it were, during the building, there would have been a feedback to the player about the degrading stability by changed color of the placement preview (from white over yellow, red to black). This feedback was not existent in the case that i encountered: While building upwards, all block placement previews always showed white color, and the building actions were successful.
Only after going down and removing (completely irrelevant for holding anything up) scaffolding that was attached to the buildup structure, the top of the structure began to crack.
After some brain quirling, i went into debug mode and began analyzing the stability display. And only in the video editing of these actions in the stream, i realized the bug which was visible only for a few frames after switching stability display on: The display, in the first few frames, was such that one of the walls where i had not yet completely removed the scaffolding was displayed in uniform bright yellow, indicating that all blocks "hanging" upwards were calculated with the exact same stability value - which is wrong, of course, since they are all "hanging" and the "hang" gets the farther away from the anchoring point the higher the blocks are in the column, since the anchoring point is at the foot of the column.
However, after some frames (thus some tenth of a second), the wall in question got a stability calculation update, which obviously had been triggered by the activation of the stability display. It then went from "uniform bright yellow" to "linearly darker red upwards" - like all other walls where i already had previously removed all scaffolding.
The latter is the evidence that the calculation during buildup was wrong (for all walls of the structure), as long as none of the already set lower blocks was ever touched again, and was corrected as soon as one of the lower blocks got changed (either by replacing it, or by removing something attached to it - for example scaffoldings) or by switching on the stability display.
Thereafter i repeated steps of changing blocks in a column of the (hanging) wall upwards and downwards, and could successfully repeat that behavior while incrementally changing the blocks: When i changed them upwards, the calculation got wrong again: Whenever i destroyed a block one step upwards and replaced it with the same block, its stability value became the exact same color as that of the underlying block. As soon as i touched a block beneath (for example by attaching something to it, then taking it away), the colors of the blocks in the column above became corrected again (so that they got a color gradient into dark red with higher positions). This whole behavior thus has been affirmed as a bug.
While up to A19, when you built DOWN (thereby changing blocks beneath something already existing above it), the stability update was not propagated upwards - unless you changed some block above the added lower block,...
...in Release V2, when you build UP (thereby changing blocks above something already existing beneath it), the stability update is not propagated downwards - unless you change some block beneath the added block above.
In the latter (and newer) case, the problem is, of course, relevant only for columns of blocks that have no bedrock support. (If they have bedrock support, all blocks in the growing column have, of course, perfect stability.)
In my case, the problem arises for some construct that is hanging (with quiet sufficiently - about 1000% - overpowered weight support) between support walls.
I have two videos that have documentation about that bug, currently rendering. I will add links to them as soon as they are uploaded.
At first, i attributed the behavior to the limit on allowed hanging blocks (of 15), but that is not fitting: If it were, during the building, there would have been a feedback to the player about the degrading stability by changed color of the placement preview (from white over yellow, red to black). This feedback was not existent in the case that i encountered: While building upwards, all block placement previews always showed white color, and the building actions were successful.
Only after going down and removing (completely irrelevant for holding anything up) scaffolding that was attached to the buildup structure, the top of the structure began to crack.
After some brain quirling, i went into debug mode and began analyzing the stability display. And only in the video editing of these actions in the stream, i realized the bug which was visible only for a few frames after switching stability display on: The display, in the first few frames, was such that one of the walls where i had not yet completely removed the scaffolding was displayed in uniform bright yellow, indicating that all blocks "hanging" upwards were calculated with the exact same stability value - which is wrong, of course, since they are all "hanging" and the "hang" gets the farther away from the anchoring point the higher the blocks are in the column, since the anchoring point is at the foot of the column.
However, after some frames (thus some tenth of a second), the wall in question got a stability calculation update, which obviously had been triggered by the activation of the stability display. It then went from "uniform bright yellow" to "linearly darker red upwards" - like all other walls where i already had previously removed all scaffolding.
The latter is the evidence that the calculation during buildup was wrong (for all walls of the structure), as long as none of the already set lower blocks was ever touched again, and was corrected as soon as one of the lower blocks got changed (either by replacing it, or by removing something attached to it - for example scaffoldings) or by switching on the stability display.
Thereafter i repeated steps of changing blocks in a column of the (hanging) wall upwards and downwards, and could successfully repeat that behavior while incrementally changing the blocks: When i changed them upwards, the calculation got wrong again: Whenever i destroyed a block one step upwards and replaced it with the same block, its stability value became the exact same color as that of the underlying block. As soon as i touched a block beneath (for example by attaching something to it, then taking it away), the colors of the blocks in the column above became corrected again (so that they got a color gradient into dark red with higher positions). This whole behavior thus has been affirmed as a bug.
- Reproduction Steps
- 1. Build a column hanging between (or at the side of) some bedrock support columns!
2. As long as the attachment of the hanging column consists of sufficiently many block surfaces (the necessary number of which i have not yet determined; i used 8 in my setup), the stability of the blocks you place on the hanging column will never change. You may extend the hanging column indefinitely - far beyond the nominal stability limit. It will hold.
3. As soon as you attach something to a block at the bottom of the hanging column and remove it afterwards, the stability values of the hanging column from that block upwards will update, and the columns will collapse as far as the stability limit is exceeded.
- Link to Logs
- https://pastebin.com/rxNdxy5J
- Link to Screenshot/Video
- https://www.twitch.tv/videos/2490012880