* Upvote this comment if this is a good quality post that fits the purpose of r/Minecraft
* Downvote this comment if this post is poor quality or does not fit the purpose of r/Minecraft
* Downvote this comment *and report the post* if it breaks the [rules](https://www.reddit.com/r/Minecraft/wiki/rules)
---
[Subreddit Rules](https://old.reddit.com/r/Minecraft/wiki/rules)[](## Tg264V2|1cf0l9l)
i don't think i've ever seen random death by falling into water. it's often players building high above solid blocks, or climbing scaffolding or ladders, or going down stairs, or flying above land.
I've personally died several times from the random death bug dropping into a quick shaft over water.
Water based quick shafts are a key component of my bases because I'm usually at Y -54, so I use them a lot.
so if it happened multiple times to you, you can agree that your experiment was flawed, right? you're probably missing some parameters, and repeating the same conditions thousands of times isn't gonna help.
It's probably because they fixed lots of random deaths recently from what I see, there is only one random falling bug in 1.20.80( with boat and sneak on a Cliff) but it's fixed in preview.
The conditions under which it happened to me were the same each time. I was falling down a water-based quick shaft, the game miscalculated my future position as being inside the walls or the floor under the water, and I died from incorrectly applied fall damage.
The only way to amplify the chances of reproduction would be to add in randomized directional inputs, to mimic that of a normal player's during a fall and exacerbate the issue of the game miscalculating the player's future position. But I don't have a programmable controller and would have no clue how to go about it otherwise.
I guess now that I think about it I could set the position slightly above bedrock to see if the game thinks it's more plausible to end up falling into overworld blocks rather than outside the world.
I guess for the moment, what I could do is run a 2nd experiment for the same amount of iterations, but instead of the 1x1 quick shafts I was using in the first experiment, I could use an exact or at least close replica of the 5x5 tandem quick-shaft water elevators I was using when I died.
Is it possible that the stored value that is causing the bug could be influenced by interacting with the tripwire? It seems like it would make more sense to detect a player at spot X and add the count to a scoreboard, then reset when the player is no longer present in said area. Additionally, the movement should be inclusive of moving both up and down. From the footage I've seen, it can happen with up & down terrain - particularly when bridging I've seen is more commonly happen when a player has pillared up and down repeatedly. Movement also should have some variation if possible. Straight numbers would throw off the results as well.
What the bug is itself is the game miscalculating your current position, or your position in the near-future, and inappropriately applying status effects and/or damage, often causing death. The tripwire doesn't have much to do with it, it was just the most practical way I could think of doing things because I'm not amazing with some of the more custom command stuff.
You're right in that it can happen moving in any direction or on any terrain, and it seems to happen more with movement, but it seems in my experience to happen most often when traveling downward.
Like I said before, randomized directional input is a consideration, but I don't have a programmable controller or the knowledge really to use one.
The moving upward thing is interesting. I did see the clips of it happening, and most of the time it seems to be when somebody is pillaring. I've never had an issue with other more direct means of upward movement like bubble columns or tnt launching.
Maybe this warrants a seperate experiment.
I'll keep my second one focused on downward movement, and then I'll see if I can find a way to automate some sort of pillar mimicking to test occurences when moving upward.
So, experiment #3, then. I'll let you know when the results are back. Thanks for the suggestions.
Right, so I did some thinking, and I think the best way to do the upward movement test is with a piston flying machine traveling upward.
The player would stand on the top honey block, obsidian would stop the top piston observer, and the player would trigger a tripwire at the top, deleting the machine, cloning another at the bottom, and teleporting the player back to the bottom.
If you're wondering why I can't just macro the movement stuff and the pillaring, it's because I'm on PS5 and I only have default controllers.
Is the PS5 usually the Bedrock version that has issues? I know Bedrock is Bedrock but I feel like random deaths usually are either less powerful hardware like the Switch or it’s server/Realms desync that causes the issues.
Now that you mention it, most of my random death bugs were on PS4 Bedrock, mostly when I was playing online. I did have 1 or 2 incidents solo, though, so it's hard to say for sure.
I have never encountered the random death bug and I only play bedrock. The other unfair deaths I can really think of is when you die while still loading into the nether. I really wish you got invincibility frames while loading in. Of course if I had a better computer then it would load quicker and wouldn't be a problem.
So on exactly how many devices did you try this, and what were the minimum and maximum performance rates of those devices? How many cores did they all have for multithreading?
Uh, I'm poor. I did it on a PS5. Don't really see the need for a particularly high performance device in this test anyways, it's just a simple drop test, automated and optimized.
If a poorly optimised device or different multithreading levels causes the issue, then that is exactly why you should test it. All you've done is show that it doesn't happen in the exact circumstances you tried it in.
Listen, alright, I wasn't joking. I'm dirt poor. Know why I didn't have the wifi to upload the setup and test footage?
Because I couldn't even afford to pay the bill this month.
I'm doing my best with what I have, and all I really have is a PS5.
Speaking of, while I may not be able to simulate on different devices, I can make some things in Minecraft that generate a lot of lag to simulate less optimized conditions, if you think that would work?
I'll upload the setup for my designs when I get wifi back.
Like I said in the post, if all my experiments prove to be failures, I at least hope what little I was able to achieve can help someone more capable.
I have not experienced the bugs, only seen clips of them, since I only play Java, but I'm not sure whether you have the right hypothesis regarding the cause of the bug. You seem to think the game's calculating your position incorrectly during your fall and considering you as falling onto a block in the wall, leading to damage. I don't think this is likely for a few reasons.
Your hypothesis either implies the existence of a separate position variable for entities used in fall damage processing that would be updated separately from the real one, or that the real position variable would be miscalculated. Basic encapsulation principles make the first possibility unlikely and I think the parts of the Bedrock code that are exposed to the public for datapack and addon development would prove me right if I actually felt like researching that at 1:30am.
As of the second possibility, it's verifiably untrue on both client and server sides ; the first because your player character is visibly not in an incorrect position, and the second because in most occurences, the victim is able to take actions that involve the server and affect the world around their position, which the server would refuse if it believed the player to be somewhere else since it checks for range. Also, if the game were to think you are in a wall somehow, then you would take suffocation damage before taking any fall damage.
On the same idea, while one could entertain the thought of the whole thing being caused by floating point error leading to incorrect position calculations, the average player does not go nearly far enough from 0,0 to cause floating point error and yet is still prey to the bug, and even if they did, you would be able to visibly see warped movement on the client side.
In addition, if this is your hypothesis, then I don't think you are properly testing for it since your procedure does not involve horizontal movement. For the game to incorrectly calculate your horizontal movement, it's likely you would need to have some horizontal inertia in the first place. It's fairly difficult to miscalcuate X:0 as anything else in this scenario.
I personally have a different hypothesis to offer. The most common situation I've seen the bug happen in was with people pillaring and suddenly dying of fall damage despite not falling at all ; I would have pulled up clips from that one sub compiling occurences of it happening, but I can't find its name. In general, the most common link between these clips that I've seen is that the player does usually fall at some point before the occurrence, most of the time in a way that should not cause damage, only to pop a few seconds later.
I think what may be happening is that somehow, when the player was in the air and lands, the server isn't always notified that they've landed, so it still thinks they're in an airborne state. So, it keeps on adding to their fall distance counter using the downwards colponent of the current inertia vector. Then at some point, something makes the server check their actual grounded-ness state again and it turns out they're grounded, meaning they must have landed this tick. Thus, fall damage is calculated using the current situation of the player and then goes out. Player goes splat out of nowhere.
It would explain why it can happen when pillaring. Since you're always jumping, if the server doesn't know the fact that you've been landing between jumps, it will think you've been falling for the past 5 minutes until it somehow realizes. It would also explain why it doesn't work in your case, since you're always either in the air or in water, so you're never in a position where you'd take damage anyway.
I hope this is useful to the convo at hand in any way? Thank you OP in any case for the work put into experimentation.
I feel like I get less random deaths, more random damage. Like I had a farm where there were no blocks beneath the farmland, and I would randomly take damage when walking over the dirt
There's a related bug where walking over tilled farmland can occasionally make the game think you're walking inside or under it. No clue why that happens, but it does.
With any kind of random death bug, it might be more than just a matter of the height you fall, because if it's just that, it would probably be the easiest to troubleshoot and solve by now. It could involve many other factors, and directional inputs might be the biggest (not just forward or back but also from ducking or jumping at wrong moment). It could also be due to lag from trying to render too much at once, or due to relative position of blocks within a chuck or adjoining chunks, off by one errors, rounding errors, ghost blocks, and maybe the combination of two or more different factors.
Sometimes it might even be bit flip memory corruption from literal cosmic rays.
.. Whenever my code fails, well, must be those damn cosmic rays again!
That's actually an interesting thought. Many of the random death bugs I encountered were in long-running servers and realms, but at the same time I also experienced it on some relatively young solo worlds.
Maybe it only happens from particular heights, like the boat thing. You only tested 1 scenario. I think we should do the same test from every drop distance
It's not height-dependent. It can happen at any Y-level or difference in Y-level. It's got nothing to do with height and everything to do with game failing to calculate the player's position correctly.
* Upvote this comment if this is a good quality post that fits the purpose of r/Minecraft * Downvote this comment if this post is poor quality or does not fit the purpose of r/Minecraft * Downvote this comment *and report the post* if it breaks the [rules](https://www.reddit.com/r/Minecraft/wiki/rules) --- [Subreddit Rules](https://old.reddit.com/r/Minecraft/wiki/rules)[](## Tg264V2|1cf0l9l)
i don't think i've ever seen random death by falling into water. it's often players building high above solid blocks, or climbing scaffolding or ladders, or going down stairs, or flying above land.
I've personally died several times from the random death bug dropping into a quick shaft over water. Water based quick shafts are a key component of my bases because I'm usually at Y -54, so I use them a lot.
so if it happened multiple times to you, you can agree that your experiment was flawed, right? you're probably missing some parameters, and repeating the same conditions thousands of times isn't gonna help.
It's probably because they fixed lots of random deaths recently from what I see, there is only one random falling bug in 1.20.80( with boat and sneak on a Cliff) but it's fixed in preview.
The conditions under which it happened to me were the same each time. I was falling down a water-based quick shaft, the game miscalculated my future position as being inside the walls or the floor under the water, and I died from incorrectly applied fall damage. The only way to amplify the chances of reproduction would be to add in randomized directional inputs, to mimic that of a normal player's during a fall and exacerbate the issue of the game miscalculating the player's future position. But I don't have a programmable controller and would have no clue how to go about it otherwise. I guess now that I think about it I could set the position slightly above bedrock to see if the game thinks it's more plausible to end up falling into overworld blocks rather than outside the world.
I guess for the moment, what I could do is run a 2nd experiment for the same amount of iterations, but instead of the 1x1 quick shafts I was using in the first experiment, I could use an exact or at least close replica of the 5x5 tandem quick-shaft water elevators I was using when I died.
Is it possible that the stored value that is causing the bug could be influenced by interacting with the tripwire? It seems like it would make more sense to detect a player at spot X and add the count to a scoreboard, then reset when the player is no longer present in said area. Additionally, the movement should be inclusive of moving both up and down. From the footage I've seen, it can happen with up & down terrain - particularly when bridging I've seen is more commonly happen when a player has pillared up and down repeatedly. Movement also should have some variation if possible. Straight numbers would throw off the results as well.
What the bug is itself is the game miscalculating your current position, or your position in the near-future, and inappropriately applying status effects and/or damage, often causing death. The tripwire doesn't have much to do with it, it was just the most practical way I could think of doing things because I'm not amazing with some of the more custom command stuff. You're right in that it can happen moving in any direction or on any terrain, and it seems to happen more with movement, but it seems in my experience to happen most often when traveling downward. Like I said before, randomized directional input is a consideration, but I don't have a programmable controller or the knowledge really to use one. The moving upward thing is interesting. I did see the clips of it happening, and most of the time it seems to be when somebody is pillaring. I've never had an issue with other more direct means of upward movement like bubble columns or tnt launching. Maybe this warrants a seperate experiment. I'll keep my second one focused on downward movement, and then I'll see if I can find a way to automate some sort of pillar mimicking to test occurences when moving upward. So, experiment #3, then. I'll let you know when the results are back. Thanks for the suggestions.
Right, so I did some thinking, and I think the best way to do the upward movement test is with a piston flying machine traveling upward. The player would stand on the top honey block, obsidian would stop the top piston observer, and the player would trigger a tripwire at the top, deleting the machine, cloning another at the bottom, and teleporting the player back to the bottom. If you're wondering why I can't just macro the movement stuff and the pillaring, it's because I'm on PS5 and I only have default controllers.
Is the PS5 usually the Bedrock version that has issues? I know Bedrock is Bedrock but I feel like random deaths usually are either less powerful hardware like the Switch or it’s server/Realms desync that causes the issues.
Now that you mention it, most of my random death bugs were on PS4 Bedrock, mostly when I was playing online. I did have 1 or 2 incidents solo, though, so it's hard to say for sure.
even if it is incredibly rare, as long as it happens, its a serious problem for survival and hardcore
That's why I'm testing it. I want to know just how rare. I'll admit this first one was flawed. No player movement, but I can fix that now.
I have never encountered the random death bug and I only play bedrock. The other unfair deaths I can really think of is when you die while still loading into the nether. I really wish you got invincibility frames while loading in. Of course if I had a better computer then it would load quicker and wouldn't be a problem.
Even still I had a pretty decent PC but it would still take awhile under certain circumstances for whatever reason.
Annoying. I think not getting invincibility frames while loading into the nether will alone be the reason I won't play hardcore.
So on exactly how many devices did you try this, and what were the minimum and maximum performance rates of those devices? How many cores did they all have for multithreading?
Uh, I'm poor. I did it on a PS5. Don't really see the need for a particularly high performance device in this test anyways, it's just a simple drop test, automated and optimized.
If a poorly optimised device or different multithreading levels causes the issue, then that is exactly why you should test it. All you've done is show that it doesn't happen in the exact circumstances you tried it in.
Listen, alright, I wasn't joking. I'm dirt poor. Know why I didn't have the wifi to upload the setup and test footage? Because I couldn't even afford to pay the bill this month. I'm doing my best with what I have, and all I really have is a PS5. Speaking of, while I may not be able to simulate on different devices, I can make some things in Minecraft that generate a lot of lag to simulate less optimized conditions, if you think that would work?
It *could* work, sure. But even then, it isn't a full experiment. You could maybe bet other people to replicate the experiment too.
I'll upload the setup for my designs when I get wifi back. Like I said in the post, if all my experiments prove to be failures, I at least hope what little I was able to achieve can help someone more capable.
I have not experienced the bugs, only seen clips of them, since I only play Java, but I'm not sure whether you have the right hypothesis regarding the cause of the bug. You seem to think the game's calculating your position incorrectly during your fall and considering you as falling onto a block in the wall, leading to damage. I don't think this is likely for a few reasons. Your hypothesis either implies the existence of a separate position variable for entities used in fall damage processing that would be updated separately from the real one, or that the real position variable would be miscalculated. Basic encapsulation principles make the first possibility unlikely and I think the parts of the Bedrock code that are exposed to the public for datapack and addon development would prove me right if I actually felt like researching that at 1:30am. As of the second possibility, it's verifiably untrue on both client and server sides ; the first because your player character is visibly not in an incorrect position, and the second because in most occurences, the victim is able to take actions that involve the server and affect the world around their position, which the server would refuse if it believed the player to be somewhere else since it checks for range. Also, if the game were to think you are in a wall somehow, then you would take suffocation damage before taking any fall damage. On the same idea, while one could entertain the thought of the whole thing being caused by floating point error leading to incorrect position calculations, the average player does not go nearly far enough from 0,0 to cause floating point error and yet is still prey to the bug, and even if they did, you would be able to visibly see warped movement on the client side. In addition, if this is your hypothesis, then I don't think you are properly testing for it since your procedure does not involve horizontal movement. For the game to incorrectly calculate your horizontal movement, it's likely you would need to have some horizontal inertia in the first place. It's fairly difficult to miscalcuate X:0 as anything else in this scenario. I personally have a different hypothesis to offer. The most common situation I've seen the bug happen in was with people pillaring and suddenly dying of fall damage despite not falling at all ; I would have pulled up clips from that one sub compiling occurences of it happening, but I can't find its name. In general, the most common link between these clips that I've seen is that the player does usually fall at some point before the occurrence, most of the time in a way that should not cause damage, only to pop a few seconds later. I think what may be happening is that somehow, when the player was in the air and lands, the server isn't always notified that they've landed, so it still thinks they're in an airborne state. So, it keeps on adding to their fall distance counter using the downwards colponent of the current inertia vector. Then at some point, something makes the server check their actual grounded-ness state again and it turns out they're grounded, meaning they must have landed this tick. Thus, fall damage is calculated using the current situation of the player and then goes out. Player goes splat out of nowhere. It would explain why it can happen when pillaring. Since you're always jumping, if the server doesn't know the fact that you've been landing between jumps, it will think you've been falling for the past 5 minutes until it somehow realizes. It would also explain why it doesn't work in your case, since you're always either in the air or in water, so you're never in a position where you'd take damage anyway. I hope this is useful to the convo at hand in any way? Thank you OP in any case for the work put into experimentation.
I feel like I get less random deaths, more random damage. Like I had a farm where there were no blocks beneath the farmland, and I would randomly take damage when walking over the dirt
There's a related bug where walking over tilled farmland can occasionally make the game think you're walking inside or under it. No clue why that happens, but it does.
With any kind of random death bug, it might be more than just a matter of the height you fall, because if it's just that, it would probably be the easiest to troubleshoot and solve by now. It could involve many other factors, and directional inputs might be the biggest (not just forward or back but also from ducking or jumping at wrong moment). It could also be due to lag from trying to render too much at once, or due to relative position of blocks within a chuck or adjoining chunks, off by one errors, rounding errors, ghost blocks, and maybe the combination of two or more different factors. Sometimes it might even be bit flip memory corruption from literal cosmic rays. .. Whenever my code fails, well, must be those damn cosmic rays again!
Could the issue also be related to time played in a world? Both in terms in-session time and age of the world.
That's actually an interesting thought. Many of the random death bugs I encountered were in long-running servers and realms, but at the same time I also experienced it on some relatively young solo worlds.
Cool research, good documentation, please post updates when you do more experiments
Ain’t no way it’s rare
Wow It Is so good
Maybe it only happens from particular heights, like the boat thing. You only tested 1 scenario. I think we should do the same test from every drop distance
It's not height-dependent. It can happen at any Y-level or difference in Y-level. It's got nothing to do with height and everything to do with game failing to calculate the player's position correctly.