The bug
The block collisions method for entities is incredibly inefficient and performs insanely redundant computations for no reason. Each tick when an entity calls the movement method to update it's position, it will first move in the Y axis, then move in the X or Z depending on which motion is greater then finish moving along the remaining axis for that tick. This method is well established to simulate entity motion in a way that is computationally efficient as it allows collision checks to be done independently for each face of an entities hitbox.
Unfortunately however, the collisions method is poorly designed to utilise the movement method for efficient collision calculations. As it will start by collecting block collision boxes from the volume projected by the motion axes, then iterate through this volume for each block, checking whether the hitbox of the entity intersects the block faces in each axis. Which is absurd because for fast moving entities the volume projected by the motion axes can contain millions of blocks that have nothing to do with the motion axes. This results in the block collisions method scaling extremely poorly as the velocity of collisions increases.
To get an idea of how bad the scaling is, consider that a TnT entity with Motion:[1000.0, 100.0, 1000.0] would check 100 million positions for collisions despite only realistically being able to collide with 8400 blocks in total. So that is pretty much 100 million calculations the game does for literally no reason but to waste energy.
The currently implemented method incorporates no mechanisms to discard redundant collision checks and free up computation for other more crucial tasks. Some effective measures to improve collisions would be to check the load state of chunks intersecting the motion axes in the order they are processed. So for example an entity with Motion:[800.0,100.0,900.0] would check the load state of chunks Z+900 then X+800 from the entities current position and discard collision checks for unloaded chunks. Then the method could check whether the subchunks intersecting the lines Y+100, Z+900, X+800 contain blocks other than air and skip collision checks for subchunks containing air. Then finally the method would iterate over individual block collisions along the motion axes where the entity actually moves.
Linked issues
Comments 30
The crash takes a while because of the extreme lag slowing down the charging process, it should normally take 90s but ran at around 4 TPS for me so it took about 8 minutes. This is a relatively small cannon btw, normally these types of cannon use a lot more TnT.
You should probably make an additional report for the explosion thing and make this about the collision check only. It's different from the report ampolive linked, so it should be its own issue.
A report specifically about the explosion calculations would be made redundant by MC-238249 which goes into a lot more detail on that.
That report is about the origin position being checked for eyery ray, while your report mentions another optimization potential (combining multiple explosions on the same tick and same position into 1 explosion).
I definitely will say this should get fixed since it been an issue for a long time in the game that causes a lot of lag from ram and cpu usage and just overwhelms the game with data checks.
Only 1203 votes so far, make sure you also tell people to make accounts if you cared enough to vote here : /
I wasn't able to reproduce a crash, but I was able to reproduce extreme server-side lag, to the point where the game stalled for several minutes.