1. KardinalZyn (https://www.twitch.tv/kardinalzyn) realized a bugged stability calculation with his castle build:
Attaching at least two blocks on top of each other to the side of some supporting column, you can stack unlimited load on top of that attached blocks.
I confirmed this bug using wood blocks.
expected behavior: You should not be able to stack more than 80 load on top of two wood blocks hanging from anywere (40 for each of them, amounting to 16 resp. 8 blocks of wood). The "stability color" of blocks hanging anywhere in the "show stability" debug view should go to deep red the higher the blocks stack. After exceeding the glue force, the hanging column should collapse.
experienced behavior: You can stack unlimited wood blocks in vertical up direction. The "stability color" in the "show stability" debug view keeps being CONSTANT for all hanging blocks in vertical up direction. See picture!
(P.S.: After further experiments, i realized that the "stability color" in the "show stability" debug view SHALL HAVE nothing to do with weights, but solely hints at the horizontal distance from the nearest supporting column. As with current buggy behavior, under certain circumstances, blocks get vertically miscolored because of bug (3). As soon as bug (3) gets fixed, the different coloring in vertical direction should disappear!)
You can repeat that sideways attachment on the "impossible" hanging tower. You can repeat that up to 15 times with wood/concrete/steel blocks (well: limited by the height of the world model, but not otherwise).
Example attached as picture.
2. That is not the only bogus appearance of stability calculation.
While building the "Völkerschlachtdenkmal von Leipzig" project, together with AsmodisdeSanktis (https://www.twitch.tv/asmodisdesanktis) i discovered that vertical support does not get recalculated after removing supporting blocks under a front of blocks that afterwards was hanging on a thin line of a single block height that was by multiple times too weak to hold the weight of the front of blocks. Only after going into debug mode and forcing "recalc stability", the front of blocks got colored in deep red.
3. Thereafter we discovered the next bug in stability calculation: After reinstalling support pillars under the hanging block fronts, were the supporting pillars have uninterrupted connection to bedrock, the stability for the blocks vertically above that newly reinstated pillar get a wrong stability calculation - as if they were not going up on the support column, but as if they were hanging sideways from the last inserted block of the support pillar.
expected behavior: ALL blocks vertically above any block with uninterrupted connection to bedrock ARE blocks that have uninterrupted connection to bedrock as well. All those blocks should be colored deep green in the "show stability" debug view.
experienced behavior: ALL blocks vertically above the last block of a newly reinstalled pillar with uninterrupted connection to bedrock are calculated as if they were hanging sideways from said last block.
This is essentially the inverse to bug (1) and (2): In THOSE, the hanging load does NOT get SUBTRACTED from the remaining load potential, thus leaving the blocks above with much too strong load support.
In the case of bug (3), the unlimited support from bedrock does not get propagated to the blocks directly vertically above the last block inserted after reaching previously hanging blocks, thus leaving the blocks above with far too weak load support.
Here is the video where at the beginning, i investigate bug (3):
======================
P.S.: Just another stability bug...
Sometimes, blocks show up having purple placing frames, suggesting that the thing would not be placeable. Despite no restriction on placeability at all.
I had have this type of bug on the terrain floor after removing the upper layer of top soil. But only on certain tiles, not everywhere.
And i had have it on certain occasions while placing forges and workbenches in my fortress:
All is well placeable, nothing gets destroyed. Nonetheless, the purple frame suggests it would be destroyed when placed.
Attaching at least two blocks on top of each other to the side of some supporting column, you can stack unlimited load on top of that attached blocks.
I confirmed this bug using wood blocks.
expected behavior: You should not be able to stack more than 80 load on top of two wood blocks hanging from anywere (40 for each of them, amounting to 16 resp. 8 blocks of wood). The "stability color" of blocks hanging anywhere in the "show stability" debug view should go to deep red the higher the blocks stack. After exceeding the glue force, the hanging column should collapse.
experienced behavior: You can stack unlimited wood blocks in vertical up direction. The "stability color" in the "show stability" debug view keeps being CONSTANT for all hanging blocks in vertical up direction. See picture!
(P.S.: After further experiments, i realized that the "stability color" in the "show stability" debug view SHALL HAVE nothing to do with weights, but solely hints at the horizontal distance from the nearest supporting column. As with current buggy behavior, under certain circumstances, blocks get vertically miscolored because of bug (3). As soon as bug (3) gets fixed, the different coloring in vertical direction should disappear!)
You can repeat that sideways attachment on the "impossible" hanging tower. You can repeat that up to 15 times with wood/concrete/steel blocks (well: limited by the height of the world model, but not otherwise).
Example attached as picture.
2. That is not the only bogus appearance of stability calculation.
While building the "Völkerschlachtdenkmal von Leipzig" project, together with AsmodisdeSanktis (https://www.twitch.tv/asmodisdesanktis) i discovered that vertical support does not get recalculated after removing supporting blocks under a front of blocks that afterwards was hanging on a thin line of a single block height that was by multiple times too weak to hold the weight of the front of blocks. Only after going into debug mode and forcing "recalc stability", the front of blocks got colored in deep red.
3. Thereafter we discovered the next bug in stability calculation: After reinstalling support pillars under the hanging block fronts, were the supporting pillars have uninterrupted connection to bedrock, the stability for the blocks vertically above that newly reinstated pillar get a wrong stability calculation - as if they were not going up on the support column, but as if they were hanging sideways from the last inserted block of the support pillar.
expected behavior: ALL blocks vertically above any block with uninterrupted connection to bedrock ARE blocks that have uninterrupted connection to bedrock as well. All those blocks should be colored deep green in the "show stability" debug view.
experienced behavior: ALL blocks vertically above the last block of a newly reinstalled pillar with uninterrupted connection to bedrock are calculated as if they were hanging sideways from said last block.
This is essentially the inverse to bug (1) and (2): In THOSE, the hanging load does NOT get SUBTRACTED from the remaining load potential, thus leaving the blocks above with much too strong load support.
In the case of bug (3), the unlimited support from bedrock does not get propagated to the blocks directly vertically above the last block inserted after reaching previously hanging blocks, thus leaving the blocks above with far too weak load support.
Here is the video where at the beginning, i investigate bug (3):
======================
P.S.: Just another stability bug...
Sometimes, blocks show up having purple placing frames, suggesting that the thing would not be placeable. Despite no restriction on placeability at all.
I had have this type of bug on the terrain floor after removing the upper layer of top soil. But only on certain tiles, not everywhere.
And i had have it on certain occasions while placing forges and workbenches in my fortress:
All is well placeable, nothing gets destroyed. Nonetheless, the purple frame suggests it would be destroyed when placed.
Last edited by a moderator:
