erroneous stability calculation

[White-Gandalf]

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):

 

Further experiments revealed that those "unlimited towers" as described in Bug (1) are only possible in randomly generated world. If you start a session in the navezgane world, those towers are not possible. There, the collapse of towers gets correctly calculated.

 

Thus arises the suspicion that the "unlimited tower" bug stems from a quick and dirty workaround for collapsing POI's in the Alphas since A17. Back then, collapsing POI's were a common appearance in all randomly generated worlds. I can perfectly well imagine that the funpimps simply limited the stability calculation as long as you play on such a randomly generated world to quickly get rid of those game breaking bugs. And that those code lines got preserved because they went out of focus.

 

 

Just another P.S.: Since more videos emerge on youtube these days about this family of buggy stability calculation, there are proposals that these bugs would have emerged only with the current A20. I can assure - from tampering with them explicitly in A19 - that these bugs are NOT new to this Alpha version. They were very probably already build in at least with Alpha 15, but back in those days i had no clue what the collapses resulted from, and i had no knowledge of the debug menu. But the manifestations of the phenomenons were rather equal to what we see today: structures with very high redundancy in structural integrity suddenly collapsing for no apparent reason.

 

=================

 

Just another bug from the same group of bugs...

 

expected behavior: IF you are able to attach a block further OUT at a hanging structure, attaching that same block further IN to the supporting point should never be impossible!

experienced behavior: The complete @%$# you can see in the video. It curls up my toenails when i try do describe that @%$# with words

 

 

======================

 

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.

Edited January 12, 2022 by White-Gandalf (see edit history)

[White-Gandalf]

Out of couriosity, i went back to previous alphas to compare the bugs....

 

For a more simple notation, i define shortcuts for the mentioned bugs:

 

VS: vertical stability bug (instantiating connection to bedrock does not propagate bedrock support vertically upwards)

VC: vertical chunk bug (stacking more than a chunk height of blocks disables weight calculation further up)

BS: bridge building bug (combining heavy and light blocks horizontally beside each other leads to collaps far below glue value)

 

          VS        VC           BS

A20    bug      bug        bug

A19    bug      bug        bug (going upwards in versions, the versions with the most accumulated bugs so far)

A18    OK        bug (1)  bug

A17    OK (2)  bug        OK

A16    OK        bug (1)  OK   (going backwards, the version with the most correct functionality so far!)

A15    OK        OK         bug

 

(1) vertical chunk bug in A16 and A18 does not allow horizontal deviation of more than 1 block; in A17, A19 and A20, you can go up to 15 blocks aside; other than that, it was the same in A16 and A18 (unlimited vertical stacking)

 

(2) vertical stability was buggy in A17, but it healed itself correctly as soon as any block was attached to or removed from any of the wrongly calculated blocks (the whole stack of blocks in vertical up direction was corrected at once)

 

Remarkably, the VS bug was absent in A18, and was existing but autohealing in A17 (thus altering in its appearance multiple times).

Remarkably, the VC bug was multiple times temporarily altered (not removed), but reappeared afterwards exactly as before.
Remarkably, the BS bug was temporarily corrected in A16, but reappeared in A18 exactly as it was in A15.

Remarkably, for the BS bug, the location of the attach position that leads to collapse was the exact same in all versions where the bug was existing, despite being gone for two versions in between. That leads to the suspicion that chunks of buggy code were preserved and reinstated. And in that, multiple times on multiple vectors independently from each other.

 

Guys: What the heck are you doing with your code base?!? What drugs are you on?!? Alternately, you can roll on the floor from laughing.

 

Edited January 8, 2022 by White-Gandalf (see edit history)

[White-Gandalf]

Thus goes the saying: Everything was better back in the old days!

[mnbnbf]

Why are you posting here instead of the bug forum? I ask because though these stability bugs have been here apparently for multiple patches, it is not listed on the known bugs list. I have posted a link to this thread with an included message about the other bugs you have posted to the bug forum.

 

https://community.7daystodie.com/a20-bug-database/bug-pool/

 

[BFT2020]

They actually know about it and 20.1 (Exp) has fixes in it that hopefully address the issue