Bytzo
- Bytzo
- JIRAUSER537439
- America/Los_Angeles
- Yes
- No
MCL-16405
MC-212291![[Mojang] Felix Jones](../../../data/avatars/users/40484.png){kind=small}
This bug report is a continuation of
MC-202202, as it was only partially fixed in 21w03a.
A change in snapshot 20w22a allows the client to dismount a vehicle independently from the server, causing a de-sync between the two. This can be triggered in a variety of ways, see Reproduction Steps.
When this de-sync occurs, the server will see the player as riding in the vehicle, while the client (the player) sees themselves as dismounted from the vehicle, allowing them walk around freely. Walking around and attempting to break blocks far away from the vehicle will cause vanilla anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the vehicle and cannot possibly break blocks that far. Sneaking causes the player to teleport back to the vehicle, as the server thinks the player has just dismounted the vehicle.
This issue was initially reported as
MC-202202, which observed that in snapshot 20w09a code was added to the client which allowed it to dismount a vehicle independently from the server using the sneak key. Since this caused de-sync issues during lag spikes, it was reverted in 21w03a leavingMC-202202resolved.However, the implemented fix for
MC-202202in 21w03a only considered situations when the client uses the sneak key to dismount. It was also noted inMC-202202that snapshot 20w22a added a way for clients to dismount a vehicle independently from the server during situations not caused by the sneak key, such as when the vehicle moves through a block. This discovery was only reported onMC-202202a short amount of time before the release of 21w03a, likely being the reason whyMC-202202was not entirely fixed.The rest of this bug report covers the unresolved part of
MC-202202, where the client can decide to dismount its own vehicle in situations not caused by sneaking, leading to a de-sync.Impact
This bug leads to a de-sync between the client and the server in several scenarios during vanilla gameplay, causing undesirable behavior. Some of these scenarios in the past have been reported as their own bugs, such as
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477. Fixing this bug using the proposed fix (see Code Analysis) will resolve all of these issues, as I was unable to reproduce any of them with the fix (see Workaround).This bug can additionally cause a de-sync on third-party servers if the server attempts to keep a player mounted on a vehicle through third-party modifications to the server software. This is a common mechanic used on minigame servers when the player must remain in a vehicle, such as a minecart on a roller coaster. While this was primarily fixed with 21w03a, situations where the client dismounts its own vehicle when not using the sneak key still cause a de-sync. For example, the client currently decides to dismount its vehicle when the vehicle moves through a block, which does not require using the sneak key, leading to a de-sync. This did not occur on versions prior to 20w22a. By implementing the proposed fix, this no longer happens and prevents buggy behavior on these third-party servers.
Reproduction Steps
We may observe the effects of this bug by looking at the other reported issues which are directly caused by this bug. See
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477.The reproduction steps of
MC-191714are provided below, which shows this bug. When the farmland is turned into a full dirt block, the horse becomes inside the block, causing the client to decide to dismount the house and create a de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /gamerule randomTickSpeed 0 in-game.
- Run the command /fill ~-3 ~-1 ~-3 ~3 ~5 ~3 minecraft:glowstone hollow in-game.
- Run the command /fill ~-2 ~-1 ~-2 ~2 ~-1 ~2 minecraft:farmland in-game.
- Run the command /summon minecraft:*horse ~ ~ ~ {Invulnerable:1b,NoAI:1b,PersistenceRequired:1b,SaddleItem: {id:saddle,Count:1}
,Tame:1}* in-game.
- Mount the horse.
- Jump at least 1 block in the air with the horse, so the farmland is broken and you are dismounted from the horse.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
Another example of this bug can be found in
MC-190454, with steps to reproduce shown below. When the husk dies, the client decides to dismount the horse, creating the de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /summon minecraft:*husk ~ ~ ~
Unknown macro: {NoAI}]}
*in-game.- Mount the horse.
- Run the command /summon minecraft:tnt in-game.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
This bug can also be seen through
MC-200286.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /fill ~ ~-1 ~ ~ ~-1 ~5 minecraft:obsidian in-game.
- Run the command /summon minecraft:end_crystal ~ ~ ~5 in-game.
- Run the command /summon minecraft:boat ~ ~ ~2 in-game.
- Mount the boat.
- Row the boat forward 3 blocks or until inside the end crystal.
- Look down and right click the boat.
- Notice the de-sync. Walking around and attempting to break blocks far away from the boat will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the boat. Sneaking causes the player to teleport back to the boat, as the server thinks the player has just dismounted the boat.
Code Analysis
In snapshot 20w22a, a change was made in the handleMovePlayer() method in net.minecraft.client.multiplayer.ClientPacketListener. This change added a conditional statement that allows the client to dismount a vehicle using the removeVehicle() method. In order to fix this bug, this change would need to be reverted. By doing so, it should no longer be possible to dismount an vehicle on the client, preventing any de-sync issues that may occur.
It may be possible that this was added to fix another bug or intentionally change behavior. In this case, reverting this change would not be beneficial to the game. We can check the changelog and fixed bugs from 20w22a relating to entity mounting in order to see if this is true. The bugs that fit this category are
MC-182967,MC-184629, andMC-184640, and changes that fit this category include the prevention of mounting entities while the shift key is held. I was unable to reproduce these resolved issues and was still unable to mount entities when the shift key was held using the proposed fix, meaning that the proposed fix in this issue should not conflict with other changes or issues from 20w22a.Workaround
The current workaround is to implement the proposed fix described in the Code Analysis section. A client-sided Fabric mod does this for versions 1.16 through 1.16.5 and snapshots 20w22a through 20w51a, with the source code linked here. Use the modification at your own risk, please audit and compile the code from source to ensure safety. As this modification was meant to fix
MC-202202, it does not work with snapshots 21w03a or later which contains a partial fix forMC-202202. This also means it back-ports the partial fix forMC-202202from 21w03a to earlier versions of the game. If you wish to fix this bug in versions 21w03a or later, it is possible to modify the source code and recompile the modification, however this process is not in the scope of this bug report and will not be described here.This bug report is a continuation of
MC-202202, as it was only partially fixed in 21w03a.
A change in snapshot 20w22a allows the client to dismount a vehicle independently from the server, causing a de-sync between the two. This can be triggered in a variety of ways, see Reproduction Steps.
When this de-sync occurs, the server will see the player as riding in the vehicle, while the client (the player) sees themselves as dismounted from the vehicle, allowing them walk around freely. Walking around and attempting to break blocks far away from the vehicle will cause vanilla anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the vehicle and cannot possibly break blocks that far. Sneaking causes the player to teleport back to the vehicle, as the server thinks the player has just dismounted the vehicle.
This issue was initially reported as
MC-202202, which observed that in snapshot 20w09a code was added to the client which allowed it to dismount a vehicle independently from the server using the sneak key. Since this caused de-sync issues during lag spikes, it was reverted in 21w03a leavingMC-202202resolved.However, the implemented fix for
MC-202202in 21w03a only considered situations when the client uses the sneak key to dismount. It was also noted inMC-202202that snapshot 20w22a added a way for clients to dismount a vehicle independently from the server during situations not caused by the sneak key, such as when the vehicle moves through a block. This discovery was only reported onMC-202202a short amount of time before the release of 21w03a, likely being the reason whyMC-202202was not entirely fixed.The rest of this bug report covers the unresolved part of
MC-202202, where the client can decide to dismount its own vehicle in situations not caused by sneaking, leading to a de-sync.Impact
This bug leads to a de-sync between the client and the server in several scenarios during vanilla gameplay, causing undesirable behavior. Some of these scenarios in the past have been reported as their own bugs, such as
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477. Fixing this bug using the proposed fix (see Code Analysis) will resolve all of these issues, as I was unable to reproduce any of them with the fix (see Workaround).This bug can additionally cause a de-sync on third-party servers if the server attempts to keep a player mounted on a vehicle through third-party modifications to the server software. This is a common mechanic used on minigame servers when the player must remain in a vehicle, such as a minecart on a roller coaster. While this was primarily fixed with 21w03a, situations where the client dismounts its own vehicle when not using the sneak key still cause a de-sync. For example, the client currently decides to dismount its vehicle when the vehicle moves through a block, which does not require using the sneak key, leading to a de-sync. This did not occur on versions prior to 20w22a. By implementing the proposed fix, this no longer happens and prevents buggy behavior on these third-party servers.
Reproduction Steps
We may observe the effects of this bug by looking at the other reported issues which are directly caused by this bug. See
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477.The reproduction steps of
MC-191714are provided below, which shows this bug. When the farmland is turned into a full dirt block, the horse becomes inside the block, causing the client to decide to dismount the house and create a de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /gamerule randomTickSpeed 0 in-game.
- Run the command /fill ~-3 ~-1 ~-3 ~3 ~5 ~3 minecraft:glowstone hollow in-game.
- Run the command /fill ~-2 ~-1 ~-2 ~2 ~-1 ~2 minecraft:farmland in-game.
- Run the command */summon minecraft:horse ~ ~ ~ {Invulnerable:1b,NoAI:1b,PersistenceRequired:1b,SaddleItem: {id:saddle,Count:1}
,Tame:1}* in-game.
- Mount the horse.
- Jump at least 1 block in the air with the horse, so the farmland is broken and you are dismounted from the horse.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
Another example of this bug can be found in
MC-190454, with steps to reproduce shown below. When the husk dies, the client decides to dismount the horse, creating the de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /summon minecraft:husk ~ ~ ~ {NoAI:1b,Passengers:[
Unknown macro: {id}]} in-game.
- Mount the horse.
- Run the command /summon minecraft:tnt in-game.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
This bug can also be seen through
MC-200286.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /fill ~ ~-1 ~ ~ ~-1 ~5 minecraft:obsidian in-game.
- Run the command /summon minecraft:end_crystal ~ ~ ~5 in-game.
- Run the command /summon minecraft:boat ~ ~ ~2 in-game.
- Mount the boat.
- Row the boat forward 3 blocks or until inside the end crystal.
- Look down and right click the boat.
- Notice the de-sync. Walking around and attempting to break blocks far away from the boat will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the boat. Sneaking causes the player to teleport back to the boat, as the server thinks the player has just dismounted the boat.
Code Analysis
In snapshot 20w22a, a change was made in the handleMovePlayer() method in net.minecraft.client.multiplayer.ClientPacketListener. This change added a conditional statement that allows the client to dismount a vehicle using the removeVehicle() method. In order to fix this bug, this change would need to be reverted. By doing so, it should no longer be possible to dismount an vehicle on the client, preventing any de-sync issues that may occur.
It may be possible that this was added to fix another bug or intentionally change behavior. In this case, reverting this change would not be beneficial to the game. We can check the changelog and fixed bugs from 20w22a relating to entity mounting in order to see if this is true. The bugs that fit this category are
MC-182967,MC-184629, andMC-184640, and changes that fit this category include the prevention of mounting entities while the shift key is held. I was unable to reproduce these resolved issues and was still unable to mount entities when the shift key was held using the proposed fix, meaning that the proposed fix in this issue should not conflict with other changes or issues from 20w22a.Workaround
The current workaround is to implement the proposed fix described in the Code Analysis section. A client-sided Fabric mod does this for versions 1.16 through 1.16.5 and snapshots 20w22a through 20w51a, with the source code linked here. Use the modification at your own risk, please audit and compile the code from source to ensure safety. As this modification was meant to fix
MC-202202, it does not work with snapshots 21w03a or later which contains a partial fix forMC-202202. This also means it back-ports the partial fix forMC-202202from 21w03a to earlier versions of the game. If you wish to fix this bug in versions 21w03a or later, it is possible to modify the source code and recompile the modification, however this process is not in the scope of this bug report and will not be described here.
This bug report is a continuation of
MC-202202, as it was only partially fixed in 21w03a.
A change in snapshot 20w22a allows the client to dismount a vehicle independently from the server, causing a de-sync between the two. This can be triggered in a variety of ways, see Reproduction Steps.
When this de-sync occurs, the server will see the player as riding in the vehicle, while the client (the player) sees themselves as dismounted from the vehicle, allowing them walk around freely. Walking around and attempting to break blocks far away from the vehicle will cause vanilla anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the vehicle and cannot possibly break blocks that far. Sneaking causes the player to teleport back to the vehicle, as the server thinks the player has just dismounted the vehicle.
This issue was initially reported as
MC-202202, which observed that in snapshot 20w09a code was added to the client which allowed it to dismount a vehicle independently from the server using the sneak key. Since this caused de-sync issues during lag spikes, it was reverted in 21w03a leavingMC-202202resolved.However, the implemented fix for
MC-202202in 21w03a only considered situations when the client uses the sneak key to dismount. It was also noted inMC-202202that snapshot 20w22a added a way for clients to dismount a vehicle independently from the server during situations not caused by the sneak key, such as when the vehicle moves through a block. This discovery was only reported onMC-202202a short amount of time before the release of 21w03a, likely being the reason whyMC-202202was not entirely fixed.The rest of this bug report covers the unresolved part of
MC-202202, where the client can decide to dismount its own vehicle in situations not caused by sneaking, leading to a de-sync.Impact
This bug leads to a de-sync between the client and the server in several scenarios during vanilla gameplay, causing undesirable behavior. Some of these scenarios in the past have been reported as their own bugs, such as
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477. Fixing this bug using the proposed fix (see Code Analysis) will resolve all of these issues, as I was unable to reproduce any of them with the fix (see Workaround).This bug can additionally cause a de-sync on third-party servers if the server attempts to keep a player mounted on a vehicle through third-party modifications to the server software. This is a common mechanic used on minigame servers when the player must remain in a vehicle, such as a minecart on a roller coaster. While this was primarily fixed with 21w03a, situations where the client dismounts its own vehicle when not using the sneak key still cause a de-sync. For example, the client currently decides to dismount its vehicle when the vehicle moves through a block, which does not require using the sneak key, leading to a de-sync. This did not occur on versions prior to 20w22a. By implementing the proposed fix, this no longer happens and prevents buggy behavior on these third-party servers.
Reproduction Steps
We may observe the effects of this bug by looking at the other reported issues which are directly caused by this bug. See
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477.The reproduction steps of
MC-191714are provided below, which shows this bug. When the farmland is turned into a full dirt block, the horse becomes inside the block, causing the client to decide to dismount the house and create a de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /gamerule randomTickSpeed 0 in-game.
- Run the command /fill ~-3 ~-1 ~-3 ~3 ~5 ~3 minecraft:glowstone hollow in-game.
- Run the command /fill ~-2 ~-1 ~-2 ~2 ~-1 ~2 minecraft:farmland in-game.
- Run the command */summon minecraft:horse ~ ~ ~ {Invulnerable:1b,NoAI:1b,PersistenceRequired:1b,SaddleItem:
{id:saddle,Count:1},Tame:1}* in-game.
- Mount the horse.
- Jump at least 1 block in the air with the horse, so the farmland is broken and you are dismounted from the horse.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
Another example of this bug can be found in
MC-190454, with steps to reproduce shown below. When the husk dies, the client decides to dismount the horse, creating the de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command
/summon minecraft:husk ~ ~ ~ {NoAI:1b,Passengers:[Unknown macro: {id}]} in-game.
- Mount the horse.
- Run the command /summon minecraft:tnt in-game.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
This bug can also be seen through
MC-200286.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /fill ~ ~-1 ~ ~ ~-1 ~5 minecraft:obsidian in-game.
- Run the command /summon minecraft:end_crystal ~ ~ ~5 in-game.
- Run the command /summon minecraft:boat ~ ~ ~2 in-game.
- Mount the boat.
- Row the boat forward 3 blocks or until inside the end crystal.
- Look down and right click the boat.
- Notice the de-sync. Walking around and attempting to break blocks far away from the boat will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the boat. Sneaking causes the player to teleport back to the boat, as the server thinks the player has just dismounted the boat.
Code Analysis
In snapshot 20w22a, a change was made in the handleMovePlayer() method in net.minecraft.client.multiplayer.ClientPacketListener. This change added a conditional statement that allows the client to dismount a vehicle using the removeVehicle() method. In order to fix this bug, this change would need to be reverted. By doing so, it should no longer be possible to dismount an vehicle on the client, preventing any de-sync issues that may occur.
It may be possible that this was added to fix another bug or intentionally change behavior. In this case, reverting this change would not be beneficial to the game. We can check the changelog and fixed bugs from 20w22a relating to entity mounting in order to see if this is true. The bugs that fit this category are
MC-182967,MC-184629, andMC-184640, and changes that fit this category include the prevention of mounting entities while the shift key is held. I was unable to reproduce these resolved issues and was still unable to mount entities when the shift key was held using the proposed fix, meaning that the proposed fix in this issue should not conflict with other changes or issues from 20w22a.Workaround
The current workaround is to implement the proposed fix described in the Code Analysis section. A client-sided Fabric mod does this for versions 1.16 through 1.16.5 and snapshots 20w22a through 20w51a, with the source code linked here. Use the modification at your own risk, please audit and compile the code from source to ensure safety. As this modification was meant to fix
MC-202202, it does not work with snapshots 21w03a or later which contains a partial fix forMC-202202. This also means it back-ports the partial fix forMC-202202from 21w03a to earlier versions of the game. If you wish to fix this bug in versions 21w03a or later, it is possible to modify the source code and recompile the modification, however this process is not in the scope of this bug report and will not be described here.This bug report is a continuation of
MC-202202, as it was only partially fixed in 21w03a.
A change in snapshot 20w22a allows the client to dismount a vehicle independently from the server, causing a de-sync between the two. This can be triggered in a variety of ways, see Reproduction Steps.
When this de-sync occurs, the server will see the player as riding in the vehicle, while the client (the player) sees themselves as dismounted from the vehicle, allowing them walk around freely. Walking around and attempting to break blocks far away from the vehicle will cause vanilla anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the vehicle and cannot possibly break blocks that far. Sneaking causes the player to teleport back to the vehicle, as the server thinks the player has just dismounted the vehicle.
This issue was initially reported as
MC-202202, which observed that in snapshot 20w09a code was added to the client which allowed it to dismount a vehicle independently from the server using the sneak key. Since this caused de-sync issues during lag spikes, it was reverted in 21w03a leavingMC-202202resolved.However, the implemented fix for
MC-202202in 21w03a only considered situations when the client uses the sneak key to dismount. It was also noted inMC-202202that snapshot 20w22a added a way for clients to dismount a vehicle independently from the server during situations not caused by the sneak key, such as when the vehicle moves through a block. This discovery was only reported onMC-202202a short amount of time before the release of 21w03a, likely being the reason whyMC-202202was not entirely fixed.The rest of this bug report covers the unresolved part of
MC-202202, where the client can decide to dismount its own vehicle in situations not caused by sneaking, leading to a de-sync.Impact
This bug leads to a de-sync between the client and the server in several scenarios during vanilla gameplay, causing undesirable behavior. Some of these scenarios in the past have been reported as their own bugs, such as
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477. Fixing this bug using the proposed fix (see Code Analysis) will resolve all of these issues, as I was unable to reproduce any of them with the fix (see Workaround).This bug can additionally cause a de-sync on third-party servers if the server attempts to keep a player mounted on a vehicle through third-party modifications to the server software. This is a common mechanic used on minigame servers when the player must remain in a vehicle, such as a minecart on a roller coaster. While this was primarily fixed with 21w03a, situations where the client dismounts its own vehicle when not using the sneak key still cause a de-sync. For example, the client currently decides to dismount its vehicle when the vehicle moves through a block, which does not require using the sneak key, leading to a de-sync. This did not occur on versions prior to 20w22a. By implementing the proposed fix, this no longer happens and prevents buggy behavior on these third-party servers.
Reproduction Steps
We may observe the effects of this bug by looking at the other reported issues which are directly caused by this bug. See
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477.The reproduction steps of
MC-191714are provided below, which shows this bug. When the farmland is turned into a full dirt block, the horse becomes inside the block, causing the client to decide to dismount the house and create a de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /gamerule randomTickSpeed 0 in-game.
- Run the command /fill ~-3 ~-1 ~-3 ~3 ~5 ~3 minecraft:glowstone hollow in-game.
- Run the command /fill ~-2 ~-1 ~-2 ~2 ~-1 ~2 minecraft:farmland in-game.
- Run the command */summon minecraft:horse ~ ~ ~ {Invulnerable:1b,NoAI:1b,PersistenceRequired:1b,SaddleItem: {id:saddle,Count:1}
*
,Tame:1} in-game.
- Mount the horse.
- Jump at least 1 block in the air with the horse, so the farmland is broken and you are dismounted from the horse.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
Another example of this bug can be found in
MC-190454, with steps to reproduce shown below. When the husk dies, the client decides to dismount the horse, creating the de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command */summon minecraft:husk ~ ~ ~ {NoAI:1b,Passengers:[
Unknown macro: {id}]}* in-game.
- Mount the horse.
- Run the command /summon minecraft:tnt in-game.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
This bug can also be seen through
MC-200286.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /fill ~ ~-1 ~ ~ ~-1 ~5 minecraft:obsidian in-game.
- Run the command /summon minecraft:end_crystal ~ ~ ~5 in-game.
- Run the command /summon minecraft:boat ~ ~ ~2 in-game.
- Mount the boat.
- Row the boat forward 3 blocks or until inside the end crystal.
- Look down and right click the boat.
- Notice the de-sync. Walking around and attempting to break blocks far away from the boat will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the boat. Sneaking causes the player to teleport back to the boat, as the server thinks the player has just dismounted the boat.
Code Analysis
In snapshot 20w22a, a change was made in the handleMovePlayer() method in net.minecraft.client.multiplayer.ClientPacketListener. This change added a conditional statement that allows the client to dismount a vehicle using the removeVehicle() method. In order to fix this bug, this change would need to be reverted. By doing so, it should no longer be possible to dismount an vehicle on the client, preventing any de-sync issues that may occur.
It may be possible that this was added to fix another bug or intentionally change behavior. In this case, reverting this change would not be beneficial to the game. We can check the changelog and fixed bugs from 20w22a relating to entity mounting in order to see if this is true. The bugs that fit this category are
MC-182967,MC-184629, andMC-184640, and changes that fit this category include the prevention of mounting entities while the shift key is held. I was unable to reproduce these resolved issues and was still unable to mount entities when the shift key was held using the proposed fix, meaning that the proposed fix in this issue should not conflict with other changes or issues from 20w22a.Workaround
The current workaround is to implement the proposed fix described in the Code Analysis section. A client-sided Fabric mod does this for versions 1.16 through 1.16.5 and snapshots 20w22a through 20w51a, with the source code linked here. Use the modification at your own risk, please audit and compile the code from source to ensure safety. As this modification was meant to fix
MC-202202, it does not work with snapshots 21w03a or later which contains a partial fix forMC-202202. This also means it back-ports the partial fix forMC-202202from 21w03a to earlier versions of the game. If you wish to fix this bug in versions 21w03a or later, it is possible to modify the source code and recompile the modification, however this process is not in the scope of this bug report and will not be described here.
This bug report is a continuation of
MC-202202, as it was only partially fixed in 21w03a.
A change in snapshot 20w22a allows the client to dismount a vehicle independently from the server, causing a de-sync between the two. This can be triggered in a variety of ways, see Reproduction Steps.
When this de-sync occurs, the server will see the player as riding in the vehicle, while the client (the player) sees themselves as dismounted from the vehicle, allowing them walk around freely. Walking around and attempting to break blocks far away from the vehicle will cause vanilla anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the vehicle and cannot possibly break blocks that far. Sneaking causes the player to teleport back to the vehicle, as the server thinks the player has just dismounted the vehicle.
This issue was initially reported as
MC-202202, which observed that in snapshot 20w09a code was added to the client which allowed it to dismount a vehicle independently from the server using the sneak key. Since this caused de-sync issues during lag spikes, it was reverted in 21w03a leavingMC-202202resolved.However, the implemented fix for
MC-202202in 21w03a only considered situations when the client uses the sneak key to dismount. It was also noted inMC-202202that snapshot 20w22a added a way for clients to dismount a vehicle independently from the server during situations not caused by the sneak key, such as when the vehicle moves through a block. This discovery was only reported onMC-202202a short amount of time before the release of 21w03a, likely being the reason whyMC-202202was not entirely fixed.The rest of this bug report covers the unresolved part of
MC-202202, where the client can decide to dismount its own vehicle in situations not caused by sneaking, leading to a de-sync.Impact
This bug leads to a de-sync between the client and the server in several scenarios during vanilla gameplay, causing undesirable behavior. Some of these scenarios in the past have been reported as their own bugs, such as
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477. Fixing this bug using the proposed fix (see Code Analysis) will resolve all of these issues, as I was unable to reproduce any of them with the fix (see Workaround).This bug can additionally cause a de-sync on third-party servers if the server attempts to keep a player mounted on a vehicle through third-party modifications to the server software. This is a common mechanic used on minigame servers when the player must remain in a vehicle, such as a minecart on a roller coaster. While this was primarily fixed with 21w03a, situations where the client dismounts its own vehicle when not using the sneak key still cause a de-sync. For example, the client currently decides to dismount its vehicle when the vehicle moves through a block, which does not require using the sneak key, leading to a de-sync. This did not occur on versions prior to 20w22a. By implementing the proposed fix, this no longer happens and prevents buggy behavior on these third-party servers.
Reproduction Steps
We may observe the effects of this bug by looking at the other reported issues which are directly caused by this bug. See
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477.The reproduction steps of
MC-191714are provided below, which shows this bug. When the farmland is turned into a full dirt block, the horse becomes inside the block, causing the client to decide to dismount the house and create a de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /gamerule randomTickSpeed 0 in-game.
- Run the command /fill ~-3 ~-1 ~-3 ~3 ~5 ~3 minecraft:glowstone hollow in-game.
- Run the command /fill ~-2 ~-1 ~-2 ~2 ~-1 ~2 minecraft:farmland in-game.
- Run the command */summon minecraft:horse ~ ~ ~ {Invulnerable:1b,NoAI:1b,PersistenceRequired:1b,SaddleItem: {id:saddle,Count:1}
*
,Tame:1} in-game.
- Mount the horse.
- Jump at least 1 block in the air with the horse, so the farmland is broken and you are dismounted from the horse.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
Another example of this bug can be found in
MC-190454, with steps to reproduce shown below. When the husk dies, the client decides to dismount the horse, creating the de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command */summon minecraft:husk ~ ~ ~ {NoAI:1b,Passengers:[
Unknown macro: {id}]}* in-game.
- Mount the horse.
- Run the command /summon minecraft:tnt in-game.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
This bug can also be seen through
MC-200286.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /fill ~ ~-1 ~ ~ ~-1 ~5 minecraft:obsidian in-game.
- Run the command /summon minecraft:end_crystal ~ ~ ~5 in-game.
- Run the command /summon minecraft:boat ~ ~ ~2 in-game.
- Mount the boat.
- Row the boat forward 3 blocks or until inside the end crystal.
- Look down and right click the boat.
- Notice the de-sync. Walking around and attempting to break blocks far away from the boat will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the boat. Sneaking causes the player to teleport back to the boat, as the server thinks the player has just dismounted the boat.
Code Analysis
In snapshot 20w22a, a change was made in the handleMovePlayer() method in net.minecraft.client.multiplayer.ClientPacketListener. This change added a conditional statement that allows the client to dismount a vehicle using the removeVehicle() method. In order to fix this bug, this change would need to be reverted. By doing so, it should no longer be possible to dismount an vehicle on the client, preventing any de-sync issues that may occur.
It may be possible that this was added to fix another bug or intentionally change behavior. In this case, reverting this change would not be beneficial to the game. We can check the changelog and fixed bugs from 20w22a relating to entity mounting in order to see if this is true. The bugs that fit this category are
MC-182967,MC-184629, andMC-184640, and changes that fit this category include the prevention of mounting entities while the shift key is held. I was unable to reproduce these resolved issues and was still unable to mount entities when the shift key was held using the proposed fix, meaning that the proposed fix in this issue should not conflict with other changes or issues from 20w22a.Workaround
The current workaround is to implement the proposed fix described in the Code Analysis section. A client-sided Fabric mod does this for versions 1.16 through 1.16.5 and snapshots 20w22a through 20w51a, with the source code linked here. Use the modification at your own risk, please audit and compile the code from source to ensure safety. As this modification was meant to fix
MC-202202, it does not work with snapshots 21w03a or later which contains a partial fix forMC-202202. This also means it back-ports the partial fix forMC-202202from 21w03a to earlier versions of the game. If you wish to fix this bug in versions 21w03a or later, it is possible to modify the source code and recompile the modification, however this process is not in the scope of this bug report and will not be described here.This bug report is a continuation of
MC-202202, as it was only partially fixed in 21w03a.
A change in snapshot 20w22a allows the client to dismount a vehicle independently from the server, causing a de-sync between the two. This can be triggered in a variety of ways, see Reproduction Steps.
When this de-sync occurs, the server will see the player as riding in the vehicle, while the client (the player) sees themselves as dismounted from the vehicle, allowing them walk around freely. Walking around and attempting to break blocks far away from the vehicle will cause vanilla anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the vehicle and cannot possibly break blocks that far. Sneaking causes the player to teleport back to the vehicle, as the server thinks the player has just dismounted the vehicle.
This issue was initially reported as
MC-202202, which observed that in snapshot 20w09a code was added to the client which allowed it to dismount a vehicle independently from the server using the sneak key. Since this caused de-sync issues during lag spikes, it was reverted in 21w03a leavingMC-202202resolved.However, the implemented fix for
MC-202202in 21w03a only considered situations when the client uses the sneak key to dismount. It was also noted inMC-202202that snapshot 20w22a added a way for clients to dismount a vehicle independently from the server during situations not caused by the sneak key, such as when the vehicle moves through a block. This discovery was only reported onMC-202202a short amount of time before the release of 21w03a, likely being the reason whyMC-202202was not entirely fixed.The rest of this bug report covers the unresolved part of
MC-202202, where the client can decide to dismount its own vehicle in situations not caused by sneaking, leading to a de-sync.Impact
This bug leads to a de-sync between the client and the server in several scenarios during vanilla gameplay, causing undesirable behavior. Some of these scenarios in the past have been reported as their own bugs, such as
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477. Fixing this bug using the proposed fix (see Code Analysis) will resolve all of these issues, as I was unable to reproduce any of them with the fix (see Workaround).This bug can additionally cause a de-sync on third-party servers if the server attempts to keep a player mounted on a vehicle through third-party modifications to the server software. This is a common mechanic used on minigame servers when the player must remain in a vehicle, such as a minecart on a roller coaster. While this was primarily fixed with 21w03a, situations where the client dismounts its own vehicle when not using the sneak key still cause a de-sync. For example, the client currently decides to dismount its vehicle when the vehicle moves through a block, which does not require using the sneak key, leading to a de-sync. This did not occur on versions prior to 20w22a. By implementing the proposed fix, this no longer happens and prevents buggy behavior on these third-party servers.
Reproduction Steps
We may observe the effects of this bug by looking at the other reported issues which are directly caused by this bug. See
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477.The reproduction steps of
MC-191714are provided below, which shows this bug. When the farmland is turned into a full dirt block, the horse becomes inside the block, causing the client to decide to dismount the house and create a de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /gamerule randomTickSpeed 0 in-game.
- Run the command /fill ~-3 ~-1 ~-3 ~3 ~5 ~3 minecraft:glowstone hollow in-game.
- Run the command /fill ~-2 ~-1 ~-2 ~2 ~-1 ~2 minecraft:farmland in-game.
- Run the command
/summon minecraft:horse ~ ~ ~ {Invulnerable:1b,NoAI:1b,PersistenceRequired:1b,SaddleItem:{id:saddle,Count:1},Tame:1}- Mount the horse.
- Jump at least 1 block in the air with the horse, so the farmland is broken and you are dismounted from the horse.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
Another example of this bug can be found in
MC-190454, with steps to reproduce shown below. When the husk dies, the client decides to dismount the horse, creating the de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command */summon minecraft:husk ~ ~ ~ {NoAI:1b,Passengers:[ Unknown macro: \{id}
]}* in-game.
- Mount the horse.
- Run the command /summon minecraft:tnt in-game.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
This bug can also be seen through
MC-200286.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /fill ~ ~-1 ~ ~ ~-1 ~5 minecraft:obsidian in-game.
- Run the command /summon minecraft:end_crystal ~ ~ ~5 in-game.
- Run the command /summon minecraft:boat ~ ~ ~2 in-game.
- Mount the boat.
- Row the boat forward 3 blocks or until inside the end crystal.
- Look down and right click the boat.
- Notice the de-sync. Walking around and attempting to break blocks far away from the boat will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the boat. Sneaking causes the player to teleport back to the boat, as the server thinks the player has just dismounted the boat.
Code Analysis
In snapshot 20w22a, a change was made in the handleMovePlayer() method in net.minecraft.client.multiplayer.ClientPacketListener. This change added a conditional statement that allows the client to dismount a vehicle using the removeVehicle() method. In order to fix this bug, this change would need to be reverted. By doing so, it should no longer be possible to dismount an vehicle on the client, preventing any de-sync issues that may occur.
It may be possible that this was added to fix another bug or intentionally change behavior. In this case, reverting this change would not be beneficial to the game. We can check the changelog and fixed bugs from 20w22a relating to entity mounting in order to see if this is true. The bugs that fit this category are
MC-182967,MC-184629, andMC-184640, and changes that fit this category include the prevention of mounting entities while the shift key is held. I was unable to reproduce these resolved issues and was still unable to mount entities when the shift key was held using the proposed fix, meaning that the proposed fix in this issue should not conflict with other changes or issues from 20w22a.Workaround
The current workaround is to implement the proposed fix described in the Code Analysis section. A client-sided Fabric mod does this for versions 1.16 through 1.16.5 and snapshots 20w22a through 20w51a, with the source code linked here. Use the modification at your own risk, please audit and compile the code from source to ensure safety. As this modification was meant to fix
MC-202202, it does not work with snapshots 21w03a or later which contains a partial fix forMC-202202. This also means it back-ports the partial fix forMC-202202from 21w03a to earlier versions of the game. If you wish to fix this bug in versions 21w03a or later, it is possible to modify the source code and recompile the modification, however this process is not in the scope of this bug report and will not be described here.
This bug report is a continuation of
MC-202202, as it was only partially fixed in 21w03a.
A change in snapshot 20w22a allows the client to dismount a vehicle independently from the server, causing a de-sync between the two. This can be triggered in a variety of ways, see Reproduction Steps.
When this de-sync occurs, the server will see the player as riding in the vehicle, while the client (the player) sees themselves as dismounted from the vehicle, allowing them walk around freely. Walking around and attempting to break blocks far away from the vehicle will cause vanilla anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the vehicle and cannot possibly break blocks that far. Sneaking causes the player to teleport back to the vehicle, as the server thinks the player has just dismounted the vehicle.
This issue was initially reported as
MC-202202, which observed that in snapshot 20w09a code was added to the client which allowed it to dismount a vehicle independently from the server using the sneak key. Since this caused de-sync issues during lag spikes, it was reverted in 21w03a leavingMC-202202resolved.However, the implemented fix for
MC-202202in 21w03a only considered situations when the client uses the sneak key to dismount. It was also noted inMC-202202that snapshot 20w22a added a way for clients to dismount a vehicle independently from the server during situations not caused by the sneak key, such as when the vehicle moves through a block. This discovery was only reported onMC-202202a short amount of time before the release of 21w03a, likely being the reason whyMC-202202was not entirely fixed.The rest of this bug report covers the unresolved part of
MC-202202, where the client can decide to dismount its own vehicle in situations not caused by sneaking, leading to a de-sync.Impact
This bug leads to a de-sync between the client and the server in several scenarios during vanilla gameplay, causing undesirable behavior. Some of these scenarios in the past have been reported as their own bugs, such as
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477. Fixing this bug using the proposed fix (see Code Analysis) will resolve all of these issues, as I was unable to reproduce any of them with the fix (see Workaround).This bug can additionally cause a de-sync on third-party servers if the server attempts to keep a player mounted on a vehicle through third-party modifications to the server software. This is a common mechanic used on minigame servers when the player must remain in a vehicle, such as a minecart on a roller coaster. While this was primarily fixed with 21w03a, situations where the client dismounts its own vehicle when not using the sneak key still cause a de-sync. For example, the client currently decides to dismount its vehicle when the vehicle moves through a block, which does not require using the sneak key, leading to a de-sync. This did not occur on versions prior to 20w22a. By implementing the proposed fix, this no longer happens and prevents buggy behavior on these third-party servers.
Reproduction Steps
We may observe the effects of this bug by looking at the other reported issues which are directly caused by this bug. See
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477.The reproduction steps of
MC-191714are provided below, which shows this bug. When the farmland is turned into a full dirt block, the horse becomes inside the block, causing the client to decide to dismount the house and create a de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /gamerule randomTickSpeed 0 in-game.
- Run the command /fill ~-3 ~-1 ~-3 ~3 ~5 ~3 minecraft:glowstone hollow in-game.
- Run the command /fill ~-2 ~-1 ~-2 ~2 ~-1 ~2 minecraft:farmland in-game.
- Run the command
/summon minecraft:horse ~ ~ ~ {Invulnerable:1b,NoAI:1b,PersistenceRequired:1b,SaddleItem:{id:saddle,Count:1},Tame:1}- Mount the horse.
- Jump at least 1 block in the air with the horse, so the farmland is broken and you are dismounted from the horse.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
Another example of this bug can be found in
MC-190454, with steps to reproduce shown below. When the husk dies, the client decides to dismount the horse, creating the de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command */summon minecraft:husk ~ ~ ~ {NoAI:1b,Passengers:[ Unknown macro: \{id}
]}* in-game.
- Mount the horse.
- Run the command /summon minecraft:tnt in-game.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
This bug can also be seen through
MC-200286.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /fill ~ ~-1 ~ ~ ~-1 ~5 minecraft:obsidian in-game.
- Run the command /summon minecraft:end_crystal ~ ~ ~5 in-game.
- Run the command /summon minecraft:boat ~ ~ ~2 in-game.
- Mount the boat.
- Row the boat forward 3 blocks or until inside the end crystal.
- Look down and right click the boat.
- Notice the de-sync. Walking around and attempting to break blocks far away from the boat will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the boat. Sneaking causes the player to teleport back to the boat, as the server thinks the player has just dismounted the boat.
Code Analysis
In snapshot 20w22a, a change was made in the handleMovePlayer() method in net.minecraft.client.multiplayer.ClientPacketListener. This change added a conditional statement that allows the client to dismount a vehicle using the removeVehicle() method. In order to fix this bug, this change would need to be reverted. By doing so, it should no longer be possible to dismount an vehicle on the client, preventing any de-sync issues that may occur.
It may be possible that this was added to fix another bug or intentionally change behavior. In this case, reverting this change would not be beneficial to the game. We can check the changelog and fixed bugs from 20w22a relating to entity mounting in order to see if this is true. The bugs that fit this category are
MC-182967,MC-184629, andMC-184640, and changes that fit this category include the prevention of mounting entities while the shift key is held. I was unable to reproduce these resolved issues and was still unable to mount entities when the shift key was held using the proposed fix, meaning that the proposed fix in this issue should not conflict with other changes or issues from 20w22a.Workaround
The current workaround is to implement the proposed fix described in the Code Analysis section. A client-sided Fabric mod does this for versions 1.16 through 1.16.5 and snapshots 20w22a through 20w51a, with the source code linked here. Use the modification at your own risk, please audit and compile the code from source to ensure safety. As this modification was meant to fix
MC-202202, it does not work with snapshots 21w03a or later which contains a partial fix forMC-202202. This also means it back-ports the partial fix forMC-202202from 21w03a to earlier versions of the game. If you wish to fix this bug in versions 21w03a or later, it is possible to modify the source code and recompile the modification, however this process is not in the scope of this bug report and will not be described here.This bug report is a continuation of
MC-202202, as it was only partially fixed in 21w03a.
A change in snapshot 20w22a allows the client to dismount a vehicle independently from the server, causing a de-sync between the two. This can be triggered in a variety of ways, see Reproduction Steps.
When this de-sync occurs, the server will see the player as riding in the vehicle, while the client (the player) sees themselves as dismounted from the vehicle, allowing them walk around freely. Walking around and attempting to break blocks far away from the vehicle will cause vanilla anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the vehicle and cannot possibly break blocks that far. Sneaking causes the player to teleport back to the vehicle, as the server thinks the player has just dismounted the vehicle.
This issue was initially reported as
MC-202202, which observed that in snapshot 20w09a code was added to the client which allowed it to dismount a vehicle independently from the server using the sneak key. Since this caused de-sync issues during lag spikes, it was reverted in 21w03a leavingMC-202202resolved.However, the implemented fix for
MC-202202in 21w03a only considered situations when the client uses the sneak key to dismount. It was also noted inMC-202202that snapshot 20w22a added a way for clients to dismount a vehicle independently from the server during situations not caused by the sneak key, such as when the vehicle moves through a block. This discovery was only reported onMC-202202a short amount of time before the release of 21w03a, likely being the reason whyMC-202202was not entirely fixed.The rest of this bug report covers the unresolved part of
MC-202202, where the client can decide to dismount its own vehicle in situations not caused by sneaking, leading to a de-sync.Impact
This bug leads to a de-sync between the client and the server in several scenarios during vanilla gameplay, causing undesirable behavior. Some of these scenarios in the past have been reported as their own bugs, such as
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477. Fixing this bug using the proposed fix (see Code Analysis) will resolve all of these issues, as I was unable to reproduce any of them with the fix (see Workaround).This bug can additionally cause a de-sync on third-party servers if the server attempts to keep a player mounted on a vehicle through third-party modifications to the server software. This is a common mechanic used on minigame servers when the player must remain in a vehicle, such as a minecart on a roller coaster. While this was primarily fixed with 21w03a, situations where the client dismounts its own vehicle when not using the sneak key still cause a de-sync. For example, the client currently decides to dismount its vehicle when the vehicle moves through a block, which does not require using the sneak key, leading to a de-sync. This did not occur on versions prior to 20w22a. By implementing the proposed fix, this no longer happens and prevents buggy behavior on these third-party servers.
Reproduction Steps
We may observe the effects of this bug by looking at the other reported issues which are directly caused by this bug. See
MC-190454,MC-191714,MC-200286,MC-201647, andMC-205477.The reproduction steps of
MC-191714are provided below, which shows this bug. When the farmland is turned into a full dirt block, the horse becomes inside the block, causing the client to decide to dismount the house and create a de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /gamerule randomTickSpeed 0 in-game.
- Run the command /fill ~-3 ~-1 ~-3 ~3 ~5 ~3 minecraft:glowstone hollow in-game.
- Run the command /fill ~-2 ~-1 ~-2 ~2 ~-1 ~2 minecraft:farmland in-game.
- Run the command
/summon minecraft:horse ~ ~ ~ {Invulnerable:1b,NoAI:1b,PersistenceRequired:1b,SaddleItem:{id:saddle,Count:1},Tame:1}- Mount the horse.
- Jump at least 1 block in the air with the horse, so the farmland is broken and you are dismounted from the horse.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
Another example of this bug can be found in
MC-190454, with steps to reproduce shown below. When the husk dies, the client decides to dismount the horse, creating the de-sync.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command
/summon minecraft:husk ~ ~ ~ {NoAI:1b,Passengers:[{id:"minecraft:horse",Invulnerable:1b,NoAI:1b,PersistenceRequired:1b,SaddleItem:{id:saddle,Count:1},Tame:1b}]}- Mount the horse.
- Run the command /summon minecraft:tnt in-game.
- Notice the de-sync. Walking around and attempting to break blocks far away from the horse will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the horse. Sneaking causes the player to teleport back to the horse, as the server thinks the player has just dismounted the horse.
This bug can also be seen through
MC-200286.
- Join a world in Creative mode with cheats enabled using version 20w22a or higher.
- Run the command /fill ~ ~-1 ~ ~ ~-1 ~5 minecraft:obsidian in-game.
- Run the command /summon minecraft:end_crystal ~ ~ ~5 in-game.
- Run the command /summon minecraft:boat ~ ~ ~2 in-game.
- Mount the boat.
- Row the boat forward 3 blocks or until inside the end crystal.
- Look down and right click the boat.
- Notice the de-sync. Walking around and attempting to break blocks far away from the boat will cause anti-cheat to prevent the blocks from being broken, as the server still thinks the player remains mounted on the boat. Sneaking causes the player to teleport back to the boat, as the server thinks the player has just dismounted the boat.
Code Analysis
In snapshot 20w22a, a change was made in the handleMovePlayer() method in net.minecraft.client.multiplayer.ClientPacketListener. This change added a conditional statement that allows the client to dismount a vehicle using the removeVehicle() method. In order to fix this bug, this change would need to be reverted. By doing so, it should no longer be possible to dismount an vehicle on the client, preventing any de-sync issues that may occur.
It may be possible that this was added to fix another bug or intentionally change behavior. In this case, reverting this change would not be beneficial to the game. We can check the changelog and fixed bugs from 20w22a relating to entity mounting in order to see if this is true. The bugs that fit this category are
MC-182967,MC-184629, andMC-184640, and changes that fit this category include the prevention of mounting entities while the shift key is held. I was unable to reproduce these resolved issues and was still unable to mount entities when the shift key was held using the proposed fix, meaning that the proposed fix in this issue should not conflict with other changes or issues from 20w22a.Workaround
The current workaround is to implement the proposed fix described in the Code Analysis section. A client-sided Fabric mod does this for versions 1.16 through 1.16.5 and snapshots 20w22a through 20w51a, with the source code linked here. Use the modification at your own risk, please audit and compile the code from source to ensure safety. As this modification was meant to fix
MC-202202, it does not work with snapshots 21w03a or later which contains a partial fix forMC-202202. This also means it back-ports the partial fix forMC-202202from 21w03a to earlier versions of the game. If you wish to fix this bug in versions 21w03a or later, it is possible to modify the source code and recompile the modification, however this process is not in the scope of this bug report and will not be described here.
Incorrect window resolution on HiDPI displayafter being scaled
When using the Minecraft Launcher on Linux with a HiDPI display, the resolution of the window is set incorrectly, causing it to appear blurry to the user compared to other nearby UI components such as the window title bar.
While the scaling of the window is handled correctly at 2×, the resolution is never changed to reflect this. For example, on a LoDPI display with scaling at 1×, the window is rendered at 1000×600 and displays in a 1000×600 pixel area. Each pixel rendered is displayed as one pixel on the screen. When this is taken to a HiDPI display with double the pixels on the screen, the window is correctly scaled by 2× to achieve the same physical size as the LoDPI display. The issue here arises when 2× scaling causes the window to render at 1000×600 in a 2000×1200 area, causing each pixel to display as 4 physical pixels. After this, the pixels are interpolated, causing them to appear blurry.
This is not a duplicate of
MCL-1, as1750MCL-1pertains to the scaling of the Minecraft Launcher, not the resolution of it. In my use case,1750MCL-1seems to have been fixed, as the window scales correctly at 2× the size. This issue may have been caused by the attempted fix for1750MCL-1.1750I have attached a screenshot of the issue using Minecraft Launcher version 2.2.909. Notice how the title bar is much more crisp and sharp to the eye than the rest of the Minecraft Launcher when zoomed in.
When using the Minecraft Launcher on Linux with a HiDPI display, the resolution of the window is set incorrectly, causing it to appear blurry to the user compared to other nearby UI components such as the window title bar.
While the scaling of the window is handled correctly at 2×, the resolution is never changed to reflect this. For example, on a LoDPI display with scaling at 1×, the window is rendered at 1000×600 and displays in a 1000×600 pixel area. Each pixel rendered is displayed as one pixel on the screen. When this is taken to a HiDPI display with double the pixels on the screen, the window is correctly scaled by 2× to achieve the same physical size as the LoDPI display. The issue here arises when 2× scaling causes the window to render at 1000×600 in a 2000×1200 area, causing each pixel to display as 4 physical pixels. After this, the pixels are interpolated, causing them to appear blurry.
This is not a duplicate of
MCL-10940, asMCL-10940pertains to the scaling of the Minecraft Launcher, not the resolution of it. In my use case,MCL-10940seems to have been fixed, as the window scales correctly at 2× the size. This issue may have been caused by the attempted fix forMCL-10940.I have attached a screenshot of the issue using Minecraft Launcher version 2.2.909. Notice how the title bar is much more crisp and sharp to the eye than the rest of the Minecraft Launcher when zoomed in.
Download and install Minecraft.deb
When launch the window size and text are not scaling with DPI
When using the Minecraft launcher on Linux, the launcher does not scale its content according to the system's display scaling factor. According to user reports, this affects multiple Linux distributions, desktop environments, and windowing systems.
Impact
Users with HiDPI displays have extreme difficulty viewing and navigating the Minecraft launcher. Since the launcher does not scale properly according to the display scaling factor, the size of content is very small. For example, text with a 12px font size would be 4px on a typical 4k 13.3" laptop with 300% scaling (equivalent size as 150% scaling on a 1080p 13.3" display).
How to reproduce
- Set a display scaling factor on your Linux distribution that is not 100%. For example, on Linux distributions with the GNOME desktop environment, go to Settings > Displays > Scale and set it to 200%.
- Open the Minecraft Launcher.
→The scale of the launcher content does not match that of the system. On HiDPI displays, the text size is unreadable and the interface is difficult to navigate.
Notes
- If I remember correctly, this is an upstream issue with CEF. However, I can't seem to find a relevant issue report.
- In launcher versions prior to 2.2.2159, the content was scaled correctly. However, the resolution of the window was not changed, causing it to appear blurry. See
MCL-16405.- Since launcher version 2.2.2159, the size and resolution of the window are set properly, but the content scale is not. Try running the launcher with GDK_SCALE=1, GDK_SCALE=2, and GDK_SCALE=3. Notice how the window size grows, but the content size does not.
Debian launcher not scaling with HiDPILauncher does not scale properly on Linux, affecting HiDPI displays
When using the Minecraft launcher on Linux, the launcher does not scale its content according to the system's display scaling factor. According to user reports, this affects multiple Linux distributions, desktop environments, and windowing systems.
Impact
Users with HiDPI displays have extreme difficulty viewing and navigating the Minecraft launcher. Since the launcher does not scale properly according to the display scaling factor, the size of content is very small. For example, text with a 12px font size would be 4px on a typical 4k 13.3" laptop with 300% scaling (equivalent size as 150% scaling on a 1080p 13.3" display).
How to reproduce
- Set a display scaling factor on your Linux distribution that is not 100%. For example, on Linux distributions with the GNOME desktop environment, go to Settings > Displays > Scale and set it to 200%.
- Open the Minecraft Launcher.
→Notes
- If I remember correctly, this is an upstream issue with CEF. However, I can't seem to find a relevant issue report.
- In launcher versions prior to 2.2.2159, the content was scaled correctly. However, the resolution of the window was not changed, causing it to appear blurry. See
MCL-16405.- Since launcher version 2.2.2159, the size and resolution of the window are set properly, but the content scale is not. Try running the launcher with GDK_SCALE=1, GDK_SCALE=2, and GDK_SCALE=3. Notice how the window size grows, but the content size does not.
When using the Minecraft launcher on Linux, the launcher does not scale its content according to the system's display scaling factor. According to user reports, this affects multiple Linux distributions, desktop environments, and windowing systems.
Impact
Users with HiDPI displays have extreme difficulty viewing and navigating the Minecraft launcher. Since the launcher does not scale properly according to the display scaling factor, the size of content is very small. For example, text with a 12px font size would be 4px on a typical 4k 13.3" laptop with 300% scaling (equivalent size as 150% scaling on a 1080p 13.3" display).
How to reproduce
- Set a display scaling factor on your Linux distribution that is not 100%. For example, on Linux distributions with the GNOME desktop environment, go to Settings > Displays > Scale and set it to 200%.
- Open the Minecraft Launcher.
→Notes
If I remember correctly, this is an upstream issue with CEF. However, I can't seem to find a relevant issue report.This does appear to be an upstream issue. When using the latest beta build of the CEF sample application (94.2.2+g0c2cc26+chromium-94.0.4606.50), the scaling of the content is not correct on a HiDPI display.- In launcher versions prior to 2.2.2159, the content was scaled correctly. However, the resolution of the window was not changed, causing it to appear blurry. See
MCL-16405.- Since launcher version 2.2.2159, the size and resolution of the window are set properly, but the content scale is not. Try running the launcher with GDK_SCALE=1, GDK_SCALE=2, and GDK_SCALE=3. Notice how the window size grows, but the content size does not.
Affects launcher version 2.2.5516 (beta, released 19 September 2021). This version does not yet exist in the Affects Version/s category, so this comment is temporary until this issue can be updated properly.
Screenshot from 2021-11-22 15-45-38.png
I have access to version 2.2.7955, see the screenshot below. This version appears to have just been made available, so the versions on the bug tracker are probably incorrectly marked as unreleased.
When using the Minecraft launcher on Linux, the launcher cannot open game directories that are specified with a relative path. Note the game still launches and functions with relative game directories.
How to reproduce
- Open the Minecraft launcher.
- Navigate to the Installations tab under Minecraft: Java Edition.
- Create a
nnew installation by pressing New Installation.- Set the game directory to any relative path of the .minecraft folder. For example, the relative paths myprofile and ./myprofile both represent the absolute path /home/user/.minecraft/myprofile.
- Create the installation by pressing Create.
- Open the game directory of the newly created profile by pressing the folder icon.
→
When using the Minecraft launcher on Linux, the launcher cannot open game directories that are specified with a relative path. Note the game still launches and functions with relative game directories.
How to reproduce
- Open the Minecraft launcher.
- Navigate to the Installations tab under Minecraft: Java Edition.
- Create a new installation by pressing New Installation.
- Set the game directory to any relative path of the .minecraft folder. For example, the relative paths myprofile and ./myprofile both represent the absolute path /home/user/.minecraft/myprofile.
- Create the installation by pressing Create.
Open the game directory of the newly created profile by pressing the folder icon.
→When using the Minecraft launcher on Linux, the launcher cannot open game directories that are specified with a relative path. Note the game still launches and functions with relative game directories.
How to reproduce
- Open the Minecraft launcher.
- Navigate to the Installations tab under Minecraft: Java Edition.
- Create a new installation by pressing New Installation.
- Set the game directory to any relative path of the .minecraft folder. For example, the relative paths myprofile and ./myprofile both represent the absolute path /home/user/.minecraft/myprofile.
- Create the installation by pressing Create.
- Attempt to open the game directory of the newly created profile by pressing the folder icon.
→
When using the Minecraft launcher on Linux, the launcher cannot open game directoriesthatare specified with a relative path. Note the game still launches andfunctions withrelative game directories.How to reproduce
- Open the Minecraft launcher.
- Navigate to the Installations tab under Minecraft: Java Edition.
- Create a new installation by pressing New Installation.
- Set the game directory to any relative path of the .minecraft folder. For example, the relative paths myprofile and ./myprofile both represent the absolute path /home/user/.minecraft/myprofile.
- Create the installation by pressing Create.
- Attempt to open the game directory of the newly created profile by pressing the folder icon.
→The launcher cannot open game directories in the system file picker when they are specified with a relative path. Note the game still launches and uses relative game directories without issue.
How to reproduce
- Open the Minecraft launcher.
- Navigate to the Installations tab under Minecraft: Java Edition.
- Create a new installation by pressing New Installation.
- Set the game directory to any relative path of the .minecraft folder. For example, the relative paths myprofile and ./myprofile both represent the absolute path /home/user/.minecraft/myprofile.
- Create the installation by pressing Create.
- Attempt to open the game directory of the newly created profile by pressing the folder icon.
→
Launcher cannot open relative game directoriesonLinuxCannot open relative game directories in system file picker
The launcher cannot open game directories in the system file picker when they are specified with a relative path. Note the game still launches and uses relative game directories without issue.How to reproduce
- Open the Minecraft launcher.
- Navigate to the Installations tab under Minecraft: Java Edition.
- Create a new installation by pressing New Installation.
- Set the game directory to any relative path of the .minecraft folder. For example, the relative paths myprofile and ./myprofile both represent the absolute path /home/user/.minecraft/myprofile.
- Create the installation by pressing Create.
- Attempt to open the game directory of the newly created profile by pressing the folder icon.
→On macOS and Linux operating systems, the launcher cannot open game directories in the system file picker when they are specified with a relative path. Note the game still launches and uses relative game directories without issue.
How to reproduce
- Open the Minecraft launcher using a macOS or Linux operating system.
- Navigate to the Installations tab under Minecraft: Java Edition.
- Create a new installation by pressing New Installation.
- Set the game directory to any relative path of the .minecraft folder. For example, the relative paths myprofile and ./myprofile both represent the absolute path /home/user/.minecraft/myprofile.
- Create the installation by pressing Create.
- Launch the game once with the newly created profile to create the game directory.
- Attempt to open the game directory of the newly created profile by pressing the folder icon.
→
Note: I'm aware of the existence of MC-130265 and its resolution, however this case is different, because the sky fog color doesn't change depending on the camera angle, please don't close this as dupe.
Fog color in the end dimension doesn't seem to match the color of the skybox, causing things far from the player to be visible instead of being hidden by the fog. MC-130265 covered the issue that affected the overworld, but got marked as Won't Fix, probably due to its complexity seeming that the sky fog color changed depending on the camera angle on sunsets, and maybe because it really wasn't that noticeable.
In the end however, it doesn't act the same. The sky fog never changes color depending of the camera angle, which might be easier to fix. Also here, the issue is more noticeable due to how things contrast strongly with the background, creating silhouettes.
The following proposal it's just an interpretation of another proposal that doesn't belong to me, all credit goes to Bytzo.
The fix in this case, would need to be making the sky not render past the fog (in this case, reduced fog). That would also make it consistent with how the nether fog works (nether doesn't have skybox i believe).
Expected Result
Observed Result
While it might fix the problem, a side-effect would also be the sky noise effect to be lost due to the fog, but at the same time it would match the Bedrock Edition behavior. That would be up to a decision of matching parity.
Sources:
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
Gave ownership to Bytzo, as they have been the one updating it through Discord requests recently.
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
The bug
A server-side lag spike sometimes occurs when attempting to locate a buried treasure or opening/breaking a chest containing a map. Some players have reported crashes caused by this issue, one of which is attached.
Code analysis
Code analysis by Bytzo can be found in this comment.
After comparing the rideTick() method across several versions, I can confirm this change was made in snapshot 20w09a. This means that versions 20w09a through 20w49a are affected by this bug.
As a temporary solution, I have created a Fabric mod for 1.16 that implements the proposed change by @Daniël Goossens. Using this mod, players are unable to dismount entities through the client, meaning servers that attempt to block entity dismounting will avoid a de-sync issue with the client. This is especially useful on third-party mini-game servers that make use of this behavior, such as Hypixel's Turbo Kart Racers which had to be disabled on 1.16 and above due to this change. The source for the Fabric mod can be found at https://github.com/bytzo/mc-202202, with pre-compiled releases here.
It is however important to note that the proposed solution does not fix other mentioned issues such as
MC-191714andMC-205477. I was able to reproduce both of these issues with the Fabric mod containing the fix.Since we know this behavior was changed in 20w09a, we can determine that the fix for
MC-186085was not the cause of this bug, asMC-186085was fixed in 1.16 Pre-release 3 which is after 20w09a. In addition to this, we can check the fixed bugs from 20w09a to see if any of those fixes may have caused this bug. 20w09a has three fixed bugs related to entity mounting, which areMC-111726,MC-148869, andMC-149042. I was not able to reproduce any of these bugs using the Fabric mod containing the fix. This should mean that this bug was not caused by fixes for other issues.Recently on various mini-game servers, I noticed that the client is still able to dismount vehicles and experience a de-sync in some rare scenarios even with the modification containing the current proposed fix. While looking into what caused this, I found a second change that allows the client to dismount an entity, causing the de-sync I experienced. This change was made in snapshot 20w22a and is located in the handleMovePlayer() method in net.minecraft.client.multiplayer.ClientPacketListener. In this method, a conditional statement was added that allows the client to dismount an entity if certain conditions are met. In order to completely fix this bug, the change in the handleMovePlayer() method during 20w22a should be reverted in addition to the current proposed fix in the rideTick() method.
Unlike the current proposed change in the rideTick() method, the new proposed change in the handleMovePlayer() method does resolve
MC-191714andMC-205477. Using an updated version of the Fabric mod on 1.16.5 which reverts the change in the handleMovePlayer() method, I was unable to reproduce both of these issues. This means that @Daniël Goossens was initially correct that a change allowing clients to dismount entities lead to bothMC-191714andMC-205477, however the mentioned change in the rideTick() method was not the specific cause.By implementing the changes above in both the rideTick() and handleMovePlayer() methods, there should no longer be any de-sync issues related to entity dismounting, as it should not be possible to dismount entities through the client. In addition, third-party servers regain the ability to keep players mounted on entities, which was used in many different ways (such as preventing players from dismounting minecarts on a roller coaster) before these changes occurred. Many third-party servers still attempt to make use of this behavior, causing undesirable issues when using the newest version of the game compared to prior versions.
Of course, the changes in both the rideTick() and handleMovePlayer() methods causing this bug might have been done to fix other bugs or intentionally change behavior, so reverting them would not be beneficial to the game. As done before, we can check the changelog and fixed bugs from 20w22a relating to entity mounting in order to see if this is the case. These are
MC-182967,MC-184629, andMC-184640. A change was also made in 20w22a that prevents mounting entities while the shift key is held. I was unable to reproduce these previously resolved issues and was still unable to mount entities when the shift key was held using both proposed fixes above, meaning that the proposed fix in this issue should not conflict with other changes or issues from 20w22a.Finally, the reproduction steps for this issue can be updated since we know more about the bug.
To observe the impact of the change in the rideTick() method (reproduction steps by @Daniël Goossens still work, however require a modified server):
To observe the impact of the change in the handleMovePlayer() method:
I can confirm the changes in the rideTick() and handleMovePlayer() methods that cause this bug still remain in 20w51a, 1.16.5-rc1, and 1.16.5.
In snapshot 21w03a, it appears only the fix in the rideTick() method was implemented. This was likely due to the fix in the handleMovePlayer() method being discovered right before the release of 21w03a. I have opened a second issue at
MC-212291to address this as recommended by a moderator.With launcher version 2.2.2159, it appears that this has been resolved, however
MCL-10940does occur again. This issue may be marked as resolved.Starting from launcher version 2.2.2159, I am experiencing this issue again. I think this issue affects all Linux versions of the launcher, not just the Debian one, since I have experienced it on other Linux distributions. If it is helpful, I am using X11 and Mutter. I have attached a screenshot of the issue on version 2.2.2159.
Updated the issue summary, as the issue affects more than just the launcher Debian package. Also updated the issue description with more details.
This is most likely an issue with CEF. In the latest beta build of the CEF sample application (which you can download from https://cef-builds.spotifycdn.com/index.html), the scaling is not correct on a HiDPI display.
Passing the --force-device-scale-factor argument should allow for the scaling to be manually overridden in CEF applications. This works with the CEF sample application and is used in the Spotify Flatpak to support HiDPI displays.
However, this does not appear to work with the Minecraft Launcher. Running minecraft-launcher --force-device-scale-factor=2 has no effect on the scaling of the application. This still does not work when executing the CEF binary directly (located at .minecraft/launcher/minecraft-launcher) with the argument.
Because of this, I don't think there are any current workarounds for this issue. If possible, having the ability to set the --force-device-scale-factor argument could be a temporary workaround until a proper fix exists upstream.
I have reproduced this issue using macOS, so it is not exclusive to the Linux version. Is anyone able to confirm this issue on Windows? (note Windows uses the \ character instead of the / character for file paths)
I am unable to reproduce this issue on Windows. This issue seems to only affect macOS and Linux.
Yes, this issue still occurs with the newest version of the launcher. I can reproduce this issue using version 1093 of the launcher bootstrap and version 2.2.8906 of the launcher itself on Fedora Workstation version 35.
I am not exactly sure what you mean by this. While the Minecraft Launcher on macOS is unique since its data directory is called minecraft instead of .minecraft, reproducing this bug does not require referencing the Minecraft folder at all. Instead, this issue deals with relative directories of the Minecraft folder, such as path/to/profile or ./path/to/profile which should point to ~/Library/Application Support/minecraft/path/to/profile.
I test Linux using Fedora Workstation version 35 and test macOS using macOS Big Sur 11.1.
Interestingly enough, I have experienced this issue with both HRTF being stuck on and HRTF being stuck off, depending on where I run the game (in a third party launcher HRTF is stuck on, but in FabricMC's Loom dev environment HRTF is stuck off). After some investigation, I think I found the cause of the issue.
Code Analysis
In com.mojang.blaze3d.audio.Library, the init method calls the setHrtf method to set directional audio on or off.
Inside the setHrtf method, the alcResetDeviceSOFT method is called on the current audio device with two attributes. The ALC_HRTF_SOFT attribute sets HRTF on or off, and the ALC_HRTF_ID_SOFT attribute sets the index of the desired HRTF file, which is currently hardcoded to 0.
According to this text document, the alcResetDeviceSOFT method should be used for resetting an audio device's attributes so that they may be changed during runtime.
While the code above functions correctly in resetting an audio device's attributes with new values, its effect is imminently overridden by the creation of a new audio device context, which replaces the current audio device's attributes.
Before Minecraft snapshot 23w31a, this was not an issue as no attributes were given in the creation of a new context. However, in 23w31a, the ALC_OUTPUT_LIMITER_SOFT attribute was added to the context creation, nullifying the effect of the setHrtf method from before.
Probably the most straightforward way to fix this is to move the calling of setHrtf after the creation of the audio device's context.
However, this creates the opposite problem where the ALC_OUTPUT_LIMITER_SOFT attribute is nullified by calling setHrtf. So, it may be simpler to just set all attributes at once.
I have implemented these changes in a FabricMC mod for testing purposes, and it seems to have fixed the issue for me. The source code for the mod can be accessed here: https://github.com/bytzo/mc-265514. Obligatory warning to proceed with caution: while I can trust myself, you can't trust me, so please audit the code yourself before compiling or running.
On multiplayer servers, I have also experienced this freeze when others were exploring shipwrecks. After some attempts over the months, I think I might have a possible solution.
Code Analysis
When using the /locate command on buried treasure, or when buried treasure maps are generated, eventually the getNearestGeneratedStructure() method (the random spread one, not the concentric rings one) in net.minecraft.world.level.chunk.ChunkGenerator is called. This loops over potential structure chunks around the player according to each structure's spread and calls several other methods to determine whether or not the structure can generate there. This includes the findValidGenerationPoint() method in net.minecraft.world.level.levelgen.structure.Structure, which is called to return a valid generation point if the generation point is in a valid biome for that structure.
The buried treasure structure has a spread of 1. This means that every single chunk around the player will searched until a buried treasure structure is found. In comparison, other structures usually have much larger spread, meaning only a few specific chunks around the player will be searched. Buried treasure structures are still kept rare despite their small spread using the LEGACY_TYPE_2 frequency reduction method.
While a structure having a spread of 1 alone does not cause a lag spike, its combination with other factors of the buried treasure structure can. The buried treasure structure must calculate the terrain height in order to find its generation point. findGenerationPoint() calls onTopOfChunkCenter() in net.minecraft.world.level.levelgen.structure.structures.BuriedTreasureStructure. And since findGenerationPoint() is called for every potential structure chunk through findValidGenerationPoint(), a small spread size of 1 causes the terrain height to be calculated many, many times, creating the observable lag spike.
Code Fix
Similar to normal world generation in the createStructures() method in net.minecraft.world.level.chunk.ChunkGenerator, the return value of the method isStructureChunk() in net.minecraft.world.level.levelgen.structure.placement.StructurePlacement can be checked before attempting to find a valid generation point in potential structure chunks. This way, potential structure chunks that are not valid structure chunks according to the frequency reduction method are skipped and the terrain height does not have to be calculated many times for buried treasure.
One possible place where this check could be implemented is in the canCreateStructure() method in net.minecraft.world.level.levelgen.structure.StructureCheck, which returns whether or not a structure can be generated in a certain chunk.
Note that access to the chunk generator state in StructureCheck is needed in order to call isStructureChunk(). When constructing net.minecraft.world.level.levelgen.structure.StructureCheck in net.minecraft.server.level.ServerLevel, the chunk generator state can passed to StructureCheck by calling getGeneratorState() on the field chunkSource.
Impact
In Minecraft 1.20.4, I measured the time it took to locate a buried treasure structure using the /locate command after creating a fresh world with seed 6071974100908662531, both without and with the potential fix.
At least for this trial, there was a 5211% increase in speed! To be sure that the fix was not negatively impacting other things, I also measured the time to locate other structures both without and with the potential fix.
Results indicated that there were no significant changes in the speed of locating other structures without and with the potential fix.
Fix Implementation
I have implemented the fix outlined above in a FabricMC mod for testing purposes, which seems to be successful in resolving the issue. It can be run on both the client and the server. The source code for the mod can be accessed here: https://github.com/bytzo/mc-249136.
This issue might be fixed with the latest versions of CEF. According to this commit which removes HiDPI-enabling code in CEF for Windows, Chromium was changed to support HiDPI by default. When testing the latest cefsimple sample application on Fedora Workstation 39, everything seems to be scaled properly. So, sometime in between whatever version I tested 2 years ago and the latest version of CEF, HiDPI support on Linux was fixed. The fixed version of CEF might be around or before April 2023 based on the time the commit linked above was made: I am unsure of the exact version this was fixed since building one version of CEF takes several hours on my machine making a bisect impractical.
This appears to be fixed in Minecraft version 24w04a. I have tested this on the game client and have looked at the code, which both indicate this being fixed.
The method isStructureChunk in StructurePlacement was refactored so that the logic for using a structure's frequency reduction method is in its own method, called applyAdditionalChunkRestrictions. This method is then used before starting to check for a structure in checkStart.
This is a much better solution than the solution I previously wrote since the logic for the frequency reduction method does not require access to a ChunkGeneratorStructureState, so refactoring it out allows for a much cleaner check in StructureCheck. I wrote my solution was in a way so that the game logic would not have to be copied to the mod containing the fix, and I determined that extracting the logic from isStructureChunk would be difficult. So, instead I used the whole method which required a very messy way of accessing a ChunkGeneratorStructureState and structure placement within StructureCheck.
Since this appears to be fixed as of now, I believe this issue can be marked as resolved.
Oops, it looks like this was already marked as resolved while I was checking and writing the below comment. I probably should have refreshed the page before posting, sorry!
As of version 2.29.15, the launcher seems to be scaling correctly when using Fedora Workstation 40 at 200% scaling. Is anyone else able to confirm that this is issue fixed?