Steps to Reproduce:
Place a block (considerably far) above you;
Stack multiple stalactites under it, leaving two blocks of space for you to fit;
Be under the stack and break them (by using redstone or the help of another player).
Observed Results:
You only get half a heart of damage. The behavior is also inconsistent sometimes.
Expected Results:
Each stalactite adds up, capping at 5 times more than the base damage. See the attached pictures for a visual explanation.
Screenshots/Videos attached: Yes
Notes: Each added pointed dripstone adds up the same damage as the base instead of the damage it would deal if it were falling from that distance.
Attachments
Comments 7
I believe this is fixed in 1.17.0.52. Now getting up to 3 hearts of damage from really long stalactites.
Can confirm that I only receive a maximum of three hearts of damage from the longest stalactites and fewer hearts of damage for the smaller ones. This is consistent with the graphic for Java presented in the original description. I therefore believe that this report can be closed. (1.18.2 on iOS)
After testing, I found that:
As with the comments (by kmb and user-01fa9) described, Mojang had tried to fixed this.
Currently, in bedrock edition, if there's no other scheduled tile tick in the same gametick, the behaviors are THE SAME with the attached image for Java (JAVA.png).
However, the image for Java Edition (JAVA.png) is outdated. In 1.18.2, the damage in Java Edition was changed. There is another issue for the new inconsistence after java 1.18.2: MCPE-184329.
So, the two images should be updated to:
[media][media][media]
The videa shows the behavior when there's no other scheduled tile tick in the same gametick.
However, if there're other blocks having scheduled tile ticks in the same game time, it works not as the image. Due to MCPE-16371, the game cannot make sure that the tip block is ticked first. As a result, when the tip checks the amount of pointed dripstone blocks, some of them has been a falling block entity, which happens when the total amount of scheduled tile ticks in the same gametick is greater than 4.
So, now this is an issue caused by MCPE-16371.
I can confirm DI's findings in this sense: the inconsistencies observed in the test world are caused by the use of a piston to remove the dripstone_block. If you use a command to destroy the dripstone block then the expected behavior occurs.
I do not agree that MCPE-16371 explains why a piston triggers the inconsistency. That report covers only the randomized update order of hoppers, pistons, and observers. If the update order of dripstones converting to falling blocks were random then (a) multiple uses of the same station in the test world would give different results, and (b) all stations except the first (single dripstone) would be inconsistent. Neither of these effects occur.
I believe the cause here is that the piston's check for moveable blocks triggers a change in the update order of nearby blocks. As DI observes,
the inconsistency occurs only where there are >4 dripstones hanging from the block that the piston moves.
I have also found that
the bug does not occur if the piston is moving a group of slime blocks:
[^MCPE-119542.mcworld]
[media][media][media][media][media][media][media]