VorCas

I have a very similar issue, per my report as MC-252878. There are some differences, however:

– I have no problem continuing playing (I only play SP, however, and do not log in to a MP server).

– I do not receive the popup; It only shows up in my logs.

– Some behavior may be different, such as when exiting the JE client and returning to the Launcher window, the Launcher window is completely blank.

– It only occurs when I have been running the JE client several hours, regardless of whether I am actively playing, or just sitting at the main JE window without entering a game world.

Also note that, for me, the computer clock is not a consideration: I play on my LAN Domain Controller – which keeps all my LAN computers in sync, and the DC itself is kept in sync from five different Internet NTP servers as well a radio time signal receiver (NIST broadcasts). It almost never has a time skew of more than one second from established atomic clocks.

Edit to add: I have fully migrated my account to the Microsoft services thingy about a week ago. I have experienced this issue both before and after the migration.

For me, steps to reproduce are simple. Start playing a game. Save world and then sit idle in the main menu screen overnight. Load the world again and check logs.

Requesting to re-open this issue. As of version 1.19 release, this is still an issue. Specific details:

When cloning a region (with move), certain attached items get destroyed and drop as items (or drop their contents, in the case of chests) at the original location. The blocks are still cloned successfully at the target location. That is, for example, chests get re-created at the target with their contents intact – but the contents also drop at the original location.  In effect, it creates duplicates. This also happens with doors, beds, etc. They get cloned, but also drop as items in the original location (I assume because the supporting/attached blocks are now destroyed).

My guess is that when the clone command executes, it creates a copy of the cloned blocks at the target location, then destroys the blocks at the source location. But instead of complete destruction, including contents of chests, or attached/supported items, the code treats it like the player destroyed the item. Thus, it executes the code to drop container contents, drop supported/attached items (torches, signs, etc), and so on. This is likely due to block update mechanics.

What should happen is that the code for destroying each block should first check any attached/supported/contained items, and destroy them before destroying itself.

I have also noted similar behavior when using something like "fill ~1 ~1 ~ ~1 ~2 ~ minecraft:oak_door[facing=north,hinge=right]". Instead of properly filling the lower and upper halfs, it fills the incorrect half(s) and immediate drops as an item on the next block update.

This also occurs when "clearing" an area, such as "fill ~ ~ ~ ~8 ~8 ~8 minecraft:air replace". Blocks such as doors, containers, signs, etc, all drop as items when their respective supporting/attached/containing blocks are replaced with air. That is, it acts nearly the same as if the final part of the command was "destroy" instead of "replace".

At first, I felt this was an issue. However, I no longer feel this way: Even in "real", situations can occur which can and do trample crops. This ranges from combat to trespassers taking a "shortcut" through a farm field.

Instead, what I believe the issue is:

Villagers themselves should attempt to avoid actions that would trample crops in normal circumstances. A villager being chased by a zombie, for example, is not going to stop and consider if his running away will trample crops; He is going to run for his life! This is the same reason am iron golem will not wait for a zombie to move to a clear spot before trying to engage the zombie in combat.

There are two immediate "fixes" I can imagine:

(1): Re-arrange generated farms to place the composter either on a block not direcly adjacent to farmland, or lower the composter by one block so villagers will not "jump down" to get off the composter.

And/or (2): Check at an appropriate place in the villager movement code if  the next move might trample crops, and choose an alternate route/movement if it might. This way, the check can be skipped if the villager is "fleeing in terror and does not care about crops". It would also affect them if, for example, a tree had spawned in such a way that the leaves become another possible place to "leap down" upon crops.