Savvvage_

This is now also a paritly issue, because of this: MCPE-225461

can replicate 25w32a

*i meant 25w32a

Can replicate in 25w31a.
I used the following setup:

A cow leashed to a fence (the cow and the fence are in different chunks). Unload and load the chunks multiple times by going in and out of spectator mode (the gamerule spectatorGenerateChunks is set to false).

can replicate in 25w32a

oops, accidentlly sent the previous comment before formatting it propperly, only first and second items of the list are supposed to be there, but the point still stands, specifically the one issues described int this report should be technically fixed (even tho i cant verify it cus it is masked by other crashes simmilar)

So, the source of the issue (falldamage raycast) seems to have been fixed in 25w32a.
However, the crash itself is still present because of the following:

1. raycast in MC-295841
   (which, as of now, is actually not fixed, as per last comment)

2. path search in the pathfinding of fast moving living entities also causes crashes.

4. Hower as stated above, thats not not the focus of this ticket, so it can be closed now.

As of 25w32a:

• The interactive collision check path still evaluates the corners of the corkscrew, which it should not do for the reasons outlined in the report above.

• The interactive collision path sometimes fails to visit the end position of the movement.

• The interactive collision path uses a movement vector that is not adjusted for block face collisions, causing it to differ from the actual direction of the entity's movement.

• The Entity.Movement#axisIndependant field appears to be misspelled in the official Mojang mappings. It should be “axisIndependent, although based on the implementation, “axisDependent” sounds more appropriate.

The replication setup provided in this report still behaves almost identically to how it did in 25w31a and earlier. This suggests the fix may not have been fully verified before the issue was marked as resolved.

This would be the 11th time we (TMC) have to re-report issues related to interactive collisions, and it’s becoming increasingly frustrating - for us, and likely for you as well. We would be happy to provide a working fix to help ensure the issue is resolved correctly and prevent further back-and-forth. If you’re open to accepting a fix from our side, please let us know by replying to this comment.

Not fixed

This report was created specifically because @Shugoh asked me to make it in the comments under MC-299681

It would be greatly appreciated if the validity of such issues was resolved internally before asking users to report them.
Writing such a text wall takes a lot of time and effort, and it is very discouraging to see that effort dismissed - especially when the report was made at the request of a developer. It's hard to view this outcome as either collaborative or productive.

Can replicate

First of all, this isn't necessarily a bug, its just a collision delta, and yes it is commonly used in redstone contraptions for all sorts of entity conveyors and even in compact piston doors (the ones with cart spam).

But you are right that it would be nice if entities' random momentum wasn't able to accidentlly reach such problematic values.
Iirc recently the angle distribution for item prime momentum was in fact changed from gaussian to triangle one, but apparently this is not enough. Just blacklisting certain values as suggested in comment above wont work, because there are too many of them (think of all reasonably possible entity falling paths, which lead to accidental float alignment), however, such a distribution might be achievable. If the devs are willing to change it, then im willing to find a distribution which will never reach such problematic values. Please contact me if interested.

About the first suggested fix from my previous comment:
calling resetEmptyTime() after the game is unfrozen is a bad idea, instead making the game not inrement the emptyTime of the levels while the game is frozen makes more sense.
Calling the resetEmptyTime() after pearl is added to the dimension upon player loggin on and after entities teleport through end gateways still applies.

Code analysis:

When in a dimension there are no forceloaded chunks, no players, no active ender pearls and no entity entered that dimension through a portal for at least 300 gameticks, that dimension will stop processing the entities, block entities and the dragon fight in that dimension.
Obviously when the player logs of, their ender pearl disappears from the end dimension. When the player is logged off, after 300 gameticks, the End dimension will stop processing entities for the reason mentioned above. When the player logs back on, the ender pearl is re-created and placed in the End, but as the End no longer ticks entities, the pearl wont tick, thus its not able to place a chunkloading ticket, which makes the pearl unload.

The check is located in the ServerLevel.java in the tick() method. to be more precisely, here:

Please note, that this is not the only consequence of dimensions stopping processing entities and block entities. This issue also manifests in end gateway based chunkloaders (they break if players leave the End) and a couple more contrpations. Here i explain the issue in much more detail: https://youtu.be/lFSfr_KlwzE?si=kQD9YZ522KtoWtjt

Moreover, when the game is frozen with /tick freeze command, the dimension unloading timer is still running, this leads to nether portal based chunkloaders breaking after player unfreezes the game. (cus entity which is supposed to cycle between dimensions stops ticking, cus the dimension that it is in stops tickin entities) This makes the /tick freeze command intrusive (aka breaks contraptions).

I'd Suggest 2 possible fixes:

1. Making the game call level.resetEmptyTime() each time the player’s pearls are added to the world, each time the game is unfrozen and each time an entity is teleported through an end gateway.

2. Removing the behavior of dimensions stopping processing of entities and block entities entirely.

can confirm in 1.21.5

Why is the category of the report marked as “Commands, Entities“? The issue isnt related to commands in any way. . .
Also it breaks a bunch of redstone contraptions

can confirm the issue in 1.21.5 and 25w19a.
i also tested the suggested fix, it fixes the issue correctly. As far as i can tell, the suggested fix doesnt break any of the archived/otherwise published redstone contraptions.

Well, you can call it “related“, technically both issues just happen to occur in roughly the same conditions, but for completely different reasons.

@Joel Danter no, as explained in this report, the crash happens due to chunks loading, not due to the issue described in the report you linked (the collision face collection being O(n^3)), even tho the issue you linked, can in some cases cause the server to crash too, its not nearly as severe as whats described above.