Zonteek
- Zonteek
- zonteek
- Europe/Stockholm
- Yes
- No
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
Normal
MC-181864
Entity collisions severely impact performance even with collisionRule set to never.
Steps to reproduce
- Open a void world
- Run a few times:
/execute as @e[team=noCollision] at @s run summon cow ~ ~ ~ {NoAI:1,Team:"noCollision"}
- Open the Shift+F3 debug graph for root.tick.level.entities.regular.tick.minecraft:cow and notice that "push" takes most of the time despite the collision rule
One can repeat the steps with NoAI bats and see that they don't cause lag as bats (effectively) have the proposed fix already implemented.
Note that this bug affects all living entities within the same subchunk (a 16x16x16 unit of the world) and not only the same block.
Code analysis
The method LivingEntity.collideWithNearbyEntities calls the costly World.getEntitiesInAABBexcluding even when it's known it will return an empty list.
A proposed fix is to shortcut the method when the collision rule is set to never.
Entity collisions severely impact performance even with collisionRule set to never.
Steps to reproduce
- Open a void world
- Run a few times:
/execute as @e[team=noCollision] at @s run summon cow ~ ~ ~ {NoAI:1,Team:"noCollision"}
- Open the Shift+F3 debug graph for root.tick.level.entities.regular.tick.minecraft:cow and notice that "push" takes most of the time despite the collision rule
One can repeat the steps with NoAI bats and see that they don't cause lag as bats (effectively) have the proposed fix already implemented.
Note that this bug affects all living entities within the same subchunk (a 16x16x16 unit of the world) and not only the same block.
Code analysis
The method LivingEntity.collideWithNearbyEntities calls the costly World.getEntitiesInAABBexcluding even when it's known it will return an empty list.
A proposed fix is to shortcut the method when the collision rule is set to never.
Note that armor stands implement their own collision code but also suffer from this bug.
Entity collisions severely impact performance even with collisionRule set to never.
Steps to reproduce
- Open a void world
- Run a few times:
/execute as @e[team=noCollision] at @s run summon cow ~ ~ ~ {NoAI:1,Team:"noCollision"}
- Open the Shift+F3 debug graph for root.tick.level.entities.regular.tick.minecraft:cow and notice that "push" takes most of the time despite the collision rule
One can repeat the steps with NoAI bats and see that they don't cause lag as bats (effectively) have the proposed fix already implemented.
Note that this bug affects all living entities within the same subchunk (a 16x16x16 unit of the world) and not only the same block.
Code analysis
The method LivingEntity.
collideWithNearbyEntities calls the costlyWorld.getEntitiesInAABBexcludingeven when it's known it will return an empty list.A proposed fix is to shortcut the method when the collision rule is set to never.
Note that armor stands implement their own collision code but also suffer from this bug.
Entity collisions severely impact performance even with collisionRule set to never.
Steps to reproduce
- Open a void world
- Run a few times:
/execute as @e[team=noCollision] at @s run summon cow ~ ~ ~ {NoAI:1,Team:"noCollision"}
- Open the Shift+F3 debug graph for root.tick.level.entities.regular.tick.minecraft:cow and notice that "push" takes most of the time despite the collision rule
One can repeat the steps with NoAI bats and see that they don't cause lag as bats (effectively) have the proposed fix already implemented.
Note that this bug affects all living entities within the same subchunk (a 16x16x16 unit of the world) and not only the same block.
Code analysis (official mappings)
The method LivingEntity.pushEntities calls the costly Level.getEntities even when it's known it will return an empty list.
A proposed fix is to shortcut the method when the collision rule is set to never.
Note that armor stands implement their own collision code but also suffer from this bug.
Steps to reproduce:
- Make sure your render distance is less than 8 chunks
/summon minecart ~ ~54 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1152,NoGravity:1}
/summon minecart ~-2 ~60 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1280,NoGravity:1}
- Face west, fly up and see how the second minecart appears
Code analysis:
public boolean isInRangeToRenderDist(double distance) { double d0 = this.getBoundingBox().getAverageEdgeLength(); if (Double.isNaN(d0)) { d0 = 1.0D; } d0 = d0 * 64.0D * renderDistanceWeight; return distance < d0 * d0; }This method should use getRenderBoundingBox instead of getBoundingBox
An entity's rendering bounding box is different from the physical bounding box only in the case of minecarts and illusioners so this bug only affects these two entities.
Steps to reproduce:
- Make sure your render distance is less than 8 chunks
/summon minecart ~ ~54 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1152,NoGravity:1}
/summon minecart ~-2 ~60 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1280,NoGravity:1}
- Face west, fly up and see how the second minecart appears
This causes minecarts to not render the custom display block properly.
Code analysis:
public boolean isInRangeToRenderDist(double distance) { double d0 = this.getBoundingBox().getAverageEdgeLength(); if (Double.isNaN(d0)) { d0 = 1.0D; } d0 = d0 * 64.0D * renderDistanceWeight; return distance < d0 * d0; }This method should use getRenderBoundingBox instead of getBoundingBox
An entity's rendering bounding box is different from the physical bounding box only in the case of minecarts and illusioners so this bug only affects these two entities.
Steps to reproduce:
- Make sure your render distance is less than 8 chunks
/summon minecart ~ ~54 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1152,NoGravity:1}
/summon minecart ~-2 ~60 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1280,NoGravity:1}
- Face west, fly up and see how the second minecart appears
This causes minecarts to not render the custom display block properly.
Code analysis:
public boolean isInRangeToRenderDist(double distance) { double d0 = this.getBoundingBox().getAverageEdgeLength(); if (Double.isNaN(d0)) { d0 = 1.0D; } d0 = d0 * 64.0D * renderDistanceWeight; return distance < d0 * d0; }This method should use getRenderBoundingBox instead of getBoundingBox
An entity's rendering bounding box is different from the physical bounding box only in the case of minecarts and illusioners so this bug only affects these two entities.
Steps to reproduce:
- Make sure your render distance is less than 8 chunks
/summon minecart ~ ~54 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1152,NoGravity:1}
/summon minecart ~-2 ~60 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1280,NoGravity:1}
- Face west, fly up and see how the second minecart appears
This causes minecarts to not render the custom display block properly in certain cases.
Code analysis:
public boolean isInRangeToRenderDist(double distance) { double d0 = this.getBoundingBox().getAverageEdgeLength(); if (Double.isNaN(d0)) { d0 = 1.0D; } d0 = d0 * 64.0D * renderDistanceWeight; return distance < d0 * d0; }This method should use getRenderBoundingBox instead of getBoundingBox
An entity's rendering bounding box is different from the physical bounding box only in the case of minecarts and illusioners so this bug only affects these two entities.
Steps to reproduce:
- Make sure your render distance is less than 8 chunks
/summon minecart ~ ~54 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1152,NoGravity:1}
/summon minecart ~-2 ~60 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1280,NoGravity:1}
- Face west, fly up and see how the second minecart appears
This causes minecarts to not render the custom display block properly in certain cases.
Code analysis
:public booleanisInRangeToRenderDist(double distance) { double d0 = this.getBoundingBox().getAverageEdgeLength(); if (Double.isNaN(d0)) { d0 = 1.0D; } d0= d0* 64.0D *renderDistanceWeight; return distance < d0 * d0; }This method should use get
RenderBoundingBox instead of getBoundingBoxAn entity's
rendering bounding box is different from the physical bounding box only in the case of minecarts and illusioners so this bug only affects these two entities.Steps to reproduce:
- Make sure your render distance is less than 8 chunks
/summon minecart ~ ~54 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1152,NoGravity:1}
/summon minecart ~-2 ~60 ~ {CustomDisplayTile:1,DisplayState:{Name:"stone"},DisplayOffset:-1280,NoGravity:1}
- Face west, fly up and see how the second minecart appears
This causes minecarts to not render the custom display block properly in certain cases.
Code analysis (official mappings)
public boolean shouldRenderAtSqrDistance(double distance) { double d0 = this.getBoundingBox().getSize(); if (Double.isNaN(d0)) { d0 = 1.0D; } d0 *= 64.0D * viewScale; return distance < d0 * d0; }This method should probably use getBoundingBoxForCulling instead of getBoundingBox
An entity's culling bounding box is different from the physical bounding box only in the case of minecarts and illusioners so this bug only affects these two entities.
Steps to reproduce:
- Run the commands
/tag @s add a /tag @s add b /tag @s add p /tag @s add q /tag @s list
- The feedback is
Player has 4 tags: p, a, q, bbut it should be ordered alphabetically
Player has 4 tags: a, b, p, qOther affected commands: /scoreboard players list and /team list <team>
The affected method in class TextComponentUtils (MCP names):
public static <TextendsComparable<T>> ITextComponent makeSortedList(Collection<T> collection, Function<T, ITextComponent> toTextComponent) { if (collection.isEmpty()) { return newStringTextComponent(""); } else if (collection.size() == 1) { returntoTextComponent.apply(collection.iterator().next()); } else {List<T> list= Lists.newArrayList(collection);list.sort(Comparable::compareTo); returnmakeList(collection, toTextComponent); } }The
collection gets sorted but the result is ignored.Steps to reproduce:
- Run the commands
/tag @s add a /tag @s add b /tag @s add p /tag @s add q /tag @s list
- The feedback is
Player has 4 tags: p, a, q, bbut it should be ordered alphabetically
Player has 4 tags: a, b, p, qOther affected commands: /scoreboard players list and /team list <team>
Code analysis (official mappings)
public static Component formatAndSortList(Collection in, Function formatter) { if (in.isEmpty()) { return new TextComponent(""); } else if (in.size() == 1) { return (Component)formatter.apply(in.iterator().next()); } else { ArrayList sorted = Lists.newArrayList(in); sorted.sort(Comparable::compareTo); return formatList(in, formatter); } }The method formatAndSortList in ComponentUtils ignores the sorting result.
Steps to reproduce
- Run a minecart in a loop
- Teleport 100 blocks away and wait a few seconds
- Teleport back
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which come into the player's tracking range
buthave already existed on the server side for some time.Also, the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.Steps to reproduce
- Run a minecart in a loop
- Teleport 100 blocks away and wait a few seconds
- Teleport back
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied. This continues until the next absolute position sync.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which are moving when they come into the player's tracking range and have already existed on the server side for some time.
Also, looking at ServerEntity.sendChanges(), the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
This bug is related to
MC-342, MC-2783 and probably many other similar issues.
Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.
Steps to reproduce
- Run a minecart in a loop
- Teleport 100 blocks away and wait a few seconds
- Teleport back
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied. This continues until the next absolute position sync.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which are moving when they come into the player's tracking range and have already existed on the server side for some time.
Also, looking at ServerEntity.sendChanges(), the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
This bug is related to
MC-342, MC-2783 and probably many other similar issues.Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.Steps to reproduce
- Run a minecart in a loop (see the screenshot below)
- Teleport 100 blocks away and wait a few seconds (/tp ~100 ~ ~)
- Teleport back (/tp ~-100 ~ ~)
The minecart appears to be travelling at an offset from the track. It might take a few tries. Make sure the chunks don't unload when you teleport away.
Code analysis
When a player starts to see an entity, the server sends the entity's current position to the client. But an entity also has another, internal position used for sending and calculating relative motion updates. This position doesn't get sent to the client with the spawning packets, so every consecutive relative motion packet is incorrectly applied. This continues until the next absolute position sync.
A proposed fix is to include the internal encoded position (ServerEntity.xp/yp/zp) in entity spawning packets and set it on the client (Entity.xp/yp/zp).
This only affects entities which are moving when they come into the player's tracking range and have already existed on the server side for some time.
Also, looking at ServerEntity.sendChanges(), the position is supposed to resync every, what appears to be, 20s (400t) but the timer which tracks that gets incremented only every updateInterval ticks (e.g. arrows get resynced every 400s). I'm not sure if that's intended.
This bug is related to
MC-342, MC-2783 and probably many other similar issues.Trivia:
This is a very old bug. I was able to reproduce it on alpha 1.1.2_01, one of the first multiplayer versions.
Still present on 1.15.2. Note that the effects of this bug start to get noticeable after around 500 entities get spawned (9 runs of the execute command).
Seems fixed in 22w05a?