Savva
- Savvvage_
- JIRAUSER703968
- Europe/Stockholm
- Yes
- No
MC-240998![[Mojang] Gnembon](../../../data/avatars/users/93709.png){kind=small}
![[Mojang] SHugoh](../../../data/avatars/users/18947.svg){kind=small}
![[Mojang] Rebecca](../../../data/avatars/users/18936.svg){kind=small}
When using any tnt cannon entities move too fast thus load too many chunks which freezes the server which then crashes due to watchdog.
Previously entities werent loading chunks on their path, but 24w33a completely reworked entities colliding with interactable blocks (pressure plates, nether portals, lava cauldrons, powdered snow, etc) which makes entities load chunks.
Previously entities checked collisions with said blocks only at the end of their tick, but since 24w33a they search the entire path that entity covered in a tick for said blocks, this search loads and generates chunks which freezes the game.Example:
1.21 no lag:
https://youtu.be/HRet2xJvzhU
24w33a minute of lag and the server crashes due to watchdog:
https://youtu.be/x_pddUNtNBQ
crash report from second videoPlease note this is a very tmc (tech mc community) sensitive issue, it breaks the entire field of cannon tech, to fix it we can suggest limiting said search to only first ~10 blocks of path that entity took.
the mentioned "raycast" is performed in the
addCollisionsAlongTravel()
in the
BlockGetter.javaThis issue is related to MC-275298
When using any tnt cannon entities move too fast thus load too many chunks which freezes the server which then crashes due to watchdog.
Previously entities werent loading chunks on their path thus didnt freeze the server, but 24w33a completely reworked entities colliding with interactable blocks (pressure plates, nether portals, lava cauldrons, powdered snow, etc) which makes entities load chunks.
Previously entities checked collisions with said blocks only at the end of their tick, but since 24w33a they search the entire path that entity covered in a tick for said blocks, this search loads and generates chunks which freezes the game.Example:
1.21 no lag:
https://youtu.be/HRet2xJvzhU
24w33a minute of lag and the server crashes due to watchdog:
https://youtu.be/x_pddUNtNBQ
crash report from second videoPlease note this is a very tmc (tech mc community) sensitive issue, it breaks the entire field of cannon tech, to fix it we can suggest limiting said search to only first ~10 blocks of path that entity took.
the mentioned "raycast" is performed in the
addCollisionsAlongTravel()
in the
BlockGetter.javaThis issue is related to MC-275298
When a boat or a minecart collides with a lava cauldron it'll get damaged by a wrong value (less than expected).
Steps to replicate:
run the following commands while staying in place:
/tick freeze
/setblock ~ ~ ~ minecraft:lava_cauldron
/summon boat ~ ~ ~
get outside the cauldron and observe the boat,
run /tick step 1Expected behavior:
boat dies immidiately upon ticking (as it did in 1.21 and prior)
Observed behavior:
the boat doesnt die on the first tick and only dies on its second tickThis behavior happens for boats because since 24w33a boats miss their second collision check in their tick (before 24w33a they performed interactive collisions twice), to be precise it's in
Boat.java
in the
{{tick() }}
method.
here as shown in the pictures:
1.21 (there is a collision check):
24w33a+ (there is no secondary collisons check):
the same issue affects minecarts, they too are missing their second collision check in their own tick() method. (you can check how it was before 24w33a).
Please note that this is a tmc (technical minecraft community) sensitive issue. A lot of redstone contraptions rely on the ability of cauldrons to kill boats/carts upon their first tick of collision with the cauldron.
One way to fix
is to put the collison checks back into corresponding places.
Another way to fix this issue is to double the damage a cauldron can deal to a boat/minecart. But this will alter their behavior, so im not sure this is a good option.When a boat or a minecart collides with a lava cauldron it'll get damaged by a wrong value (less than expected).
Steps to replicate:
run the following commands while staying in place:
/tick freeze
/setblock ~ ~ ~ minecraft:lava_cauldron
/summon boat ~ ~ ~
get outside the cauldron and observe the boat,
run /tick step 1Expected behavior:
boat dies immidiately upon ticking (as it did in 1.21 and prior)
Observed behavior:
the boat doesnt die on the first tick and only dies on its second tickThis behavior happens for boats because since 24w33a boats miss their second collision check in their tick (before 24w33a they performed interactive collisions twice), to be precise it's in
Boat.java
in the
{{tick() }}
method.
here as shown in the pictures:
1.21 (there is a collision check):
24w33a+ (there is no secondary collisons check):
the same issue affects minecarts, they too are missing their second collision check in their own tick() method. (you can check how it was before 24w33a).
Please note that this is a tmc (technical minecraft community) sensitive issue. A lot of redstone contraptions rely on the ability of cauldrons to kill boats/carts upon their first tick of collision with the cauldron.
One way to fix this issue is to double the damage a cauldron can deal to a boat/minecart.
Another way to fix this is to put the secondary collison checks back into corresponding places.
So, now the order in which an entity interacts with pressure plates and alike blocks is locational. This behavior was previosly non locational thus the change breaks redstone contraptions that relied on it.
How to replicate:
Create a redstone ready superflat world in 24w40a, run these commands:
/execute in minecraft:overworld run tp @s 99999 63 19 -90 60
/fill 100000 59 17 99999 59 20 minecraft:blue_concrete
/fill 100000 60 17 99999 60 20 minecraft:heavy_weighted_pressure_plate
/fill 100000 60 18 99999 60 19 air
/setblock 100000 59 18 minecraft:sticky_piston[facing=west]
/setblock 99999 59 18 minecraft:sticky_piston[facing=east]
/setblock 100000 59 21 minecraft:sticky_piston[facing=west]
/setblock 99999 59 21 minecraft:sticky_piston[facing=east]You should get a setup that looks something like this:
Then perform these two commands and observe the pistons (which piston extends indicates which pressure plate is activated first by the boat)
/summon minecraft:armor_stand 100000. 60.00 20.5
/summon minecraft:armor_stand 100000. 60.00 17.5As you can see pistons on different sides activated, this means that the order in which an armor stand activates pressure paltes below self is not consistent.
The expected behavior is for an entity to activate the collideable blocks below self in a consistent order that does not depend on location (previously in 1.21.1 it was directional but not locational)
Code analysis:
Currently the block coords to be collided with are collected within the
boxTraverseBlocks method in the BlockGetter.java file and in the
addCollisionsAlongTravel method in the BlockGetter.java , there the block coords are put into a set (ObjectOpenHashSet), then the said set is returned to the
collectBlockCollidedWith method in the Entity.java file
Where it iterates through the set and puts all of the collected block coords into the
blocksInside field of an Entity object, this field is a HashMap, and later within the
applyEffectsFromBlocks method within the Entity.java it iterates through said map, executing block collisions for each collected block coordinate.Obviously collecting coordinates into a hashset, then puting them into a hashmap and then iterating through that scrambles the order of entries and is generally suboptimal.
Moreover, there is no real reason to store the block coordinates in any container at all, as the collision can be computed while the block coordinates are collected (so directly within the uppermentioned boxTraverseBlocks and addCollisionsAlongTravel methods). Executing the collisions right when the collisiosn block coordinate is acquired will not only fix the issue with the collision order being inconsistent (locational), but will also increase the performance just a bit because the game wont have to initialise a set and a map of 1-8 entries per each entity per each game tick.For clarification, by "executing the collision" i mean checking if the entity intersects the collidable part of the hitbox of a block located at the collected block coordinate as done here in the collectBlockCollidedWith method:
and later performing block reaction to entity collision as it is currently done here within the applyEffectsFromBlocks method:
And by "executing collisions while the block coordinates are collected" i mean executing them inside inside the boxTraverseBlocks and addCollisionsAlongTravel immideately instead of puting the block coordinates into the set.
Please note, that this issue does break certain redstone contraptions, and it does so in a very annoying way, as there are no meaningful alternatives to fix this issue with the ingame means, it just detracts from the gameplay.
So, now the order in which an entity interacts with pressure plates and alike blocks is locational. This behavior was previosly non locational thus the change breaks redstone contraptions that relied on it.
How to replicate:
Create a redstone ready superflat world in 24w40a, run these commands:
/execute in minecraft:overworld run tp @s 99999 63 19 -90 60
/fill 100000 59 17 99999 59 20 minecraft:blue_concrete
/fill 100000 60 17 99999 60 20 minecraft:heavy_weighted_pressure_plate
/fill 100000 60 18 99999 60 19 air
/setblock 100000 59 18 minecraft:sticky_piston[facing=west]
/setblock 99999 59 18 minecraft:sticky_piston[facing=east]
/setblock 100000 59 21 minecraft:sticky_piston[facing=west]
/setblock 99999 59 21 minecraft:sticky_piston[facing=east]You should get a setup that looks something like this:
Then perform these two commands and observe the pistons (which piston extends indicates which pressure plate is activated first by the boat)
/summon minecraft:armor_stand 100000. 60.00 20.5
/summon minecraft:armor_stand 100000. 60.00 17.5As you can see pistons on different sides activated, this means that the order in which an armor stand activates pressure paltes below self is not consistent.
The expected behavior is for an entity to activate the collideable blocks below self in a consistent order that does not depend on location (previously in 1.21.1 it was directional but not locational)
Code analysis:
Currently the block coords to be collided with are collected within the
boxTraverseBlocks method in the BlockGetter.java file and in the
addCollisionsAlongTravel method in the BlockGetter.java , there the block coords are put into a set (ObjectOpenHashSet), then the said set is returned to the
collectBlockCollidedWith method in the Entity.java file
Where it iterates through the set and puts all of the collected block coords into the
blocksInside field of an Entity object, this field is a HashMap, and later within the
applyEffectsFromBlocks method within the Entity.java it iterates through said map, executing block collisions for each collected block coordinate.Obviously collecting coordinates into a hashset, then puting them into a hashmap and then iterating through that scrambles the order of entries and is generally suboptimal.
Moreover, there is no real reason to store the block coordinates in any container at all, as the collision can be computed while the block coordinates are collected (so directly within the uppermentioned boxTraverseBlocks and addCollisionsAlongTravel methods). Executing the collisions right when the collisiosn block coordinate is acquired will not only fix the issue with the collision order being inconsistent (locational), but will also increase the performance just a bit because the game wont have to initialise a set and a map of 1-8 entries per each entity per each game tick.For clarification, by "executing the collision" i mean checking if the entity intersects the collidable part of the hitbox of a block located at the collected block coordinate as done here in the collectBlockCollidedWith method:
and later performing block reaction to entity collision as it is currently done here within the applyEffectsFromBlocks method:
And by "executing collisions while the block coordinates are collected" i mean executing them inside inside the boxTraverseBlocks and addCollisionsAlongTravel immideately instead of puting the block coordinates into the set.
Please note, that this issue does break certain redstone contraptions, and it does so in a very annoying way, as there are no meaningful alternatives to fix this issue with the ingame means, it just detracts from the gameplay.
This issue happens in the same place in code as the MC-275437
Entity Collision order is now locational
So, now the order in which an entity interacts with pressure plates and alike blocks is locational. This behavior was previosly non locational thus the change breaks redstone contraptions that relied on it.
How to replicate:
Create a redstone ready superflat world in 24w40a, run these commands:
/execute in minecraft:overworld run tp @s 99999 63 19 -90 60
/fill 100000 59 17 99999 59 20 minecraft:blue_concrete
/fill 100000 60 17 99999 60 20 minecraft:heavy_weighted_pressure_plate
/fill 100000 60 18 99999 60 19 air
/setblock 100000 59 18 minecraft:sticky_piston[facing=west]
/setblock 99999 59 18 minecraft:sticky_piston[facing=east]
/setblock 100000 59 21 minecraft:sticky_piston[facing=west]
/setblock 99999 59 21 minecraft:sticky_piston[facing=east]You should get a setup that looks something like this:
Then perform these two commands and observe the pistons (which piston extends indicates which pressure plate is activated first by the
boat)
/summon minecraft:armor_stand 100000. 60.00 20.5
/summon minecraft:armor_stand 100000. 60.00 17.5As you can see pistons on different sides activated, this means that the order in which an armor stand activates pressure paltes below self is not consistent.
The expected behavior is for an entity to activate the collideable blocks below self in a consistent order that does not depend on location (previously in 1.21.1 it was directional but not locational)
Code analysis:
Currently the block coords to be collided with are collected within the
boxTraverseBlocks method in the BlockGetter.java file and in the
addCollisionsAlongTravel method in the BlockGetter.java , there the block coords are put into a set (ObjectOpenHashSet), then the said set is returned to the
collectBlockCollidedWith method in the Entity.java file
Where it iterates through the set and puts all of the collected block coords into the
blocksInside field of an Entity object, this field is a HashMap, and later within the
applyEffectsFromBlocks method within the Entity.java it iterates through said map, executing block collisions for each collected block coordinate.Obviously collecting coordinates into a hashset, then puting them into a hashmap and then iterating through that scrambles the order of entries and is generally suboptimal.
Moreover, there is no real reason to store the block coordinates in any container at all, as the collision can be computed while the block coordinates are collected (so directly within the uppermentioned boxTraverseBlocks and addCollisionsAlongTravel methods). Executing the collisions right when the collisiosn block coordinate is acquired will not only fix the issue with the collision order being inconsistent (locational), but will also increase the performance just a bit because the game wont have to initialise a set and a map of 1-8 entries per each entity per each game tick.For clarification, by "executing the collision" i mean checking if the entity intersects the collidable part of the hitbox of a block located at the collected block coordinate as done here in the collectBlockCollidedWith method:
and later performing block reaction to entity collision as it is currently done here within the applyEffectsFromBlocks method:
And by "executing collisions while the block coordinates are collected" i mean executing them inside inside the boxTraverseBlocks and addCollisionsAlongTravel immideately instead of puting the block coordinates into the set.
Please note, that this issue does break certain redstone contraptions, and it does so in a very annoying way, as there are no meaningful alternatives to fix this issue with the ingame means, it just detracts from the gameplay.
This issue happens in the same place in code as the MC-275437
So, now the order in which an entity interacts with pressure plates and alike blocks is locational. This behavior was previosly non locational thus the change breaks redstone contraptions that relied on it.
How to replicate:
Create a redstone ready superflat world in 24w40a, run these commands:
/execute in minecraft:overworld run tp @s 99999 63 19 -90 60
/fill 100000 59 17 99999 59 20 minecraft:blue_concrete
/fill 100000 60 17 99999 60 20 minecraft:heavy_weighted_pressure_plate
/fill 100000 60 18 99999 60 19 air
/setblock 100000 59 18 minecraft:sticky_piston[facing=west]
/setblock 99999 59 18 minecraft:sticky_piston[facing=east]
/setblock 100000 59 21 minecraft:sticky_piston[facing=west]
/setblock 99999 59 21 minecraft:sticky_piston[facing=east]You should get a setup that looks something like this:
Then perform these two commands and observe the pistons (which piston extends indicates which pressure plate is activated first by the armor stand)
/summon minecraft:armor_stand 100000. 60.00 20.5
/summon minecraft:armor_stand 100000. 60.00 17.5As you can see pistons on different sides activated, this means that the order in which an armor stand activates pressure paltes below self is not consistent.
The expected behavior is for an entity to activate the collideable blocks below self in a consistent order that does not depend on location (previously in 1.21.1 it was directional but not locational)
Code analysis:
Currently the block coords to be collided with are collected within the
boxTraverseBlocks method in the BlockGetter.java file and in the
addCollisionsAlongTravel method in the BlockGetter.java , there the block coords are put into a set (ObjectOpenHashSet), then the said set is returned to the
collectBlockCollidedWith method in the Entity.java file
Where it iterates through the set and puts all of the collected block coords into the
blocksInside field of an Entity object, this field is a HashMap, and later within the
applyEffectsFromBlocks method within the Entity.java it iterates through said map, executing block collisions for each collected block coordinate.Obviously collecting coordinates into a hashset, then puting them into a hashmap and then iterating through that scrambles the order of entries and is generally suboptimal.
Moreover, there is no real reason to store the block coordinates in any container at all, as the collision can be computed while the block coordinates are collected (so directly within the uppermentioned boxTraverseBlocks and addCollisionsAlongTravel methods). Executing the collisions right when the collisiosn block coordinate is acquired will not only fix the issue with the collision order being inconsistent (locational), but will also increase the performance just a bit because the game wont have to initialise a set and a map of 1-8 entries per each entity per each game tick.For clarification, by "executing the collision" i mean checking if the entity intersects the collidable part of the hitbox of a block located at the collected block coordinate as done here in the collectBlockCollidedWith method:
and later performing block reaction to entity collision as it is currently done here within the applyEffectsFromBlocks method:
And by "executing collisions while the block coordinates are collected" i mean executing them inside inside the boxTraverseBlocks and addCollisionsAlongTravel immideately instead of puting the block coordinates into the set.
Please note, that this issue does break certain redstone contraptions, and it does so in a very annoying way, as there are no meaningful alternatives to fix this issue with the ingame means, it just detracts from the gameplay.
This issue happens in the same place in code as the MC-275437
So, now the order in which an entity interacts with pressure plates and alike blocks is locational. This behavior was previosly non locational thus the change breaks redstone contraptions that relied on it.
How to replicate:
Create a redstone ready superflat world in 24w40a, run these commands:
/execute in minecraft:overworld run tp @s 99999 63 19 -90 60
/fill 100000 59 17 99999 59 20 minecraft:blue_concrete
/fill 100000 60 17 99999 60 20 minecraft:heavy_weighted_pressure_plate
/fill 100000 60 18 99999 60 19 air
/setblock 100000 59 18 minecraft:sticky_piston[facing=west]
/setblock 99999 59 18 minecraft:sticky_piston[facing=east]
/setblock 100000 59 21 minecraft:sticky_piston[facing=west]
/setblock 99999 59 21 minecraft:sticky_piston[facing=east]You should get a setup that looks something like this:
Then perform these two commands and observe the pistons (which piston extends indicates which pressure plate is activated first by the armor stand)
/summon minecraft:armor_stand 100000. 60.00 20.5
/summon minecraft:armor_stand 100000. 60.00 17.5As you can see pistons on different sides activated, this means that the order in which an armor stand activates pressure p
altes below self is not consistent.
The expected behavior is for an entity to activate the collideable blocks below self in a consistent order that does not depend on location (previously in 1.21.1 it was directional but not locational)
Code analysis:
Currently the block coords to be collided with are collected within the
boxTraverseBlocks method in the BlockGetter.java file and in the
addCollisionsAlongTravel method in the BlockGetter.java , there the block coords are put into a set (ObjectOpenHashSet), then the said set is returned to the
collectBlockCollidedWith method in the Entity.java file
Where it iterates through the set and puts all of the collected block coords into the
blocksInside field of an Entity object, this field is a HashMap, and later within the
applyEffectsFromBlocks method within the Entity.java it iterates through said map, executing block collisions for each collected block coordinate.Obviously collecting coordinates into a hashset, then puting them into a hashmap and then iterating through that scrambles the order of entries and is generally suboptimal.
Moreover, there is no real reason to store the block coordinates in any container at all, as the collision can be computed while the block coordinates are collected (so directly within the uppermentioned boxTraverseBlocks and addCollisionsAlongTravel methods). Executing the collisions right when the collisiosn block coordinate is acquired will not only fix the issue with the collision order being inconsistent (locational), but will also increase the performance just a bit because the game wont have to initialise a set and a map of 1-8 entries per each entity per each game tick.For clarification, by "executing the collision" i mean checking if the entity intersects the collidable part of the hitbox of a block located at the collected block coordinate as done here in the collectBlockCollidedWith method:
and later performing block reaction to entity collision as it is currently done here within the applyEffectsFromBlocks method:
And by "executing collisions while the block coordinates are collected" i mean executing them inside inside the boxTraverseBlocks and addCollisionsAlongTravel immideately instead of puting the block coordinates into the set.
Please note, that this issue does break certain redstone contraptions, and it does so in a very annoying way, as there are no meaningful alternatives to fix this issue with the ingame means, it just detracts from the gameplay.
This issue happens in the same place in code as the MC-275437
So, now the order in which an entity interacts with pressure plates and alike blocks is locational. This behavior was previosly non locational thus the change breaks redstone contraptions that relied on it.
How to replicate:
Create a redstone ready superflat world in 24w40a, run these commands:
/execute in minecraft:overworld run tp @s 99999 63 19 -90 60
/fill 100000 59 17 99999 59 20 minecraft:blue_concrete
/fill 100000 60 17 99999 60 20 minecraft:heavy_weighted_pressure_plate
/fill 100000 60 18 99999 60 19 air
/setblock 100000 59 18 minecraft:sticky_piston[facing=west]
/setblock 99999 59 18 minecraft:sticky_piston[facing=east]
/setblock 100000 59 21 minecraft:sticky_piston[facing=west]
/setblock 99999 59 21 minecraft:sticky_piston[facing=east]You should get a setup that looks something like this:
Then perform these two commands and observe the pistons (which piston extends indicates which pressure plate is activated first by the armor stand)
/summon minecraft:armor_stand 100000. 60.00 20.5
/summon minecraft:armor_stand 100000. 60.00 17.5As you can see pistons on different sides activated, this means that the order in which an armor stand activates pressure plates below self is not consistent.
The expected behavior is for an entity to activate the collideable blocks below self in a consistent order that does not depend on location (previously in 1.21.1 it was directional but not locational)
Code analysis:
Currently the block coords to be collided with are collected within the
boxTraverseBlocks method in the BlockGetter.java file and in the
addCollisionsAlongTravel method in the BlockGetter.java , there the block coords are put into a set (ObjectOpenHashSet), then the said set is returned to the
collectBlockCollidedWith method in the Entity.java file
Where it iterates through the set and puts all of the collected block coords into the
blocksInside field of an Entity object, this field is a HashMap, and later within the
applyEffectsFromBlocks method within the Entity.java it iterates through said map, executing block collisions for each collected block coordinate.Obviously collecting coordinates into a hashset, then puting them into a hashmap and then iterating through that scrambles the order of entries and is generally suboptimal.
Moreover, there is no real reason to store the block coordinates in any container at all, as the collision can be computed while the block coordinates are collected (so directly within the uppermentioned boxTraverseBlocks and addCollisionsAlongTravel methods). Executing the collisions right when the collisiosn block coordinate is acquired will not only fix the issue with the collision order being inconsistent (locational), but will also increase the performance just a bit because the game wont have to initialise a set and a map of 1-8 entries per each entity per each game tick.For clarification, by "executing the collision" i mean checking if the entity intersects the collidable part of the hitbox of a block located at the collected block coordinate as done here in the collectBlockCollidedWith method:
and later performing block reaction to entity collision as it is currently done here within the applyEffectsFromBlocks method:
And by "executing collisions while the block coordinates are collected" i mean executing them inside inside the boxTraverseBlocks and addCollisionsAlongTravel immideately instead of puting the block coordinates into the set.
Please note, that this issue does break certain redstone contraptions, and it does so in a very annoying way, as there are no meaningful alternatives to fix this issue with the ingame means, it just detracts from the gameplay.
This issue happens in the same place in code as the MC-275437
So, now the order in which an entity interacts with pressure plates and alike blocks is locational. This behavior was previosly non locational thus the change breaks redstone contraptions that relied on it.
How to replicate:
Create a redstone ready superflat world in 24w40a, run these commands:
/execute in minecraft:overworld run tp @s 99999 63 19 -90 60
/fill 100000 59 17 99999 59 20 minecraft:blue_concrete
/fill 100000 60 17 99999 60 20 minecraft:heavy_weighted_pressure_plate
/fill 100000 60 18 99999 60 19 air
/setblock 100000 59 18 minecraft:sticky_piston[facing=west]
/setblock 99999 59 18 minecraft:sticky_piston[facing=east]
/setblock 100000 59 21 minecraft:sticky_piston[facing=west]
/setblock 99999 59 21 minecraft:sticky_piston[facing=east]You should get a setup that looks something like this:
Then perform these two commands and observe the pistons (which piston extends indicates which pressure plate is activated first by the armor stand)
/summon minecraft:armor_stand 100000. 60.00 20.5
/summon minecraft:armor_stand 100000. 60.00 17.5As you can see pistons on different sides activated, this means that the order in which an armor stand activates pressure plates below self is not consistent.
The expected behavior is for an entity to activate the collideable blocks below self in a consistent order that does not depend on location (previously in 1.21.1 it was directional but not locational)
Code analysis:
Currently the block coords to be collided with are collected within the
boxTraverseBlocks method in the BlockGetter.java file and in the
addCollisionsAlongTravel method in the BlockGetter.java , there the block coords are put into a set (ObjectOpenHashSet), then the said set is returned to the
collectBlockCollidedWith method in the Entity.java file
Where it iterates through the set and puts all of the collected block coords into the
blocksInside field of an Entity object, this field is a HashMap, and later within the
applyEffectsFromBlocks method within the Entity.java it iterates through said map, executing block collisions for each collected block coordinate.Obviously collecting coordinates into a hashset, then puting them into a hashmap and then iterating through that scrambles the order of entries and is generally suboptimal.
Moreover, there is no real reason to store the block coordinates in any container at all, as the collision can be computed while the block coordinates are collected (so directly within the uppermentioned boxTraverseBlocks and addCollisionsAlongTravel methods). Executing the collisions right when the collisiosn block coordinate is acquired will not only fix the issue with the collision order being inconsistent (locational), but will also increase the performance just a bit because the game wont have to initialise a set and a map of 1-8 entries per each entity per each game tick.For clarification, by "executing the collision" i mean checking if the entity intersects the collidable part of the hitbox of a block located at the collected block coordinate as done here in the collectBlockCollidedWith method:
and later performing block reaction to entity collision as it is currently done here within the applyEffectsFromBlocks method:
And by "executing collisions while the block coordinates are collected" i mean executing them inside inside the boxTraverseBlocks and addCollisionsAlongTravel immideately instead of puting the block coordinates into the set
.Please note, that this issue does break certain redstone contraptions, and it does so in a very annoying way, as there are no meaningful alternatives to fix this issue with the ingame means, it just detracts from the gameplay.
This issue happens in the same place in code as the MC-275437
So, now the order in which an entity interacts with pressure plates and alike blocks is locational. This behavior was previosly non locational thus the change breaks redstone contraptions that relied on it.
How to replicate:
Create a redstone ready superflat world in 24w40a, run these commands:
/execute in minecraft:overworld run tp @s 99999 63 19 -90 60
/fill 100000 59 17 99999 59 20 minecraft:blue_concrete
/fill 100000 60 17 99999 60 20 minecraft:heavy_weighted_pressure_plate
/fill 100000 60 18 99999 60 19 air
/setblock 100000 59 18 minecraft:sticky_piston[facing=west]
/setblock 99999 59 18 minecraft:sticky_piston[facing=east]
/setblock 100000 59 21 minecraft:sticky_piston[facing=west]
/setblock 99999 59 21 minecraft:sticky_piston[facing=east]You should get a setup that looks something like this:
Then perform these two commands and observe the pistons (which piston extends indicates which pressure plate is activated first by the armor stand)
/summon minecraft:armor_stand 100000. 60.00 20.5
/summon minecraft:armor_stand 100000. 60.00 17.5As you can see pistons on different sides activated, this means that the order in which an armor stand activates pressure plates below self is not consistent.
The expected behavior is for an entity to activate the collideable blocks below self in a consistent order that does not depend on location (previously in 1.21.1 it was directional but not locational)
Code analysis:
Currently the block coords to be collided with are collected within the
boxTraverseBlocks method in the BlockGetter.java file and in the
addCollisionsAlongTravel method in the BlockGetter.java , there the block coords are put into a set (ObjectOpenHashSet), then the said set is returned to the
collectBlockCollidedWith method in the Entity.java file
Where it iterates through the set and puts all of the collected block coords into the
blocksInside field of an Entity object, this field is a HashMap, and later within the
applyEffectsFromBlocks method within the Entity.java it iterates through said map, executing block collisions for each collected block coordinate.Obviously collecting coordinates into a hashset, then puting them into a hashmap and then iterating through that scrambles the order of entries and is generally suboptimal.
Moreover, there is no real reason to store the block coordinates in any container at all, as the collision can be computed while the block coordinates are collected (so directly within the uppermentioned boxTraverseBlocks and addCollisionsAlongTravel methods). Executing the collisions right when the collisiosn block coordinate is acquired will not only fix the issue with the collision order being inconsistent (locational), but will also increase the performance just a bit because the game wont have to initialise a set and a map of 1-8 entries per each entity per each game tick.For clarification, by "executing the collision" i mean checking if the entity intersects the collidable part of the hitbox of a block located at the collected block coordinate as done here in the collectBlockCollidedWith method:
and later performing block reaction to entity collision as it is currently done here within the applyEffectsFromBlocks method:
And by "executing collisions while the block coordinates are collected" i mean executing them inside inside the boxTraverseBlocks and addCollisionsAlongTravel immideately instead of puting the block coordinates into the set here:
and here:
Please note, that this issue does break certain redstone contraptions, and it does so in a very annoying way, as there are no meaningful alternatives to fix this issue with the ingame means, it just detracts from the gameplay.
This issue happens in the same place in code as the MC-275437
So, now the order in which an entity interacts with pressure plates and alike blocks is locational. This behavior was previosly non locational thus the change breaks redstone contraptions that relied on it.
How to replicate:
Create a redstone ready superflat world in 24w40a, run these commands:
/execute in minecraft:overworld run tp @s 99999 63 19 -90 60
/fill 100000 59 17 99999 59 20 minecraft:blue_concrete
/fill 100000 60 17 99999 60 20 minecraft:heavy_weighted_pressure_plate
/fill 100000 60 18 99999 60 19 air
/setblock 100000 59 18 minecraft:sticky_piston[facing=west]
/setblock 99999 59 18 minecraft:sticky_piston[facing=east]
/setblock 100000 59 21 minecraft:sticky_piston[facing=west]
/setblock 99999 59 21 minecraft:sticky_piston[facing=east]You should get a setup that looks something like this:
Then perform these two commands and observe the pistons (which piston extends indicates which pressure plate is activated first by the armor stand)
/summon minecraft:armor_stand 100000. 60.00 20.5
/summon minecraft:armor_stand 100000. 60.00 17.5As you can see pistons on different sides activated, this means that the order in which an armor stand activates pressure plates below self is not consistent.
The expected behavior is for an entity to activate the collideable blocks below self in a consistent order that does not depend on location (previously in 1.21.1 it was directional but not locational)
Code analysis:
Currently the block coords to be collided with are collected within the
boxTraverseBlocks method in the BlockGetter.java file and in the
addCollisionsAlongTravel method in the BlockGetter.java , there the block coords are put into a set (ObjectOpenHashSet), then the said set is returned to the
collectBlockCollidedWith method in the Entity.java file
Where it iterates through the set and puts all of the collected block coords into the
blocksInside field of an Entity object, this field is a HashMap, and later within the
applyEffectsFromBlocks method within the Entity.java it iterates through said map, executing block collisions for each collected block coordinate.Obviously collecting coordinates into a hashset, then puting them into a hashmap and then iterating through that scrambles the order of entries and is generally suboptimal.
Moreover, there is no real reason to store the block coordinates in any container at all, as the collision can be computed while the block coordinates are collected (so directly within the uppermentioned boxTraverseBlocks and addCollisionsAlongTravel methods). Executing the collisions right when the collisiosn block coordinate is acquired will not only fix the issue with the collision order being inconsistent (locational), but will also increase the performance just a bit because the game wont have to initialise a set and a map of 1-8 entries per each entity per each game tick.For clarification, by "executing the collision" i mean checking if the entity intersects the collidable part of the hitbox of a block located at the collected block coordinate as done here in the collectBlockCollidedWith method:
and later performing block reaction to entity collision as it is currently done here within the applyEffectsFromBlocks method:
And by "executing collisions while the block coordinates are collected" i mean executing them inside inside the boxTraverseBlocks and addCollisionsAlongTravel immideately instead of puting the block coordinates into the set here:
and here:
and there has to be a check against performing the collision on the same position multiple times as currently this cant happen because of positions being stored in a set.Please note, that this issue does break certain redstone contraptions, and it does so in a very annoying way, as there are no meaningful alternatives to fix this issue with the ingame means, it just detracts from the gameplay.
This issue happens in the same place in code as the MC-275437
p1.jpg
So, first of all that new behaviour breaks lazy looting - a contraption that allows to significantly reduce lag from large mob farms. it will break lazy acceleration cannons, and also previously various redstone contraptions were designed to fit in 5x5 chunks to fit in one chunkloader, but now loaders only process redsone in 3x3 chunks so we would need to build more loaders creating more lag. it also breaks super fast crafters as they require to store items in lazy chunks. links to lazy looting: https://www.youtube.com/watch?v=T7yXrU31gmw & https://www.youtube.com/watch?v=B2HAUsigb9c .
from redstone perspective itmakes a lot of sense for crafters to support quasi connectivity as it behaves like a dropper, also it would allow for much more interesting to design autocrafter mechanisms as quasi connectivity allows for more ways to wire redstone contraptions (it is even more important for crafters as one of ther most effective ways to design those is 1wt (one wide tileable) which leaves only 4 faces of a crafter block to work with, so crafter redstone contraptions would benefit a lot from being able to power crafter fromm 1 block above as it leaves more block faces to input items into crafter block)
oman, hopper minecarts not being able to pull items through blocks breaks every contraptions that uses hopper carts, i really hope this gets reverted, otherwise hopper carts become kinda useless for redstone contraptions
can confirm 24w21b
here is a world download with the setup to replicate the issue, steps to replicate:
-open the world in 1.20.6, if you for any reason aren't spawned near the setup (its a portal on the nether roof), then run this command to tp to it:
/execute in minecraft:the_nether run tp @s 10000.26 128.00 10000.47 -90. 0
-press the button on the command block, you will see the message in chat appear saying that the A chunk is loaded, but no message about chunk B being loaded, this is the expected behavior.
-now open the world in 24w21b, press the button on the command block, you will see the message in chat appear saying that the B chunk is loaded, but no message about chunk A being loaded, this difference in chunkloading behavior is the issue, it happens due to the change in the position where the chunkloading ticket is created and this issue breaks (without any way to fix them) a lot of contraptions people have built so far.
brief explanation of how the setup works:
when you press the button on the command block, it spawn an armor stand in the portal in front of you which makes it teleport into the overworld where it loads chunks and depending on which version you are in it loads different chunks with different command blocks which spam the corresponding message.
Chunkloadin_bug_showcase.zip
can confirm for 1.20.6, here is the test setup for those who want to replicate: explosion_lag_issue.zip
how to use the setup:
-load the world in 1.20.2 (version before the issue is introduced), press the button on the command block (its near the diamond block), wait till the game unfreezes from lag, check how much server is lagging behind in the console
-load the world in 1.20.6 (version after the issue is introduced), press the button, wait till the game unfreezes from lag and check how much server is lagging behind in the console, it should be roughly twice as much behind as the test in 1.20.2 was.
in my own testing this issue indeed made explosions lag about twice as much compared to how it was before the issue was introduced, exact amount of lag is in the attached screenshots.
It is important to note, that even though this issue is marked as related to two other reports, MC-238249 is about a completely different issue (the one related to block breaking and not entity interaction) and the MC-260762 just being a feature request asking to implement an optimization from a certain mod even though it is not vanilla-preserving (as in it breaks vanilla behavior thus breaking even more explosion related contraptions).
However this report (
MC-272414), states that since 23w45a the entire exposure calculation is needlessly done twice which worsens the lag from it even more, this leads to tnt cannons becoming too laggy to use for many players. thus entire field of cannon and tnt related redstone suffers a lot, i (and many others from tnt tech community) really hope this issue gets fixed soon.Can confirm 1.21 pre-1
Here is the testing world to help reproduce the issue:
Ender_Pearl_Portal_Issue.zip
Steps to reproduce:
-load the world in 1.21 pre-1
-press a button near a diamond block to activate a command block (it'll align your player to a right angle)
-without moving your mouse throw the pearl into the portal in front of you
-observe that the pearl doesn't teleport you to the nether as it got stuck in lazy chunks there
Can confirm in 1.21 pre-1 and 1.21 pre-2,
This issue is very important cus it breaks all vehicle-passenger related contraption that technical minecraft community has designed over the years, and it breaks most of them fundamentally cus most of them rely on the cart dismounting its passenger specifically not on a rail block, as it is very hard to get a mob from a rail in a controllable manner (without causing entity cramming in entity holding chambers etc).
Can confirm in 1.21 pre-1 and 1.21 pre-2,
This issue is very important cus it breaks all vehicle-passenger related contraption that technical minecraft community has designed over the years, and it breaks most of them fundamentally cus most of them rely on the cart dismounting its passenger specifically not on a rail block, as it is very hard to get a mob from a rail in a controllable manner (without causing entity cramming in entity holding chambers etc).
Expected behavior is for entities to dismount the carts to the side of the cart, exactly the way it was in 1.20 and in versions prior to that
can confirm 1.21
The main issue described here is the loss of block events upon a reload (they just arent saved)
Which makes it so if the restart happens in a right tick pistons just wont extend at all cus their corresponding block events didnt save.
The second issue present here is scrambling of block entity ticking order and
this issue affects not only pistons, but all block entities, this causes a lot of sensitive contraptions to break.
Here is a testing setup to replicate the issue:
Block Enitty hash issue.zip
To replicate follow these steps:
1. Reset the contraption by the note block labeled Reset (next to a gold block).
2. Test the contraption by clicking the note block (next to the diamond block). Observe the pistons extending, only the pistons in the same row activates.
3. Reload the world. After the reload the pistons no longer behave normally. Their behavior changes by the pistons on random side extending.
4. Resetting the contraption fixes it till the area reloads resulting in the scrambled order again.
Noting that the bug is locational. It appears after reload. It affects more than pistons, all block entity's are affected.
This happens due to order in which ticking block entities get ticked is scrambled upon a chunk reload due to the way they are stored.
This bug affects a lot of redstone contraptions, such as storage systems, flying machines, and basically all contraptions which rely on block entity ticking order, so basically any sensitive contraption.
There is a simple way to fix this issue:
in
```
ChunkAccess.java
```
The fix is in done by changing the hash map to a linked hash map
```
protected final Map<BlockPos, BlockEntity> blockEntities = new Object2ObjectOpenHashMap<>();
```
the fix is simply done by changing it to
```
new Object2ObjectLinkedOpenHashMap<>();
```
This issue causes a lot of sensitive contraptions to break.
Here is a testing setup to replicate the issue:
Block Enitty hash issue.zip
To replicate follow these steps:
1. Reset the contraption by the note block labeled Reset (next to a gold block).
2. Test the contraption by clicking the note block (next to the diamond block). Observe the pistons extending, only the pistons in the same row activates.
3. Reload the world. After the reload the pistons no longer behave normally. Their behavior changes by the pistons on random side extending.
4. Resetting the contraption fixes it till the area reloads resulting in the scrambled order again.
Noting that the bug is locational. It appears after reload. It affects more than pistons, all block entity's are affected.
This happens due to order in which ticking block entities get ticked is scrambled upon a chunk reload due to the way they are stored.
This bug affects a lot of redstone contraptions, such as storage systems, flying machines, and basically all contraptions which rely on block entity ticking order, so basically any sensitive contraption.
There is a simple way to fix this issue:
in
```
ChunkAccess.java
```
The fix is in done by changing the hash map to a linked hash map
```
protected final Map<BlockPos, BlockEntity> blockEntities = new Object2ObjectOpenHashMap<>();
```
the fix is simply done by changing it to
```
new Object2ObjectLinkedOpenHashMap<>();
```
can confirm 1.21
can confirm
Here is a full list of affected blocks:
This issue lies within the method that collects the block positions for collision. Previously entity hitbox was contracted by 10^-7 blocks so that if the entity intersected the block space of an interactable block by a tiny bit it didnt include it in the collision calculation, and since 24w33a the entity hitbox gets infltated instead which causes the issue
Old code:
New code:
still an issue in 24w34a
i can reproduce it, 24w34a, this seems very important
this happens due to pressing the button while one of the pistons is on cooldown, this has nothing to do with update order
This behaviour is indeed very important for tech and removing it will just detract from the gameplay as there are just no alternatives to it, please consider this a tmc sensitive issue
can confirm 24w34a
The rendering of those boxes has nothing to do with actual collision boxes of a block, the way you see the azalea being split into 5 boxes is just a consequence of the way they are rendered and the actual hitboxes used for collision have entirely different and correct shape., One can verify this by clipping entites into non full blocks. I'd say this report is invalid
1.20.3 introduced 2 lag causes to explosion code:
MC-272414and after looking at code and testing in game i can verify that this specific issue is indeed fixed.To verify that the issue lies within the block removal, one can use the same setup as shown in the screenshots above, but with a liquid source where the explosions happen, that way each explosion will collect no block positions for blocks to be exploded, thus skipping almost the entire block removal part of the explosion but not the other parts of the explosion, and indeed from my testing there is no lag difference in between 1.20.2 and 24w34a with water present.
Yet without water the lag difference between versions is about x1.5
i hope someone can post a propper code analisys of the block removal part of the explosion, if noone does ill do it later
can confirm 24w35a
still an issue in 24w35a
We did some math and the raycast can be limited by up to 30 blocks, any more than that leads to excessive chunkloading (its 30 because its width of 2 chunks that separate the entity processing chunks where entity can start its tick from unloaded chunks minus half the maximum hitbox size of the entity that can be shot in regular circumstances)
that is caused by the loss of block events upon server restart, its already reported MC-89146
that issue is tmc sensitive and very annoying, i hope itll get fixed
can confirm with Minecart Experimantal features in 24w36a
as stated in the changelog the update order changes affect only dust and not other processes in the game, in this case directionality comes from the update order of the redstone block placement, however in the experiments the 0tick gens (and all of the other contraptions involving redstone dust) become chiral which is almost the same as directionality. The chirality of redstone dust is the direct consequence of the "left hand" rule
This is a normal behavior and works as expected.
This happens due to the block event for extension on the leftmost horizontal piston not being scheduled due to push limit, and being later scheduled by some other update when the vertical piston is pushed down thus making the horizontal piston being able to extend. This behavior is commonly know as "push limit detector" and is actively used in tree farms
Can confirm 1.21.2rc1
This happens because of the way how
MC-276876was fixed, previously (in 1.21) upon ticking, the cart would damage itself in 2 places in its tick, first here in the moveAlongTrack() method in the AbstracktMinecraft.java, (it calls enitity.move() which has the cauldron collision check in the tryCheckInsideBlocks() method thats within.) and the scond time the cart damages self upon executing the this.checkInsideBlocks(); within the tick() method in the AbstracktMinecraft.javaSo 2 damage calls here and here:
But after the fix of
MC-276876the first damage call was moved to another place which changed the order of important stuff within the cart (and also boat) ticks.Now it looks like this:
Notice that the cart no longer damages itself within the moveAlongTrack() method, previously it happened within the move() call within it, but entity.move() no longer does collision checks with cauldrons and such blocks in 1.21.2 rc1
The damage now happens 2 times, both within the .applyEffectsFromBlocks() method, thus the first damage call happans way later compared to where it was called in 1.21.
the fix for this issue should be simple: just move the duplicate applyEffectsFromBlocks() call from here
to here (right after the cart calls enity.move() on self, it deos so within the this.minecart.move() within the moveAlongTrack() method):
Please notice that the same exact issue happens to Boats, the fix for them is the same, just move the duplicate collision chechk to where it is logically supposed to be:
Also it is important to note that fixing the issue the way described above should make it so both this issue and the
MC-276876are fixedcan confirm, moreover it not only affects tnts, but all entities. Some redstone contraptions broke due to this issue.
The redstone torch updates got changed too for the same reason, and there are possibly more affected blocks.
issue still persists in some cases. For example breaking a powered lever by a piston doesnt send required updates.
here is a demonstration video https://www.bilibili.com/video/BV1avwge2Et2/?share_source=copy_web&vd_source=966badf48a7682d5cf56c2abe89a1898
the items are still on portal cooldown after entering the nether