Exa
- Selacos
- selacos
- Europe/Stockholm
- Yes
- No
Occasionally, Entities may appear invisible in flowing water when at screen borders. This happened with zombies, squids, drowned (particularly awful) and a creeper. They will not turn visible again if focused, but they will no longer turn invisible again. Every part of the entity rendering that came out of the water will stay visible.
Because of the speed at which they turn fully visible i didn't manage to take a screenshot.
If I am powering/unpowering a sticky piston at the exact same time I am pausing/quitting the game/unloading the chunk, the piston will remain in the previous state, completely ignoring the update. This did not occur with regular pistons.
20w06a partially fixed this; it still occursrarelybut much less common than 1.15.2-pre2 and 1.15.2
Reproduce:
1. build an array of zeroticking machines as they provide a lot of fast updates to the piston
2. repeatedly pause the game (in singleplayer) or kill the server (in multiplayer). Regular saving & shutting down of a multiplayer server will not cause the issue, despite singleplayer running an integrated server.
3. most likely some of the machines will have stopped working, with a piston being powered and not firing.
I am already sorry for most likely duplicating something... after about an hour of searching i couldnt find any similar issue though
If I am powering/unpowering a sticky piston at the exact same time I am pausing/quitting the game/unloading the chunk, the piston will remain in the previous state, completely ignoring the update. This did not occur with regular pistons.
20w06a partially fixed this; it still occurs but much less common than 1.15.2-pre2 and 1.15.2
Reproduce:
1. build an array of zeroticking machines as they provide a lot of fast updates to the piston
2. repeatedly pause the game (in singleplayer) or kill the server (in multiplayer). Regular saving & shutting down of a multiplayer server will not cause the issue, despite singleplayer running an integrated server.
3. most likely some of the machines will have stopped working, with a piston being powered and not firing.
I am already sorry for most likely duplicating something... after about an hour of searching i couldnt find any similar issue though
If I am powering/unpowering a sticky piston at the exact same time I am pausing/quitting the game/unloading the chunk, the piston will remain in the previous state, completely ignoring the update. This did not occur with regular pistons.
20w06a partially fixed this; it still occurs but much less common than 1.15.2-pre2 and 1.15.2
Reproduce:
1. build an array of zeroticking machines as they provide a lot of fast updates to the piston
2. repeatedly pause the game/reload the world (in singleplayer) or kill the server (in multiplayer). Regular saving & shutting down of a multiplayer server will not cause the issue, despite singleplayer running an integrated server.
3. most likely some of the machines will have stopped working, with a piston being powered and not firing.
I am already sorry for most likely duplicating something... after about an hour of searching i couldnt find any similar issue though
Sticky Pistons forgetting to push/pull when pausing the game or saving & quitting while the pistongets poweredSticky Pistons forgetting to push/pull when pausing the game or saving & quitting while the pistons power state changes
If I am powering/unpowering a sticky piston at the exact same time I am pausing/quitting the game/unloading the chunk, the piston will remain in the previous state, completely ignoring the update. This did not occur with regular pistons.
20w06a partially fixed this; it still occurs but much less common than 1.15.2-pre2 and 1.15.2
Reproduce:
1. build an array of zeroticking machines as they provide a lot of fast updates to the piston (machines that don't use unintended behaviour, like flying machines, are affected as well but as they are slower it's harder to demonstrate the issue with them)
2. repeatedly pause the game/reload the world (in singleplayer) or kill the server (in multiplayer). Regular saving & shutting down of a multiplayer server will not cause the issue, despite singleplayer running an integrated server.
3. most likely some of the machines will have stopped working, with a piston being powered and not firing.
I am already sorry for most likely duplicating something... after about an hour of searching i couldnt find any similar issue though
StickyPistons forgetting to push/pull when pausing the game or saving & quitting while the pistons power state changes
Minecraft Server 1.16.2 and 1.16.3, on Debian 10 and Java JRE 1.8.0_241
Glow Lichen can be harvested at a rate of 6400 items per hour, as shown in https://www.youtube.com/watch?v=TGPyaN0-J1E and as can be easily replicated by testing a bunch.
6400 items per hour equals 11.25 game ticks per item, which is clearly broken.
The Minecraft Vanilla Server generates 7200 plants per hour, not 6400; and latency is no excuse in singleplayer.
Edit: wrote up a gist explaining this: https://gist.github.com/ExaInsanity/e7004a3d11a811b3dabd02d7092151b7
Glow Lichen can be harvested at a rate of 6400 items per hour, as shown in https://www.youtube.com/watch?v=TGPyaN0-J1E and as can be easily replicated by testing a bunch.
6400 items per hour equals 11.25 game ticks per item, which is clearly broken
.The Minecraft Vanilla Server generates 7200 plants per hour, not 6400; and latency is no excuse in singleplayer.
Edit: wrote up a gist explaining this: https://gist.github.com/ExaInsanity/e7004a3d11a811b3dabd02d7092151b7
Glow Lichen can be harvested at a rate of 6400 items per hour, as shown in https://www.youtube.com/watch?v=TGPyaN0-J1E and as can be easily replicated by testing a bunch.
6400 items per hour equals 11.25 game ticks per item, which is clearly broken as it indicates a desync from the main tick loop, moreover there is absolutely no place where that number would come from:
It has a 6gt breaking time, one tick would be needed to regrow = 7gt/item
Taking non-instamining delay into account: 6gt breaking, 6gt delay, one tick regrow = 13gt/itemThe Minecraft Vanilla Server generates 7200 plants per hour, not 6400; and latency is no excuse in singleplayer.
Edit: wrote up a gist explaining this: https://gist.github.com/ExaInsanity/e7004a3d11a811b3dabd02d7092151b7
affects 21w10a - should i start deleting the old confirm comments?
affects 1.16.5 and 21w03a
affects 20w45a, though apparently chunk unloading changed/got a new bug so its even less predictable when it happens now. reloading the world a few times is still a pretty guaranteed reproduce
affects 1.16.4
affects 1.16.4-pre2, also i would like to add the bug is not piston exclusive. All block updates are affected, including observers, redstone dust etc
All block updates are forgotten when the chunk is reloaded.
affects 1.16.3
affects 1.16.2
affects 1.16-Release
affects 1.16 pre8.
affects 1.16 pre5
affects 1.16 pre3
affects 20w22a
had to fix that typo
ok, Johnibur... affects 20w18a
affects 1.16 pre7
affects 17a
affects 20w14a
affects 20w13b
affects 15a and 16a
affects 20w11a
affects 20w12a
confirmed in 1.15.x and the 1.16 snapshots (including 20w08a and 20w09a)
affects 20w10a
Exa ticket is yours now. You can delete all your comments and update the report yourself in the future.




according to my observations they have more problems when there's blocks above.
it's the same one as
MC-165874the panda comes into rendering inside of water, the underwater parts get invisible, it comes into screen center.
you were fortunate enough to take a screenshot, unlike me
it is excessivley hard to reproduce... it randomly happens and is hard to control. i never managed to take a screenshot
i know that there is a range and i know that the effect lasts only three to five seconds. i also had trouble reproducing it. sometimes, by random chance, it failed to work, but mostly, it worked perfectly well.
your chest issues are due to resource packs being updated.
even the slightest resource pack-based change to chests will cause it to look like that.
1.15 uses the resource pack version 5, which is incompatible with all older resource packs.
confirmed on single- and multiplayer across all game modes, chunk peculiarities et cetera i could think of
Incidentally, using resource packs like Vanilla Tweaks fix that (if they are edited to fit RP version 5). Also it seems like the affected chunks are random.
that is actually exactly how it's supposed to work.
that is actually intended afaik
apparently 20w06a fixed it for pausing the game but not for quitting & reloading
still happens in 20w07a
affects 20w08a, with again decreased probability for some reason
meant to be fixed in 20w08a
Duplicate of
MC-172078affects 20w09a, with even more decreased probability but now also affecting normal pistons
still works in 1.15.x and 1.16 snapshots if you cure the villager multiple times (single-cure wont work)
fixed if you optimize your world.
/locate never allowed finding dungeons
affects 1.16 and 1.16.1 releases as well.
Datapack files do not load consistently; they sometimes don't get applied (for loot tables/recipes) or executed (tick.mcfunction). The problem being that there are no error messages, just a cryptic message that the Render Thread is loading datapacks for some reason.
Attached the datapack; just made sure it works... In 1.14 and 1.15 it starts flawlessly.
This specific datapack does not have a tick.mcfunction, however, I confirmed them being sometimes broken with different datapacks. Also it does not only affect my datapacks but also randomly packs that have been found working in previous versions.
Could not reproduce in 1.15.1 or later. Then again the save where I encountered the bug in the first place turned out to be corrupted, might as well have been a side effect of the corruption in the first place.
It affects all mobs that convert while in a minecart, including z villagers.
I have added the logfile (and censored the IP addresses as this is a public report)
affects 21w06a
Can reproduce: to make it easier, use minimal settings when attempting to take the report
its outputting the maximum ticks per second the game could possibly get if the limit was removed, from what it looks like