Fix bugs in collision detection when itemframe is outside the worldborder#9806
Fix bugs in collision detection when itemframe is outside the worldborder#9806Hydrostic wants to merge 1 commit into
Conversation
|
I wonder if we can somehow pass if the entity noCollision should use the My brain is absolutely friend right now tho, so I sadly cannot look deeper into that. |
|
Closing this pr since this is a hack not a fix, the proper way is to do what vanilla do instead of what the new system do. There's more issue with the world border collision. The item frame do indeed drop when near the border (<2*|boxSize|) but not when far outside of the border and that's the issue. Essentially in vanilla an entity collide with a border without collide epsilon and when the entity is near the border and inside (with a margin) but not far outside then the two voxel shape intersection are checked. |
If the border is set to expand automatically e.g. /worldborder add 10000 10,then will the moving border cause item frame to disappear? |
|
Yes, this might happen if the timing is right. For example if the border is slow enough that the item frame check its state (that happens each 100 ticks by default) and the condition are met. |
repair for #9805
in
net.minecraft.world.entity.decoration.ItemFrame#survivesthe itemframe will detect whether itself collides with other items by calling
noCollision, but innet.minecraft.world.level.Level#noCollision(Entity, AABB), which has been modified by paper, hasn't consider the situation that itemframe is outside the world border and directly call the funcgetCollisionsForBlocksOrWorldBorder, which return false when entity is outside the world borderso I change the patch to
to prevent item frame from killed