foxynotail

I've tested this thoroughly.
The player can no longer interact with an entity while crouching.

The addon I've attached shows that the game is detecting the player crouching and or holding shears. However when interacting with a sheep that requires the player to be crouched in order to shear it, nothing happens.

This has broken several of my most popular packs including marketplace content!

I have had this issue on two separate worlds several times.
Both are flat worlds, one is new and the other is a few years old. Both have filesizes of less than 1MB

Platform: Windows 10
MC Version: 1.19.51

Video taken from a recent Live stream highlighting the bug:
Video Link

What happens:
Opening the world the first time after loading Minecraft:
The world has reverted to an older state. Builds / chunks and items are missing. The player is in a different location from where they logged out.
Closing and opening the world for a second time:
The world is as expected. Blocks / chunks & items are back and the player is where they logged out.

To reproduce:
There is seemingly no consistent way to reproduce.

Steps taken in 1st scenario:
1. Open Minecraft (Windows 10 1.19.51)
2. Click play
3. Choose a world ( only had this issue with flat worlds so far)
4. Observe the world reverted to a previous state. (builds/chunks/items missing, player in wrong location)
5. Close the world
5. Open the same world
6. Observe the world back to its expected state

Steps taken in 2nd scenario (As per video link above)
1. Open Minecraft (Windows 10 1.19.51)
2. Click play
3. Play on a server
4. Exit the server
5. Choose a local world (only had this issue with flat worlds so far)
6. Observe the world reverted to a previous state. (builds/chunks/items missing, player in wrong location)
7. Close the world
8. Open the same world
9. Observe the world back to its expected state

It also affects the other server that I run which resets twice per day

This affects 1.19.41 too.
Our Nodecraft server resets every 12 hours at 1pm and you can see the issues from the attached graphs.

I don't think they forgot to add a clean function.
I've been writing functions to get rid of the lost actor data with my prune tool, but even when the leveldb reports the actor key as deleted, it will often appear again.

I think this bug is with the leveldb system, more than it is mojang. Perhaps the structure of the keys or data within them is bugging out leveldb system, preventing them truly being deleted.

I've tried to replicate the issues I had yesterday in which changing the simulation made no difference, but I cannot replicate it exactly.

I did get a fill command that was within the simulation distance of a player to fail, but increasing the sim distance fixed it today, whereas yesterday it did not.

Process:
1. Start a new flat world, in creative, sim 4, no experiments.
2. Go into fly mode
3. tp to 0 40 0
4. run the fill command 0 40 0 50 40 50 stone 0 -> gives error "cannot place blocks outside of world"
5. /tp 20 40 20
6. /fill 20 40 20 40 40 40 stone 0 -> Works today (didn't yesterday: could be human error)

Yesterday I tried a range of commands within the same area, even switched up to sim distance of 12 and still couldn't fill that area.
All of the commands are copy pasted from a list, so its unlikely I typed them in wrong, but not impossible.

From today's testing it does very much seem like this is related to simulation distance, however this is bizzare as I spent a very long time trying the exact same process yesterday and I only managed to get 1 out of 20 fill commands to work on a sim distance of 12.

I was standing (flying) at 20 40 20 in a flat world in creative mode.
I ran the command /fill 20 40 20 40 40 40 stone 0
I also ran commands with relative coordinates and tried the same fill command with different coordinates in the area around me
It wasn't until I had physically been in all of the chunks within the fill area that the command would run.

The "duplicated" bug MCPE-156751 is not a duplicate of this bug as it is unrelated to simulation distance.
It is a separate bug that should stand on it's own

Request to reopen as the linked bug is related to simulation distance where as this bug is not.
This bug occurs on any simulation distance with a fill area of any size (small 16x16) to large.

The fill command will not work because the chunks it's trying to fill in have not been visited by a player which means they are not saved / loaded.
As simulation distance no longer affects how chunks are saved / stored (i.e. the player has to have visited the chunk for it to be saved to the leveldb), the parent bug of this bug report is invalid and this bug report should stand on it's own.

Reply from @unknown
What is the specific command you tried and where were you standing at the time?

This is not resolved. The issue still occurs in Minecraft 1.18.1

I have video evidence of spawners emitting full light level on a BDS server.

Two players in the same area can see different lighting & light levels.

Relogging fixes the issue.

There is no walking sound at all below Y=0 which is why the stairs lose their noise. You still hear the "thud" sound as you technically fall from one stair to the next (falling/jumping sounds still exist below Y=0), but there are no footstep sounds below that level, so you don't hear the copper "ting" any more.

Additionally to this, in survival...

If you craft a lightning rod it will place just fine.
Breaking that lightning rod causes it to become cursed. It gets stuck in your inventory and you can no longer place it in the world. You can also not interact with other blocks while holding it.

It is possible to throw it out of your inventory using the mouse while it is cursed, but that doesn't fix the issue.

This is still an issue.

Please see my recent Beta video for reference.
The issue occurs at 18mins 43seconds
https://youtu.be/qMMGFxqdbiw?t=1123

Version: 1.16.210.59
Platform: Windows 10
All Experimental Features Enabled

Playing on a multiplayer world, connected via VPN to induce lag to simulate realms / server performance in the Betas.

This happens regularly in the UHC map that I've made. MC Version 1.16.201.2

Steps to reproduce
1. Players start at 5000 100 5000 in the UHC Hub
2. On starting the map the following command runs: /spreadplayers 0 0 0 512 @a

Observed results
Players fall from the correct coords around 0, 0 but from 255 in the air.

Expected results
Players should appear on the surface and not at 255

There is a ticking area at 0,0 and also one at the UHC Hub at 5000,5000

This issue is back in 1.16.100 but not just after jumping.

If there is any form of lag or latancy from internal processing, players will die on being teleported.

Sometimes they die instantly, sometimes it can be a couple of seconds after they appear to have survived, dependant on ping.

Giving the teleporting player status effects including resistance and slow falling does not help.

I've also tried deactivating the fall damage game rule whilst players are teleporting but that also doesn't help.

Death messages are always, "player fell from a high place" or "player experienced fall damage".

This has happened on a realm and single player worlds with local players (Lan) and remote players.

I.e. on my local world with one Lan player the lab player died on teleporting. On my realm several members died while teleporting.

To recreate:
Create a world
Invite players
Teleport players from y=200 to Y=50 or vice versa.

Repeat until they die from it.

Sometimes the local player can see the player teleport back and forth from the place they're supposed to be going to before they die. For example, the teleport command is run, the player visually moves to the correct location, then appears back where they were for a second, and then goes back to the correct teleport location.

Perhaps this rubber banding is causing the issue.

I can confirm this made it into stable release.

Changing the UUID is a temporary fix. The packs can "break" again after changing the UUIDs on the same realm. We need a long term solution or an actual bug fix for this

Using world edit, it's possible to see that treasure / loot chests no longer maintain their loot table data and therefore cannot be used in map making.

The LootTable key and LootTableSeed keys are missing from the database data for the chests and manually adding those keys (which worked before), no longer works. The data is removed when the world is loaded and the items are generated in what should be an empty chest.

It seems that the loot is being generated when the chunk contianing the chests are loaded, instead of when the player opens the chest.

Whilst this isn't a huge issue for survival gameplay, for any map makers or add-ons that use custom loot tables for chests, this is a huge issue as you can no longer create random loot in existing chests.

The fix for this is terrible.
Loot chests now have their loot generated when the chest loads into the world instead of when a player opens the chest which means it's now impossible for map makers to have loot tables for chests in custom maps.

This needs addressing as it's such a massive oversight by the devs!

Please fix!

This is still an issue on 1.16.0.67