Minecarts outside of the EAR for "misc" entities do not fall immediately after a block moves out from under them

[Rektroth]

Expected behavior

A minecart should always fall immediately after a block is moved out from under them by a piston.

Observed/Actual behavior

Minecarts outside of the EAR for miscellaneous entities are delayed in falling after the block is moved. (The behavior is inconsistent.)

This causes issues in farming systems that are reliant on precise timing.

Steps/models to reproduce

video

Plugin and Datapack List

None.

Paper version

This server is running Paper version git-Paper-210 (MC: 1.19.2) (Implementing API version 1.19.2-R0.1-SNAPSHOT) (Git: 0bdf997)

Other

Is this technically a Spigot issue? And is this WAI since it's EAR behavior?

[petersv5]

I seem to remember that EAR grants immunity to moving entities. However, if the minecarts have not yet started moving maybe they are still subject to the EAR when the fence gate opens?

You can try by reducing corresponding activation distance in spigot.yml to a lower value so that the issue becomes more convenient to observe. I suspect it will be covered by the falling-block-height-nerf -> misc setting. This can allow you to see if the EAR is the culprit.

[Rektroth]

I have confirmed that it's the EAR. My original estimate of ~63 blocks was way off - it's actually 16 (which is the default EAR for minecarts). Video of the behavior witnessed from ~24 blocks away is included in the post. Boosting the EAR for "misc" all the way up to 128 fixes the behavior unless I move very far away.

When I first posted this issue, it was late and I was tired, so I simply put "~63" in the title because 63/64 blocks was the distance I could reproduce the issue consistently.

I've updated the title and post. But, since this is the EAR, would this be considered WAI? And wouldn't this be a Spigot issue? If so, I can simply boost the EAR for "misc" on my server up to something like 192, although I expect a slight performance hit from such a move.

Edit: Upon closer inspection of the video, the issue has nothing to do with them not moving on the rails - the minecarts aren't falling when they should be. I've updated the title and post again.

[petersv5]

Maybe removing/adding a block should trigger a short immunity for entities immediately around the block position? that should cover things such as pistons pushing/pulling blocks, endermen removing blocks, ice melting to water etc.

An alterantive is to only grant immunity when pistons move blocks. In that case the existing immunity in PistonMovingBlockEntity could be augmented to trigger immunity to not just pushed/pulled entities but also adjacent entities.

[petersv5]

Thinking about this, contraptions like the pez dispenser for miecarts typically rely on precise timing of the movement of a minecart after opening e.g. a fence gate. So giving some ticks to an entities when a block in the immediate surroundings change may be required. At least entities inside and immediately above the block.

[ryantheleach]

I'd go as far as saying that the entire chuck should be excluded from EAR (for a tick) whilst any hitbox changes have happened, otherwise stacked minecarts etc will be an issue, unless you somehow notify neighbouring entities recursively to check for collisions and resume them.

I havn't tested, but it's my gut feeling that even this may not be enough to have consistent behavior, as I think it depends on entity iteration order as to whether all entities will realize they need to start falling, and I'm not sure there's an elegant solution.

[petersv5]

We could try cascading. An entity that receives immunity looks for entities abutting it and grant a short immunity there as well, and so on. Immunity only needs to be for a few ticks as entities that start moving are immune (I think).

Maybe it is best to handle that in the entity move phase. If an entity moves it can check for abutting entities and grant them 1 tick immunity as well? We could even search only above, that may be enough.