Portals generate far-away chunks & set player on fire
The bug
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival mode, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
These issues are usually characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. E.g., if you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that exact location.
Related issues
MC-90062 - which covers the other effects of the cheat engine changes
MC-86850 - which covers how taking certain actions may cause you to remain at the erroneous location.
The fix
A suggested fix by Xcom6000, Timothy Miller, and [Mod] Pokechu22 can be found in this comment.
Linked Issues
is duplicated by11
MC-97523Nether Portals briefly teleport players to original location in alternate dimensionDuplicateMC-98209Moved too quicklyDuplicateMC-101184bug élytraDuplicateMC-101581Entering certain nether portals causes burningDuplicateMC-103917Cathing fire when using the nether portalDuplicateMC-105349taking damage when going through portal to the nether in SurvivalDuplicateMC-105552I Burn when i go out of the NetherDuplicateMC-108832Fire through nether portalDuplicateMC-110676On fire after entering the NetherDuplicateMC-111049Catching Fire in Nether PortalDuplicateMC-116942Entering nether portal creates stray chunks at coordinates of other dimensionDuplicaterelates to9
MC-86850Ender Pearling through a nether portal in the over-world tp's you to the portals nether coordinates but in the overworldFixedMC-89928Portals not placing the player at correct coordinates causing them to take suffocation damageCannot ReproduceMC-116758Enter/exit nether, server reports: <player> moved too quicklyFixed
MCPE-28765Player Takes Damage Going Through Nether PortalFixedMC-123364Player-in-block checking happens after block collision events are done
NormalMC-262094Spectators teleport to the wrong spot when ceasing to spectate a player who has changed dimensionsConfirmedMC-90062Server spams "Player/Vehicle moving too quickly" to the log when players are using Elytra/Boats or flying at max. speedAwaiting ResponseMC-102641Crashing/quitting while loading nether, teleports player to the overworld coordinates *IN* the netherAwaiting ResponseMC-235414Player desynchronization with Nether PortalsFixed
Created Issue:
Minecraft teleporting players back if they move too quickly
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting players back, thinking they moved too quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension
- Portals setting the player on fire if there is lava at said location
- Speed 2 causing the player to rubberband back and forth.
Linked Issues
is duplicated by1
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting players back, thinking they moved too quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension
- Portals setting the player on fire if there is lava at said location
- Speed 2 causing the player to rubberband back and forth.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting players back, thinking they moved too quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Speed 2 causing the player to rubberband back and forth. - NOT CONFIRMED
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting players back, thinking they moved too quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Speed 2 causing the player to rubberband back and forth. - NOT CONFIRMED
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting players back, thinking they moved too quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time ignoring hunger regen
- Easily survivable if saturation is high - you only take 1 or 2 hearts
- Speed 2 causing the player to rubberband back and forth. - NOT CONFIRMED
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting players back, thinking they moved too quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time ignoring hunger regen
- Easily survivable if saturation is high - you only take 1 or 2 hearts
- Speed 2 causing the player to rubberband back and forth. - NOT CONFIRMED
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting players back, thinking they moved too quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time ignoring hunger regen
- Easily survivable if saturation is high - you only take 1 or 2 hearts
- Speed 2 causing the player to rubberband back and forth. - NOT CONFIRMED (see
MC-89928for claim)This issue is generally characterised by a debug message in the chat claiming that a player moved too quickly such as:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000). However, this message does not appear 100% of the time.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting players back, thinking they moved too quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time ignoring hunger regen
- Easily survivable if saturation is high - you only take 1 or 2 hearts
- Speed 2 causing the player to rubberband back and forth. - NOT CONFIRMED (see
MC-89928(comments) for claim)This issue is generally characterised by a debug message in the chat claiming that a player moved too quickly such as:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000). However, this message does not appear 100% of the time.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting
players back, thinking they movedtoo quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time ignoring hunger regen
- Easily survivable if saturation is high - you only take 1 or 2 hearts
- Speed
2causing the player to rubberband back and forth. -NOTCONFIRMED(seeMC-89928(comments) for claim)This issue is generally characterised by a debug message in the chat claiming that a player moved too quickly such as:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000). However, this message does not appear 100% of the time.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players backfor moving too quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time ignoring hunger regen
- Easily survivable if saturation is high - you only take 1 or 2 hearts
- Speed causing the player to rubberband back and forth. - CONFIRMED
- Only for swiftness 120/130+
This issue is generally characterised by a debug message in the chat claiming that a player moved too quickly such as:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000). However, this message does not appear 100% of the time.
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor speed effect in to maximum movement speed in one tick
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players backfor moving too quickly. Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time
ignoring hunger regen- Easily survivable if saturation is high - you only take 1 or 2 hearts
- Speed causing the player to rubberband back and forth. - CONFIRMED
- Only for swiftness 120/130+
This issue is
generallycharacterised by a debug message in the chat claiming that a player moved too quicklysuch as:[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000). However, this message does not appear 100% of the time.
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor s
peedeffect in to maximum movement speedin one tick
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Speed causing the player to rubberband back and forth. - CONFIRMED
- Only for swiftness 120/130+
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000). However, this message does not appear 100% of the time.
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor swiftness effect in to maximum movement speed before anti-cheat is engaged
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
is duplicated by
relates to
this bug tracker is not a discussion forum, if it doesn't relate to the bug it's not the place to say it here
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- S
peedcausing the player to rubberband back and forth. - CONFIRMED
- Only for swiftness 120/130+
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000). However, this message does not appear 100% of the time.
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor swiftness effect in to maximum movement speed before anti-cheat is engaged
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness ststus effect causing the player to rubberband back and forth. - CONFIRMED
- Can cause desync e.g. ghost blocks
- Can be achieved in survival with beacons
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000). However, this message does not appear 100% of the time.
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor swiftness effect in to maximum movement speed before anti-cheat is engaged
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness ststus effect causing the player to rubberband back and forth. - CONFIRMED
- Can cause desync e.g. ghost blocks
Can be achieved in survival with beaconsThis issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
However, this message does not appear 100% of the time.Possible fixes:
- Check if player is using portal before TPing them back.
- Factor swiftness effect in to maximum movement speed before anti-cheat is engaged
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness ststus effect causing the player to rubberband back and forth. - CONFIRMED
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Can be achieved in survival with beacons
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor swiftness effect in to maximum movement speed before anti-cheat is engaged
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness st
stus effect causing the player to rubberband back and forth. - CONFIRMED
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Can be achieved in survival with beacons
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor swiftness effect in to maximum movement speed before anti-cheat is engaged
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth. - CONFIRMED
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Can be achieved in survival with beacons
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor swiftness effect in to maximum movement speed before anti-cheat is engaged
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
is duplicated by
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension. - CONFIRMED
- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location. - CONFIRMED
- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth. - CONFIRMED
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Can be achieved in survival with beacons
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
Check if player is using portal before TPing them back.- Factor swiftness effect
intomaximum movement speed before anti-cheat is engaged
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Can be achieved in survival with beacons
- Flying in creative / spectator mode causing the player to rubberband back and forth.
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Can be achieved in survival with beacons
- Flying in creative / spectator mode causing the player to rubberband back and forth.
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Can be achieved in survival with beacons-
- Flying in creative / spectator mode causing the player to rubberband back and forth.-
MC-98209-
(Could not reproduce claims in strikethrough text)This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Can be achieved in survival with beacons-
- Flying in creative / spectator mode causing the player to rubberband back and forth.-
MC-98209-
(Could not reproduce claims in strikethrough text)This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
Can be achieved in survival with beaconsFlying in creative / spectator mode causing the player to rubberband back and forth.
MC-98209
(Could not reproduce claims in strikethrough text)This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
Can be achieved in survival with beaconsFlying in creative / spectator mode causing the player to rubberband back and forth.
MC-98209
(Could not reproduce claims in strikethrough text)This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
Can be achieved in survival with beaconsFlying in creative / spectator mode causing the player to rubberband back and forth.(Could not reproduce claims in strikethrough text)
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
is duplicated by
is duplicated by
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
Can be achieved in survival with beaconsFlying in creative / spectator mode causing the player to rubberband back and forth.(Could not reproduce claims in strikethrough text)
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Have not yet confirmed first hand
Flying in creative / spectator mode causing the player to rubberband back and forth.(Could not reproduce claims in strikethrough text)
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Have not yet confirmed first hand
- Flying in creative / spectator mode
causing the player to rubberband back and forth.
(Could not reproduce claims in strikethrough text)This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Flying with elytra
- Flying in creative / spectator mode
Server lag e.g. having another player on the server makes these more reproducible.
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Flying with elytra
- Flying in creative / spectator mode
Server lag e.g. having another player on the server or allocating lettle RAM makes these more reproducible.
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
Assigning little ram to minecraft using the arguments in the launcher profile
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Flying with elytra
- Flying in creative / spectator mode
Server lag e.g. having another player on the server or allocating l
ettle RAM makes these more reproducible.This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Flying with elytra
- Flying in creative / spectator mode
Server lag e.g. having another player on the server or allocating little RAM makes these more reproducible.
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
Did you mean "little RAM"?
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Flying with elytra
- Flying in creative / spectator mode
Server lag e.g. having another player on the server or allocating l
ittle RAM makes these more reproducible.This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Flying with elytra
- Flying in creative / spectator mode
- Going full speed on a boat
Server lag e.g. having another player on the server or allocating lettle RAM makes these more reproducible.
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Flying with elytra
- Flying in creative / spectator mode
- Going full speed on a boat
Server lag e.g. having another player on the server or allocating l
ettle RAM makes these more reproducible.This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Flying with elytra
- Flying in creative / spectator mode
- Going full speed on a boat
Server lag e.g. having another player on the server or allocating little RAM makes these more reproducible.
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effectinto fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Flying with elytra
- Flying in creative / spectator mode
- Going full speed on a boat
Server lag e.g. having another player on the server or allocating little RAM makes these more reproducible.
This issue is characterised by a debug message in the chat claiming that a player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal from the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before TPing them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact loction of the other dimension's portal loads
- Only the blocks are generated: entities do not spawn
- InhabitedTime of that chunk is 0
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time
- Easily survivable if saturation is high - you only take 1 or 2 hearts' damage
- Swiftness status effect causing the player to rubberband back and forth.
- Can cause desync e.g. ghost blocks
- Most noticeable at very high (100+) swiftness levels
- Have not reproduced in survival
- Falling at terminal velocity
- Flying with elytra
- Flying in creative / spectator mode
- Going full speed on a boat
Server lag e.g. having another player on the server or allocating little RAM makes these more reproducible.
This issue is characterised by a debug message in the chat claiming that
aplayer moved too quickly:[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal
fromthe overworld at 10 000, 10 000).Possible fixes:
- Check if player is using portal before
TPing them back.- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
- In this case you would be able to lower the threshold for detecting speed hacks while still allowing all levels of swiftness to work
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the blocks are generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading.
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time.
- Easily survivable in survival if saturation is high - you only take 1 or 2 hearts' damage.
- The following actions can cuase the player to rubberband back and forth:
- Swiftness status effect.
- Most noticeable at higher swiftness levels.
- Jump boost status effect.
- Only at officially unsupported (>5) levels.
- Falling at terminal velocity.
- Flying with elytra.
- Flying in creative / spectator mode.
- Moving at full speed on a boat.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes these effects more reproducible.
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the blocks are generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading.
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time.
- Easily survivable in survival if saturation is high - you only take 1 or 2 hearts' damage.
- The following actions can cuase the player to rubberband back and forth:
- Swiftness status effect.
- Most noticeable at higher swiftness levels.
- Jump boost status effect.
- Only at officially unsupported (>5) levels.
- Falling at terminal velocity.
- Flying with elytra.
- Flying in creative / spectator mode.
- Moving at full speed on a boat.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes these effects more reproducible.
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the blocks are generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading.
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time.
- Easily survivable in survival if saturation is high - you only take 1 or 2 hearts' damage.
- The following actions can cuase the player to rubberband back and forth:
- Swiftness status effect.
- Most noticeable at higher swiftness levels.
- Jump boost status effect.
- Only at officially unsupported (>5) levels.
- Falling at terminal velocity.
- Flying with elytra.
- Flying in creative / spectator mode.
- Moving at full speed on a boat.
- Under a bad network connection the game has been known to completely prevent a player from moving or jumping.
- This might be due to Minecraft recieveing several ticks if movement data from the client at the same time, with the server thinking the client was trying to move that far in a single tick.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes these effects more reproducible.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the blocks are generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading.
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time.
- Easily survivable in survival if saturation is high - you only take 1 or 2 hearts' damage.
- The following actions can cuase the player to rubberband
back and forth:
- Swiftness status effect.
- Most noticeable at higher swiftness levels.
- Jump boost status effect.
- Only at officially unsupported (>5) levels.
- Falling at terminal velocity.
- Flying with elytra.
- Flying in creative / spectator mode.
- Moving at full speed on a boat.
- Under a bad network connection the game has been known to completely prevent a player from moving or jumping.
- This might be due to Minecraft recieveing several ticks if movement data from the client at the same time, with the server thinking the client was trying to move that far in a single tick.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes these effects more reproducible.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the blocks are generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading.
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time.
- Easily survivable in survival if saturation is high - you only take 1 or 2 hearts' damage.
- The following actions can cuase the player to rubberband or be teleported back:
- Swiftness status effect.
- Most noticeable at higher swiftness levels.
- Jump boost status effect.
- Only at officially unsupported (>5) levels.
- Falling at terminal velocity.
- Flying with elytra.
- Flying in creative / spectator mode.
- Being launched by a TNT cannon.
- Moving at full speed on a boat.
- Under a bad network connection the game has been known to completely prevent a player from moving or jumping.
- This might be due to Minecraft recieveing several ticks if movement data from the client at the same time, with the server thinking the client was trying to move that far in a single tick.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes these effects more reproducible.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the blocks are generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading.
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time.
- Easily survivable in survival if saturation is high - you only take 1 or 2 hearts' damage.
The following actions cancuase the player to rubberband or be teleported back:
- Swiftness status effect.
- Most noticeable at higher swiftness levels.
- Jump boost status effect.
- Only at officially unsupported (>5) levels.
- Falling at terminal velocity.
- Flying with elytra.
- Flying in creative / spectator mode.
- Being launched by a TNT cannon.
- Moving at full speed on a boat.
- Under a bad network connection the game has been known to completely prevent a player from moving or jumping.
- This might be due to Minecraft recieveing several ticks if movement data from the client at the same time, with the server thinking the client was trying to move that far in a single tick.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes these effects more reproducible.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the blocks are generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading.
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time.
- Easily survivable in survival if saturation is high - you only take 1 or 2 hearts' damage.
- The following actions can cuase the player to rubberband or be teleported back:
- Swiftness status effect.
- Most noticeable at higher swiftness levels.
- Jump boost status effect.
- Only at officially unsupported (>5) levels.
- Falling at terminal velocity.
- Flying with elytra.
- Flying in creative / spectator mode.
- Being launched by a TNT cannon.
- Moving at full speed on a boat.
- Under a bad network connection the game has been known to completely prevent a player from moving or jumping.
- This might be due to Minecraft recieveing several ticks if movement data from the client at the same time, with the server thinking the client was trying to move that far in a single tick.
These issues, especially the non-portal-related ones, are difficult to reporduce but have all been seen by me or reported with screenshots at some point.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes these effects more reproducible.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the blocks are generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
- Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading.
- Portals setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time.
- Easily survivable in survival if saturation is high - you only take 1 or 2 hearts' damage.
- The following actions can cuase the player to rubberband or be teleported back:
- Swiftness status effect.
- Most noticeable at higher swiftness levels.
- Jump boost status effect.
- Only at officially unsupported (>5) levels.
- Falling at terminal velocity.
- Flying with elytra.
- Flying in creative / spectator mode.
- Being launched by a TNT cannon.
- Moving at full speed on a boat.
- Under a bad network connection the game has been known to completely prevent a player from moving or jumping.
- This might be due to Minecraft recieveing several ticks if movement data from the client at the same time, with the server thinking the client was trying to move that far in a single tick.
These issues, especially the non-portal-related ones, are difficult to reporduce but have all been seen by me or reported with screenshots at some point.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes these effects more reproducible.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
- Add a gamerule such as check-player-velocity (default true) to allow servers to turn this "feature" off; Spigot already does this.
is duplicated by
The anti-cheat engine (or perhaps another change in 15w40/41) is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals loading chunks at the location of the portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the blocks are generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Over time this will cause server lag on large SMP servers as random chunks keep loading and unloading.- Portals
setting the player on fire if there is lava at said location.
MC-97523- Deals 11 damage over time.
Easily survivable in survival if saturation is high - you only take 1 or 2 hearts' damage.- The following actions can cuase the player to rubberband or be teleported back:
Swiftness status effect.
- Most noticeable at higher swiftness levels.
Jump boost status effect.
- Only at officially unsupported (>5) levels.
- Falling at terminal velocity.
- Flying with elytra.
- Flying in creative / spectator mode.
Being launched by a TNT cannon.- Moving at full speed on a boat.
Under a bad network connection the game has been known to completely prevent a player from moving or jumping.
- This might be due to Minecraft recieveing several ticks if movement data from the client at the same time, with the server thinking the client was trying to move that far in a single tick.
These issues, especially the non-portal-related ones, are difficult to reporduce but have all been seen by me or reported with screenshots at some point.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes these effects more reproducible.These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
- Add a gamerule such as check-player-velocity (default true) to allow servers to turn this "feature" off; Spigot already does this.
The anti-cheat engine is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
The following actions can cause the player to rubberband or be teleported back:
Swiftness status effect.
Most noticeable at higher swiftness levels.Jump boost status effect.
Only at officially unsupported (>5) levels.Falling at terminal velocity.Flying with elytra.Flying in creative / spectator mode.Being launched by a TNT cannon.Moving at full speed on a boat.Under a bad network connection the game has been known to completely prevent a player from moving or jumping.
This might be due to Minecraft receiving several ticks of movement data from the client at the same time, with the server thinking the client was trying to move that far in a single tick.Strikethrough issues not confirmed in 1.9.2 or later
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes the non-portal-related effects more reproducible.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
The portal issues began around week 40 or 41 (15w40x/15w41x).
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
- Add a gamerule such as check-player-velocity (default true) to allow servers to turn this "feature" off; Spigot already does this.
The anti-cheat engine is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
The following actions can cause the player to rubberband or be teleported back:
Swiftness status effect.
Most noticeable at higher swiftness levels.Jump boost status effect.
Only at officially unsupported (>5) levels.Falling at terminal velocity.Flying with elytra.Flying in creative / spectator mode.Being launched by a TNT cannon.Moving at full speed on a boat.Under a bad network connection the game has been known to completely prevent a player from moving or jumping.
This might be due to Minecraft receiving several ticks of movement data from the client at the same time, with the server thinking the client was trying to move that far in a single tick.Strikethrough issues not confirmed in 1.9.2 or later
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes the non-portal-related effects more reproducible.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
The portal issues began around week 40 or 41 (15w40x/15w41x).
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
- Add a gamerule such as check-player-velocity (default true) to allow servers to turn this "feature" off; Spigot already does this.
The anti-cheat engine is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes the non-portal-related effects more reproducible.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
The portal issues began around week 40 or 41 (15w40x/15w41x).
This issue is characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
- Add a gamerule such as check-player-velocity (default true) to allow servers to turn this "feature" off; Spigot already does this.
Minecraft teleporting players back if they move too quicklyPortals generate far-away chunks & set player on fire
The anti-cheat engine is being over-zealous and occasionally teleporting non-hacking players back for "moving too quickly". Known issues arising from this are:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Increasing server lag/load, for example having another player on the server or allocating little RAM to it, makes the non-portal-related effects more reproducible.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
The portal issues began around week 40 or 41 (15w40x/15w41x).Thi
sissueischaracterised by a debug message in the chat claiming that the player moved too quickly:[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Possible fixes:
- Check if player is using portal before teleporting them back.
- Factor gamemode into fastest possible velocity calculations.
- Factor swiftness effect into fastest possible velocity calculations.
- Add a gamerule such as check-player-velocity (default true) to allow servers to turn this "feature" off; Spigot already does this.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
The portal issues began around week 40 or 41 (15w40x/15w41x).
Thiese issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the chest engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
The portal issues began around week 40 or 41 (15w40x/15w41x).
Thiese issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the chest engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
The portal issues began around week 40 or 41 (15w40x/15w41x).
Thiese issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
is duplicated by
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
These issues can arise in both single- and multiplayer but are often more obvious in multiplayer.
The portal issues began around week 40 or 41 (15w40x/15w41x).
Th
iese issues are characterised by a debug message in the chat claiming that the player moved too quickly:[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
To fix this issue, remove all fire/lava at the exact location of the entry portal _in the other dimension.
e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) (not the location of the exit portal) and remove fire and lava around that location.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
To fix this issue, remove all fire/lava at the exact location of the entry portal
_in the other dimension.e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) (not the location of the exit portal) and remove fire and lava around that location.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
To fix this issue, remove all fire/lava at the exact location of the entry portal in the other dimension.
e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) (not the location of the exit portal) and remove fire and lava around that location.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
To fix this issue, remove all fire/lava at the exact location of the entry portal in the other dimension.
e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100)
(not the location of the exit portal) and remove fire and lava around that location.These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
To fix this issue, remove all fire/lava at the exact location of the entry portal in the other dimension.
e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
To fix this issue,remove all fire/lava at the exact location of the entry portal in the other dimension.e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
workaround: remove all fire/lava at the exact location of the entry portal in the other dimension.
e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
workaround: remove all fire/lava at the exact location of the entry portal in the other dimension.
e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.Th
ese issues are characterised by a debug message in the chat claiming thatthe playermoved too quickly:[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine.A possible fix is to check if player is using portal before teleporting them back.
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.This seems to occur more regularly when the server is under more load e.g. other players online.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine changes.
is duplicated by
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.This seems to occur more regularly when the server is under more load e.g. other players online.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine changes.IF you are using Spigot, you may instead be teleported to X, 0, Z per
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.This seems to occur more regularly when the server is under more load e.g. other players online.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine changes.IF you are using Spigot, you may instead be teleported to X, 0, Z per
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.This seems to occur more regularly when the server is under more load e.g. other players online.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine changes.If you are using Spigot, you may instead be teleported to X, 0, Z per
MC-103905. This is a Spigot issue; please report it there.
is duplicated by
is duplicated by
I am playing on 1.10.2 and I currently have 5 nether portals set up, 2 of which set me on fire every time I go through. I have been to the cords which match with the overworld and have found lava. I have put gravel there as others suggested but I am still being set on fire. Is there any way to stop this happening?
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.This seems to occur more regularly when the server is under more load e.g. other players online.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine changes.If you are using Spigot, you may instead be teleported to X, 0, Z per
MC-103905. This is a Spigot issue; please report it there.The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.This seems to occur more regularly when the server is under more load e.g. other players online.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine changes
Related toMC-86850, which covers how taking certain actions may cause you to remain at the erroneous location.If you are using Spigot, you may instead be teleported to X, 0, Z per
MC-103905. This is a Spigot issue; please report it there.
relates to
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.This seems to occur more regularly when the server is under more load e.g. other players online.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine changes
Related toMC-86850, which covers how taking certain actions may cause you to remain at the erroneous location.If you are using Spigot, you may instead be teleported to X, 0, Z per
MC-103905. This is a Spigot issue; please report it there.The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.This seems to occur more regularly when the server is under more load e.g. other players online.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062, which covers the other effects of the cheat engine changes
Related toMC-86850, which covers how taking certain actions may cause you to remain at the erroneous location.If you are using Spigot, you may instead be teleported to (X, 0, Z) per
MC-103905. This is a Spigot issue; please report it to them.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
is duplicated by
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
is duplicated by
is duplicated by
relates to
relates to
relates to
is duplicated by
relates to
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
relates to
MC-120460
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. e.g. If you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that location.This seems to occur more regularly when the server is under more load e.g. other players online.
These issues are characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Related to
MC-90062,which covers the other effects of the cheat engine changes
Related toMC-86850,which covers how taking certain actions may cause you to remain at the erroneous location.
If you are using Spigot, you may instead be teleported to (X, 0, Z) perMC-103905. This is a Spigot issue; please report it to them.The bug
The anti-cheat engine is being over-zealous causing the following issues with nether portals, caused by the game teleporting a player back:
- Portals setting the player on fire if there is lava at the exact location of the entry portal in the other dimension.
MC-97523- Can kill player if they are low on food or health - very serious.
- Deals 11 damage (5 1/2 hearts) over time.
- Usually survivable in survival mode, especially if you are full on food or have good armour - you will only take 1 or 2 hearts' damage.
- Portals loading chunks at the exact location of the entry portal, but in the other dimension.
MC-97523- Only the chunk at the exact location of the other dimension's portal loads.
- Only the terrain is generated: entities do not spawn.
- InhabitedTime of that chunk is 0.
These issues are usually characterised by a debug message in the chat claiming that the player moved too quickly:
[11:07:36] [Server thread/WARN]: FM22 moved too quickly! 8740.213380243677,-16.0,8751.561382695907
(this was going through a nether portal in the overworld at 10 000, 10 000).
Workaround
Remove all fire/lava at the exact location of the entry portal in the other dimension. E.g., if you have a portal at (100, 64, 100) in the overworld and you are set on fire when going to the nether, go to (100, 64, 100) in the nether (not to the location of the exit portal) and remove fire and lava around that exact location.
Related issues
MC-90062- which covers the other effects of the cheat engine changes
MC-86850- which covers how taking certain actions may cause you to remain at the erroneous location.The fix
A suggested fix by Xcom6000, Timothy Miller, and [Mod] Pokechu22 can be found in this comment.
relates to
relates to
relates to
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mod] GoldenHelmet](../../../data/avatars/users/18951.svg){kind=small}
relates to
relates to
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Although it might make sense to keep this issue open because you can still take damage, the issue has changed a lot and we now have a much better understanding of it. Grouping issues by cause rather than effect may make the bugs be fixed more quickly.
Edit: See MC-98153
The "other" coordinates in the Nether could potentially be very far from the actual exit portal - if you went from an Overworld portal at 800,y,800, it would briefly put you at 800,y,800 in the Nether (which could contain fire or lava) before teleporting you to the portal closest to 100,y,100.
well, this is not really MC-98153 to be honest
I haven't had this in any of the 1.9.3 pres; I have only seen MC-98153 so far. Is this now fixed with the removal of a lot of lag sources?
I thinks it's a direct result of MC-98153. Should be "blocked by", as I learned recently. 
Oh I was testing MC-89928 which involved teleporting to specific coords and kept ending up 5 or so blocks below my target. I was teleporting to underground locations while in creative but I would type, say, "/tp 6400 35 64" but fall to (6400, 31, 64) before or as the chunks loaded. To reproduce, perhaps try teleporting to a target location which is already underground, or being in creative? I'm guessing that, similarly to MC-89928 and MC-98153, server load increases the chance of this issue occuring as well as its severity as the chunks take longer to load.
Extremely similar to MC-98153. However in my instance when taking a portal from the overworld at coords -5/120/34 I end up in the Nether at or near -3/-3/-2 (The coordinates I'm sent to are just about directly below our actual portal in the Nether which is at -2/52/-2. I easily could have moved a tiny bit from X=-2 and I know I start falling immediately so I expect I'm actually arriving at -2/0/-2.). Upon arriving there's a sky of solid Bedrock above that the player begins falling away from at once, suffocating soon after. If the gamemode is set to Creative the player can punch through the Bedrock and if they fly directly upwards they are in the normal Nether chunk they expected to be at in the first place. In the server console I see the text "<player name> moved too quickly!" and right after the death message for that player is "<player name> fell out of the world."
Seed is -2466281547766755436. This world was created at version 1.9. This problem seems to have started somewhere around 1.9.4, potentially earlier. The only plugin in use on this server is PermissionsEx although the server itself is Spigot.
I checked per notes in MC-98153 and if I go in the Nether to the coordinates precisely corresponding to the Overworld coordinates of the starting nether portal there's nothing there but solid netherrack. However I do think it's significant that the player arrives at the same X and Z coordinates as their Nether Portal in the Nether but the Y value is far enough down that the player is basically outside of the game world.
This problem is rather severe as it basically renders all our existing Nether portals unusable.
Do you have a way to reproduce this without modifying the client to send a custom packet? I know it's possible for collision to behave poorly, I'm just not aware of a concrete way to reproduce this as-is (I'd like to try to reproduce on the snapshot, where sending other packets is rather difficult)
The portals/dimension change logic is definitely broken, though (see MC-98153). Were that less broken, would this still be an issue? I'm pretty sure it would still be, as the blocks would be triggered when they shouldn't be.
I am running a local Minecraft server for my roommate and myself, and as it usually happens, we both created Overworld portals to get to the Nether.
Since my roommate was first to the Nether, my Overworld portal (see 2018-02-05_19.32.12.png; all of these sides were lit right after each other) "linked" (yes, I know, thus the quotes) to my roommate's, and then I had to do some difficult math to create my own Nether portal (see 2018-02-05_18.56.17.png; the portal to the left is the one created, and is what I call the "first" of the pending quad-sided Nether portal) so that it "linked" my Overworld portal.
Everything was good; both my roommate and I were satisfied with our Overworld and Nether portal "linkage" – that is, when we used them, we traveled to our expected corresponding portals.
Tonight, I started working on the "second" Nether portal (see 2018-02-05_18.56.17.png; the right-side is the newly-created "second" Nether portal). Upon completion, I began testing by traveling through this second side of the Nether portals – this led to a spawned Overworld (see 2018-02-05_18.50.02.png), which is unexpected behavior, since there is a portal already available in the desert temple for that side. A couple of travels through this and the Nether portal confirmed that the good "linkage" was now lost; if I traveled through either of the Nether portals, I would arrive at this spawned desert Overworld portal. I destroyed this portal by removing an obsidian block (see 2018-02-05_19.31.20.png). In doing so, I was able to reuse the quad sided Overworld portal to go to the Nether and back, as long as I only used the "first" side of the Nether portals.
Attempting to use the "second" side of the Nether portals resulted in a new Overworld portal getting spawned, this time underground (see 2018-02-05_18.56.50.png). This portal is not yet destroyed, so the current "linkage" is to this undergournd Overworld portal from the Nether, even if I use one of the sides in the desert temple Overworld portals.
When I look at the server log, I see these "<entity> moving too quickly" and notice that it seems the previous entry's coordinates are virtually negated for the next log entry.
I got annoyed, and started searching online for reports, but most seem to be from earlier versions, and comments on those results seemed to indicate the bug(s) were fixed. Yet here I am, latest version of the Java Edition, and am having portal issues. So I came here, and heeded the search first request, and most of the cases I have seen seem to be "resolved" as duplicates of to MC-1403 (which I am referencing here), and there was also MC-98153, which I am including for the "moving too quickly" portion.
From searches in the bug tracker:
- https://bugs.mojang.com/browse/MC-1403 – However, according to Anon Ymus, the reported bug is not "seen" as a bug. I would disagree, as my Overworld portals (in the Desert temple I have repurposed) have never been destroyed since being created – only the newly spawned Overworld portals from the second side of the Nether portal.
- https://bugs.mojang.com/browse/MC-98153 – However, neither I or my roommate are on fire when traveling through our portals. I am seeing a lot of the "moving too quickly" debug warnings though (see attachment 2018-02-05 19-59-34.png), which are coinciding with mostly the portal traveling – not sure if this file contains personal information, since there are UUID's included in the server log, so I marked this as private just in case.
Screenshot Attachments:
- 2018-02-05_18.50.02.png (spawned desert Overworld portal)
- 2018-02-05_18.56.17.png (under construction Nether portal)
- 2018-02-05_18.56.33.png ("first" Nether portal + coordinates)
- 2018-02-05_18.56.37.png ("second" Nether portal + coordinates)
- 2018-02-05_18.56.50.png (spawned underground Overworld portal + coordinates)
- 2018-02-05_19.30.27.png (desert temple Overworld portal A + coordinates)
- 2018-02-05_19.30.42.png (desert temple Overworld portal B + coordinates)
- 2018-02-05_19.30.52.png (desert temple Overworld portal C + coordinates)
- 2018-02-05_19.31.04.png (desert temple Overworld portal D + coordinates)
- 2018-02-05_19.31.20.png (broken desert Overworld portal + coordinates)
- 2018-02-05_19.32.12.png (above desert temple quad Overworl portals + coordinates)
- 2018-02-05 19-59-34.png (* moving too quickly calls)
MC-98153 was already fixed in 13 though. The bug where entity's would pingpong using portals.
I noticed I had lost a villager in a village I haven't even been to since 1.17.1. Playing on a 1.18.2 vanilla server currently.
The region of the village was briefly loaded due to MC-98153 when going to or returning from the nether. The server created an entities file for this region and updated the poi and region files. This has happened with other regions as well, but this is the first time a villager vanished (replacing the affected files from the backup brought him back). There was nothing in the server or client logs.
Whether or not MC-98153 is the root cause is unclear, but it was at least the trigger in this case. Commented on there as well.
Please contact me if you need the world downloads (before and after it happened) - they're big, so I might have to strip them down first. Not sure if it would help, though, as I have done the same as today for quite some time and only today the issue happened, so it seems pretty sporadic.
I had the same issue as described before again and there seems to be a pattern. It might not be related to MC-98153. This time a whole village has been wiped out.
I have been working in the Nether and some nearby chunks with portals were loaded. I assume a piglin or it's zombified variant spawned close by and walked into the portal. The portals are in enclosed rooms with doors, but piglins can open doors and zombified ones can spawn in portals.
When (if that is what happened) they entered the portal, they caused the counterpart in the overworld to be loaded, but then probably instantly despawned because no player was around there. These regions were in villages and last loaded in 1.17.1 - the issue happened in 1.18.2. So upon loading this overworld region, the game attempts to convert the affected chunks, which you can see that the new caves are generated below zero (but only in a few chunks, not as much as you'd expect), and sometimes also a file in the entities/ folder if it didn't exist yet, otherwise it shows as changed.
My guess is that the chunks weren't loaded long enough for the conversion to be successfully completed (because the mob despawned), thus letting villagers (and potentially other mobs) disappear.
Not sure if this is a separate issue - if necessary, I can create an own bug report for this. I can also provide the world with and without the issue (I restored the affected entities/poi/region files from a backup), but the worlds are big and in principle this should happen to any 1.17.1 world with a portal in a village where a (hostile?) mob enters the portal in the nether in 1.18.2 without a player being in the overworld - probably not every time, though.
Could anyone link to the video proofs of those confirmed issues?
I will make a video showing all the issues soon but
MC-97523has a couple videos showing portal behaviour (although you now take less fire damage in pre-4). I tested all these issues which were claimed by other people on a fresh world on a 1.9 pre-4 server, if you would like to reproduce them.I think the mention of swiftness should be removed because of
MC-10755MC-10755is a totally different case, where sound game logic just results in some non-intuitive behaviours. This is an anti-cheat feature accidentally breaking the game logic.@Fang Zhang
https://youtu.be/w0sv2ZvQJ_k
This was actually created in relation to
MC-89928, but relates to the anti-cheat kicking in and then teleporting the player. The teleport action is clearly visible.Also, if I'm correct, this was the cause of
MC-89928and all bugs related to the Nether Portal since 15w40a, all of which effects have been patched, including, but not limited to:Finally, a current effect of this bug,is that you load & generate chunks far out in the nether that would otherwise never be visited. For example:
If you are at 800 70 800 in the overworld, and make a nether portal, the game will teleport you to a portal near 100 70 100. However, anticheat moves you to 800 70 800 (the location of the portal block you came through in the other dimension). If lava happens to be in that location, you will catch fire before your finally teleported back into the proper nether portal frame at ~ 100 70 100. I had also observed in gamemode 3 that if a ghast was spawned, it would attempt to lock onto the teleporting player at the 800 70 800 range.
Not only does this increase server load, it also unnecessarily increases the size of the server save file.
Please ask if you have any additional questions about these points.
Yes. Mojang have been patching effects not causes which I cannot imagine is good for either the code quality/changeablilty or stability in future versions.
I will admit, certain patches such as the cooldown on dimension shifts and invulnerability while shifting dimensions are good safeguards, especially if there is server lag involved. But you are correct, future versions can really get screwed if they make one minor change and then suddenly all of the patches unravel. At this point, if this specific bug is fixed, there's a bunch of technically unneeded code in the game as well. :/
@James Koon Do you know any other issues that are caused by this?
@bob
I believe you've outlined quite well in the description everything else that I've noticed except for one thing I noticed: If using a Speed 2 Beacon + a Haste 2 beacon, there is a vast increase in ghost blocks due to corrections to coordinates while breaking blocks. I was clearing out a 10 x 7 x 100 long tunnel around a beacon and was constantly getting ghost blocks.
The main reason I know so much about the nether is I have been building the nether hub on my server, and have been having to poke around to fix all the issues in regards to portal issues.
That last issue is
MC-94438Yes, however, I was able to correlate the amount of "moving too fast" errors to the amount of ghost blocks. I'll have to record with a console open to show this. I'm about to head to work, but the ghost block issue seems to happen everytime the server corrects the coordinates of the player while using instant mine.
Oh; in that case it is this bug, sorry
st*s*tus
@James Koon
Just tried a load of tests using speed 2 in survival; could not reporoduce either rubberbanding or log messgages.
Also, can anyone reproduce
MC-98209? I flew around for a while but nothing happened.Edit: Does it have to be on a server?
https://youtu.be/UyrrEdEbkHo
The portal issue is the only one I've had time to test. I have yet to see a "Player Moved Too Fast" while testing however, and since it's still happening, and we don't know what's going on behind the scenes (as far as if they changed how it's reported), and since the same things are happening without the error, I'm skeptical as to the bug itself being fixed.
I'll be checking the other items as well. I'll add a new comment if I find anything (such as the ghost blocks with beacons).
OK thank you! I can confirm portals also.
I'm on the 1.9 release and went through a portal to the nether then went back to the overworld, the console displayed the Player moved too quickly message.
23:41:01 [Warn] DecrepitDoors moved too quickly! -233.2804134719363,24.0,-201.96840655578762
23:43:43 [Warn] DecrepitDoors moved too quickly! 233.5886696276972,-24.0,202.1310059257861
Broken anti-cheat code is far, far worse than cheaters. This should never have been present in RC-level releases.
@Kai I strongly agree. Cheaters are not that common, and if they DO get seen, an OP can just ban them. But this broken code stretches into territory that we as players use too often to be interfered with.
I catch fire every time I go through my portal to the nether, but there is no fire at the portal there. Overworld portal at y=22 might correspond to lava suspected by other commenters. What patch do I need to download to fix this?
@Jeffry R. Fisher
There is no patch for this. The best you can do is go to the exact coordinates in the nether that the overworld portal is in (so if the portal is at 300 22 300 in the overworld, go to 300 22 300 in the nether), and remove all lava blocks from that location. Hopefully this will be fixed in a later version.
This bug is much more serious than I thought!
bob it's "little" not "lettle", lettle isn't a word
Sorry: typo
I fixed it before as well, and you changed it back XD
Wow I'm bad.
One other thing I noticed one day when my internet was acting up a little was that moving at all causes "Moved too Fast" errors, creating bad bad bad rubber banding, and simply jumping would kick you using the No Flying kick.
I'm guessing it is because the client sends several ticks' worth of movement packets in one go so the game thinks you moved that far in a single tick.
I'm not sure if this counts as a suggestion (and as such would be considered off topic), but could an additional solution for the possible fixes, however temporary, be to add a game rule or server.properties option to disable this anti-cheat, in the same vein as the allow-flight option? Say, allow-speed. It'd fix half the problem if you were playing on a server with people you trust not to cheat/hack.
Off topic: I was actually initially under the impression that allow-flight was what disabled the subject of this bug report.
Edit: Apparently /gamerule disableElytraMovementCheck was already a thing when I posted this, lol. I do wish this would apply to all movement and not just elytra movement.
Megabobster ^This. It should be a gamerule though, so that you can toggle it in singleplayer.
I'm actually coming to think that the real fix lies in calculating how many ticks of movement data came from the client. So if the speed limit is 10 m/tick (I think it is this) and the client sends a move packet of 20m after 3 ticks, the game would currently TP the player back as they "moved too quickly" but should not actually as the player only moved 6.67 m/tick
Just an additional note, under "The following actions can cause the player to rubberband back and forth", I have found that my TNT cannons no longer launch me in the air... they now launch me one block up and the server says I moved too quickly. I have also been seeing this when I fly in creative or with Elytra, even though I have set
and have added the gamerule
I cannot confirm the portal issues that others have been discussing, but I can confirm this is still an issue.
Thank you for the information. Is this confirmed for 16w15a then?
Bob camino Honestly I don't know. I am new to bug-reporting... I made an account to follow this bug. I'm playing on 1.9.2 currently and am not downloading pre-releases, if that helps.
Where do I find my specific snapshot code, for future reference?
Well it says what snapshot you are on in the top left corner if you press F3, but I really meant "version" not "snapshot", sorry. Confirmed for 1.9.2 then.
I've heard disableElytraMovementCheck doesn't work properly.
Which of the non-portal (strikethrough) issues are others getting in 1.9.3?
Just created a new world, teleported to 10.000 10.000, built a portal, opened world in Minutor. There were the usual chunks loaded in the nether around 1.250 1.250, but also 2x2 chunks around 10.000 10.000 in the nether. So I still got teleported back (bug confirmed), but only generated a few chunks, because I'm playing on a laptop with multiple programs open.
tldr: "Portals loading chunks at the exact location of the entry portal, but in the other dimension" <-confirmed for 1.9.3-pre2.
Thank you. But have you seen any issues with bring teleported back ("rubberbanding") while riding a horse, sprinting with speed effects, rowing a boat at max speed, flying with elytra, flying in creative or spectator etc.?
Nope. Just flew with maximum speed in gamemode 3 and even had a repeating command block with
tp @p 0 ~ ~
This was a command where I first encountered rubberbanding, but it worked good this time.
I also haven't been able to reproduce over the past few days of playing so I'll remove that bit.
Edit: Log now says stuff like "<Player> moved wrongly". I think this implies that no attempted reverse teleportation is occuring.
bob that message means that theplayer attampted to move via a invalid path, for example through blocks in creative.
Why am I getting it in a boat on an ice path? Has this been reported?
Edit:
MC-90062, a related issue.Because the ice boat speed is not a feature, as known so far, no mojangster said it's intended.
I changed this bug to focus in the portal issues in light of
MC-90062.Well, then this has become a duplicate of
MC-89928.No it hasn't.
MC-89928is about end portals teleporting you into the void. This bug is about nether portals setting you on fire. They were going to be merged but some Mojangsta intervened AFAIK so they are separate bugs.It mentions nether as well, setting on fire = spawning inside blocks with said blocks being fire or lava.
You don't spawn inside that block though. You are instantly teleported to the correct location. With
MC-89928you remain at the wrong location until you fall in the void, burn or suffocate, and the nether part has been fixed--the description is outdated. The end part was thought fixed, but it was reproduced in 1.9.0. Also:bob added a comment - 27/Feb/16 10:49 AM - edited
If the invulnerablility has been added, this bug should be marked as resolved. Instead, a new bug should be opened detailing the various effects of the broken anti-cheat system (rubberbanding with speed, portals briefly loading wrong chunks, portals setting you on fire and so forth).
[Mod] Kumasasa added a comment - 27/Feb/16 10:55 AM
bob: Go ahead.
Well, to me this still seems like a duplicate now, but we'll see what other mods have to say about this.
If you resolve as dupe please update the description of the other bug at least; it is very outdated.
As far as I know, there is currently no other unresolved bug to track 'nether portal sets you on fire' due to the bad coords. The comment section of
MC-89928is kind of a disaster to understand 'what effects' any of the bugs actually tracks.MC-89928is tracking the (fixed AFAIK) bug that portals actually TP you to the wrong coords.I cannot attach the video I've recorded as the file is too large, but I've dug around the portal and cannot find any lava that would represent a threat, yet the burning issue is persistent as of May 4, 2016.
Not around the portal; around the portal's exact location (xyz) in the other dimension. So if you had an overworld portal at (100, 64, 100) you would dig at that spot in the nether, not around the exit portal at (12,64,12) or so.
I've managed to dig around both portals now, yet am still set on fire. Note that the first portal I created was in the overworld, and the second one of the pair within the Nether.
I apologize for misinterpreting your previous comment, what you've said makes sense now that I've reread it.
It's fine; this issue is really confusing!
Edit: added fix instructions; are they clear enough?
Also @mathew what version are you running?
The "fix" instructions sound like Mojang could fix it this way (for me at least).
I'm currently running the latest version of Minecraft, which should be 1.9.2 (the debug says 1.9.2/vanilla)
OK; thank you
I can confirm "burning coming out in nether" beginning with 1.9.0 and still with 1.9.4. (pure vanilla server).
It does not happen all the time, but most of it.
I will check out the workaround/fix, sometime soon.
I TPed to coordinates in nether, where portals coordinate are in overworld and removed lava there, seems working, no burning yet.
Edit: I must relativise my prior statement. It still happens that i'm burning when coming out of the portal in nether, though not happening as often.
This video was originally made for
MC-89928for Pre-2, but it offers a side by side shot of what's happening.https://youtu.be/n9hZgJDO9TA
I can make an updated version with 1.9.4 but I've been able to repeat this in current versions.
Also, if you, due to latency, disconnect from the server during dimension shift, you are likely to find yourself in the opposite dimensions coordinates when you log back on.
EG: You enter a portal in overworld at 1000, 70, 1000 in the overworld. You DC. You log in. Instead of being at 125, 70, 125, you find you're at 1000, 70, 1000 in the nether. And it's in a wall. And you suffocate to death. GG.
How do you disconnect whilst going through a portal?
Due to latency? Had one of the people on my server disconnect during dimension shift numerous times because he was playing at 2-3 bars. He was disconnected from the server, he didn't disconnect himself. Don't know if it'd work if you alt-F4'd during dimension shift or not to recreate or force-crashed your client?
This bug is still very lag-based but also reproducible. I think it's because of the quick-and-dirty way in which they patched
MC-89928.Myself and my sever's players just noticed this problem. We're running 1.10. It seems to either have been introduced with 1.9.x or 1.10. I've tried replacing World files in the Nether but that doesn't help at all. When using a Nether Portal my start coordinates are -5/120/34 and upon going through to the Nether I arrive at -3/-3/-2 (Y value may actually be zero). I appear to be in "The Void" and immediately begin falling from some solid surface, take suffocation damage and die shortly thereafter. Server logs do indeed show "<player name> moved too quickly!" and right after the death message for that player is "<player name> fell out of the world."
I would be happy to provide any files or other data that would help resolve this problem. Right now our Nether Portals are effectively broken in our game.
Two questions: First, is there a workaround for this problem as I've described it? Second, does this affect any new Nether Portals outside the portal-linkage radius (1024 blocks, I think) of the original portals or does this only affect already-existing portals?
James Fischl What is the Seed of the world? In which version did you generate the world?
I just created a regular world and went into a portal at -5/120/34, but I landed safe in the Nether at around Y-level 109.
There are generating differences even when one uses the very same seed, and maybe the issue isn't the seed after all, but I'd like to make sure.
Also, do you run any plugins on the server, or is it 100% Vanilla?
Edit: Check in the NETHER at around the same coordinates, so, around -5/120/34, if there is any lava, fire or something that sort of obstructs the exit there.
If so, remove all the Lava and Fire closeby and try again (go into creativemode to be sure).
If they are falling out of the world, I guess the chunk is not loading.
If you get teleported to y=-3 instead of your overworld coordinates, it's not this bug.
Thanks Meri Diana for writing. My world's seed is -2466281547766755436. The Create date on the \World\level.dat file is Feb 28, 2016 so I'm pretty sure we started with 1.9. I run a Spigot server and the only plugin I use is PermissionsEx. If you think it's helpful I can try and load the world using a vanilla server build instead of Spigot.
I went into the Nether in creative mode and had to bust upwards through a wall in the sky of bedrock to get to the nether proper. Once I did I was in the normal Nether area that we're used to seeing. I flew to -5/120/34 (not at all where the Nether portal is) and it's within solid Netherrack for quite a distance in any direction. For reference the actual location of our portal within the Nether is -2/52/-2. There's a structure around it so no fire but one side of the portal is covered by cobblestone.I removed that cobblestone but the problem still persists. I did note too that when I took the portal in the Nether to get back to the normal overworld it sent me roughly (I moved slightly before recording the coords) to -51/38/-49. It put me within solid rock and if I weren't in Creative mode I would have died.
Thanks Fabian, I actually came to this bug by way of
MC-89928which references this one. If you're saying that what I'm describing is a different bug (albeit one with strikingly similar symptoms) should I start a brand new bug report?I can confirm this bug, it just happened on my multiplayer server. Travelling through a portal in the nether at 5, 8, -127 set me on fire when I arrived in the overworld at 40, 64, -1000. The was no lava near the overworld portal, but going to the nether coordinates of the portal in the overworld (5, 8, -127) and removing the lava there stopped me from being set on fire when using the portal.
[~James Fischl]
MC-89928was kind of the old version of this bug. Then a short invulnerability after going through portals was introduced that hid some of the symptoms. Because parts of it technically got fixed, this bug report was created. It's still the same cause, just some effects are not there anymore.If you can't find a bug report that says that you get teleported below y=0, you should create one, yes.
[~Fabian Röling] Sounds good, I've created
MC-103905for what I'm seeing. It sounds extremely similar and I do know that others have reported the same symptoms of "falling out of the world."MC-90062also describes some other effects of this bug. Does it cover your effectMC-103905?Bob that's a good question. I do see that message in the server console while falling out of the world but I don't get TP'd upwards to my starting point. I would have to say that it covers part of what I'm seeing as described in
MC-103905. However any of that is a consequence of my chief issue that our Nether Portals are now depositing players under the Nether at the incorrect Y coordinates instead of to the proper destination. That's the primary issue at hand for myself.Confirmed in 16w35a & 16w36a
Confirmed in 16w38a
Confirmed in 16w39a
Confirmed in 16w39b
Confirmed in 16w39c
Have come to this bug via
MC-98209which has been marked as a duplicate of this one.I'm running a 1.10.2 vanilla server on Windows 7 x64 JRE1.8.0_102-b14 (also 64-bit) and getting the "<player> moved too quickly!" message in the server console whenever I sprint and far worse if I have my Speed 2 beacon on - I can barely walk. Doesn't happen if the same world is loaded as SP. This is on a quad core i7 with 32GB RAM (8 allocated to server) across a 1Gb LAN
Just saying, as the focus of the discussion here seems to be on Nether Portals, should the other bug be reopened?
Either way, please please give us the ability to just disable the broken anti-cheat in server.properties!
Richard you are looking for
MC-90062Confirmed in 16w40a
Confirmed in 16w41a
Confirmed in 16w42a
The issue is that due to the new teleport acknowledgement system, after moving through the portal, the server sets the player back to the last position acknowledged until the client acknowledges the new position later causing a rubber band / teleport.
When was the teleport acknowledgement system added?
1.9
Oh right. Is this the same thing as the anti-chest thing around 15w4xx?
Confirmed in 16w43a
Confirmed in 16w44a
Confirmed in 1.11-pre1
Confirmed in 1.11
Confirmed in 16w50a
Confirmed in 1.11.2
Isn't it related to
MC-114022?Also confirmed in 1.11.2. I have confirmed with spectator mode that there are no lava blocks in the vacinity of either portal.
UPDATE (solution confirmation for an unmodded multiplayer server)
My example:
I was catching fire only when returning to the Nether from the Overwold. My Overworld portal (5x5 sized portal) bottom center block is at [710, 25, 431]. I went to [710, 25, 431] in the Nether (not the Nether equivalent coordinates). This was in the middle of a lava lake. I filled a portal sized area at those coordinates, plus some surrounding area with a solid block (approx. a 7x7x9 area filled).
This HAS solved the problem for this portal. After doing this, I did not have to move EITHER portal, and the portal behavior is now normal in both directions.
In my case I am not sure which part fixed the portal:
A) Because the chunks at that location [710, 25, 431] had not been generated in my world in the Nether?
B) Because I removed the lava from that location and the surrounding area?
Please edit your message as few times as possible, with this comment you sent 195 mails. There is a blue icon on the bottom right of the text box, that's a preview.
Also this is not a solution, the bug is still in the game and has to be fixed. It's a workaround to encounter the bug more rarely. And it's already known, it says in the description here: "Workaround: Remove all fire/lava at the exact location of the entry portal in the other dimension"
We just encountered this bug on our 1.12 world. The world was created during recent snapshot phase, not sure during which snapshot exactly. The portal was created during one of the late 1.12 pre-releases. We had no problems at first. When we returned after full release we started burning when going through it. I followed the advice from here, which fixed the problem.
Confirmed 1.12.2
Me, Tim Miller, and Pokechu22 found the fix!
add ((EntityPlayerMP)entityIn).connection.captureCurrentPosition(); to Teleporter.java to line 186.
What is happening is that the player is being moved to the new portal location but as there is a speculated redundant code in the NetHandlerPlayServer.java function update().
captureCurrentPosition saves the location of the player. Then onUpdateEntity updates the players positions to teleport to the other dimensions portal location. Then the position of the player is set in setPositionAndRotation back to the older saved position in captureCurrentPosition creating a pink pong effect. Later the position is updated by the teleport confirmation making the player end up in the correct destination eventually. But this ping pong effect causes massive issues with players being placed in the wrong location in the correct dimension, both fire and chunk loading happens due to this and causes extra strain on the server when travelling through a portal as unneeded chunks are loaded. The simplest fix is to update the position via captureCurrentPosition in the place where the player is being teleported to i.e. the part of the Teleport.java code that updates the players position to the new portal exit position.
Just for clarity:
We couldn't figure out why it calls captureCurrentPosition, then onUpdateEntity (which through a long chain of calls to e.g. onUpdate, gets to Entity.onEntityUpdate which changes the entity's dimension+teleports them to the portal) but then reverts it, but didn't feel comfortable removing the reversion since we couldn't determine that removing it would be safe. All of the stuff in EntityPlayerMP.onUpdateEntity is network-related, but onUpdate and such isn't. It's kind of weird.
This bug originated sometime during 1.9's snapshot phase (might have been 15w30-42 if memory serves). I'm not sure if any devs can look into changes back to that time, but whatever caused the initial bug has never been fixed, only the effects have been patched. I noted all of the ways this bug was 'patched' in a previous comment, but am going to repost/update it here to help hopefully clarify the logic behind some of the code, that way if someone reads through this trying to figure out what's causing the problem, it may help in peeling back all of the patching involved so they can make sense of it.
Portal Looping - Since you were moved out of the portal, and then the previous patch moved you back in, you effectively broke the game logic that you couldn't teleport immediately after spawning in a portal block. Due to the client attempting to load three locations (proper location, overworld equivalent coordinates, then back to the proper location), this often caused client side lag, as well as server lag, which would often not let the player move from the portal before they teleported again. The only way to break this looping was to kill the game. This was later patched with what I believe was a dimension shift cooldown.
Ultimately, I've been watching this bug for a couple years now, as I admin a server and am often having to go remove lava blocks from server members portals. If there are any questions about this please feel free to contact me, but as I said, it originated in the 1.9 Snapshots, the effects of the bug have been patched instead of the bug itself, which in all honesty has probably made it more difficult to fix, especially as time goes on.
Can confirm that the code in question was introduced during the 1.9 snapshots - it's not present in 1.8.9 MCP and is present in 1.9 MCP (that's the simplest test).
MC-89928is pretty important to note (already linked as related).Doing a binary search on the (obfuscated!) versions, using the string " moved wrongly" to find the right class, I can confirm that code to this effect was introduced in 15w41a (a bunch of new fields were added that are updated in c() based off of b's position - that matches this description, although c() is a general tick thing. Another search shows that this was moved into its own method in 15w43c (I can't say whether there were any other logic changes or if this was just general cleanup, as it's hard to read without any naming).
From NetHandlerPlayServer:
The position seems to get reverted right after the teleport: this.player.setPositionAndRotation(d4, d5, d6, f, f1); Removing that line fixes the problem. Disconnecting right after changeDimension (by setting a breakpoint) causes the player to have the dimension changed but not the position, which could even be abused intentionally by some players.
I thought Grum confirmed fixing this bug as per the suggestion above. Can this be tested with a snapshot to see if its fixed. It's already fixed as far as I remember and if not the suggested fix is the least invasive until a complete rewrite of the netcode is needed.
this still doesn't seem fixed for the 1.13 release mainly the
MC-98209part,It happens in both teleport directions - you end up in the destination dimension, but at the source dimension's coordinates.
In my world, I always get my home base's beacon effects when entering a portal in the overworld (far from my base) and entering the nether, assuming I was at the nether coordinates, but in the overworld for a brief moment.
Same issue happens with parrots when walking into a portal, keeping the overworld chunk loaded by a 2nd player to enable the parrot teleporting to the player when exiting the nether. Parrot should stay there when player enters the nether, but often vanishes and can be found again in the overworld at the nether coordinates of the portal. I assume it tries to teleport to the player in between changing dimension and coordinates. Could be related to
MC-123147.Fixing this bug should be high priority. It has nasty interactions with
MC-138550(High ms ticks in 1.14+, player cannot interact with world normally) andMC-151082(Loading chunks creates irrecoverable lag). Those bugs are issues with chunk loading and/or chunk caching. This bug causes chunks to be loaded unnecessarily. Combine the two, and this is probably why players can take several minutes to forever to teleport through a Nether portal in 1.14+.Fixing this bug should not be difficult as a suggested fix has already been provided.
Is this still happening in 19w45b or later?
Test: New world, teleported to 3M 100 0, went through a portal. Waited a few minutes, went back. Then the same process again in Survival. Resulting region files:
So yes, this is indeed fixed. Otherwise the files DIM-1/region/r.5858.0.mca and region/732.0.mca would exist at least in the Survival world.
Disclaimer: I don't know if you can still get on fire if those chunks were already generated. I doubt it, because that would almost imply intentional differentiation between whether the chunk was generated before or not when putting the player in the wrong location, but I have no tested it, because that part of the bug is annoying to test.
It's not resolved yet, as of 1.18.2. I am constantly getting chunks loaded and the region/poi/entities files created/updated at the coordinates of the wrong dimension. Running on a vanilla server.
This report is currently missing crucial information. Please take a look at the other comments to find out what we are looking for.
If you added the required information and a moderator sees your comment, they will reopen and update the report. However, if you think your update to this report has been overlooked or you want to make sure that this report is reopened, you can contact the Mojira staff on Discord or Reddit.
– I am a bot. This action was performed automatically! If you think it was incorrect, please notify us on Discord or Reddit