Disclaimer: all info, videos and images were captured in fabric. However, the behavior has been confirmed by myself and others to also happen identically in vanilla 1.17.1.
Bug in question shown in video 1.
In the setup shown by images 1 - 4, after the entity gains velocity as described in image 5 (data collected via /data get entity @e[type=item,limit=1,sort=nearest] Pos and Motion and CarpetMod's /tick freeze and step 1 commands), it 100% of the time collides with what I can only guess is the fence's hitbox.
But it shouldn't. By further examination via F3 + B, the item entity hitbox doesn't collide with the fence's, and if that were the case, the item entity would be expected to collide with both fences simultaneously and get stuck, instead of launching off the water stream.
Also should be added that the launching direction depends on the water flow direction:
North oriented streams (-east and -west) have their item entities launched north, and south oriented streams launch their item entities south (consistency tested via Save and Quit to Title).
As well as that, the item entity only gets deflected if the block located where the fences are (which are used to contain the water stream flow) has a hitbox of at least 4 blocks diagonally perpendicular to the stream's center diagonal, examples of this are fences and sea pickles, meanwhile this behavior isn't observed with glass panes, which has a diagonal hitbox of 2 pixels.
Images 6 and 7 show further testing, by showing setups in a northwest oriented stream with which the item entity doesn't get deflected at all (by having a sea pickle placed north of the stream's center diagonal, image 6) and with which it gets deflected north (as discussed previously in regards to stream orientation, pickle placed east of the stream's center diagonal, image 7).
By image 5 and Pythagoras' Theorem, the equivalent diagonal velocity a tick prior to collision was calculated as approximately 0.79898. I feel like there should be an investigation regarding whether the diagonal speed threshold of 0.8 has any effect on the item entity.
Added world download for easier testing and showing hitbox limitations.
Upon further testing, I determined that the same bug occurs using glass panes (which was previously stated to not happen). For that to be the case, the same setup needs to be expanded 79 blocks diagonally counting from the light blue stained glass block. The measured equivalent diagonal speed was calculated as approximately 0.91824 (note: even with "perfect" alignment, at this distance the item entity does end up misaligned enough for it to be noticeable via /data get entity @e[type=item,limit=1,sort=nearest] Pos on it's last shown digit, however the Motion argument doesn't show the same noticeable change, thus the abrupt change in the velocity vector shouldn't be expected).
Code Analysis by @unknown here
Linked issues
Attachments
Comments 3
This is actually how entity movement works. Entity movement works by straight lines, but not in diagonal directions. what this means is that the entity will travel like a L shape for example, instead of a \ shape.
Can confirm this affects 1.20.5. May relate to MC-240541
Can Confirm for 1.17.1
Code analysis: (yarn - 1.17.1)
Entity.java - adjustMovementForCollisions
The code which looks for block collisions does the following:
It takes the entity's current hitbox, then stretches it out by the velocity/motion that it currently has. It then calculates collision based on this new hitbox
I have attached 2 images, both showing the extended hitbox that is used