MisterKartoffel
- MisterKartoffel
- JIRAUSER700424
- America/Sao_Paulo
- Yes
- No
MC-240054
Low
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.
Edit: added world download for easier testing and showing hitbox limitations.
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.
Edit: added world download for easier testing and showing hitbox limitations.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).
On varied setups of item entity velocity, sometimes only one hopper of a pair will pick up an item. This behavior is unpredictable.
Steps to Reproduce:
- Step 1: Download attached world;
- Step 2: Test the presented setups accordingly;
- Step 3: Note which items were collected by their respective item filters.
Observed Results:
Sometimes, no hopper pair picks up their respective filtered items. This may be caused by the item entity not ticking above the hopper and is NOT the object of this bug report.
Other times, only ONE of the hoppers in a pair picks up their respective filtered items (described in world download as "break parity", see video 1). Furthermore, as can be seen in the various setups presented, further away hopper pairs may or may not work as intended, which discards the possibility of item entity misalignment. This IS the object of this bug report.
Expected Results:
Either:
- Both hoppers in a pair collect their filtered items; or
- Neither hoppers in a pair collect their filtered items, possibly due to, as discussed in Observed Results, item entities not ticking above hoppers.
Additional information:
There were, in testing, other setups of water streams with different parity break points. However, they are redundant for the purposes of this bug report. The world download for all tested setups can be attached if requested.
I disagree. Containing / stopping a fluid is not the same as redirecting its flow direction. As the pictures show, an unwaterlogged sign also stops fluids as intended, but it doesn't redirect its flow. The same behavior difference can be seen when using live and dead coral fans in the same space.
Elytra changes were reverted in 21w37a, therefore it's intended behavior.
May relate to MC-1133
My reasoning is that, as you know, item entities 1 pixel on top of ice are not affected by ice, and
MC-1133is related toMC-163979, which affected all entities.Can confirm as of 1.19.4. This happens not only with barrels, but with all inventory blocks that should disable a hopper's search for item entities, irrespective of their physical orientation, including:
From the fact item entities are not collected by hoppers covered by the above blocks even when the item entity is clipped inside those blocks, or resting inside the composter walls, it feels to me like all 5 hopper collection bounding box checks are properly disabled, except for when the item entity directly collides with the hopper bowl.
To people pointing to 24w06a changelog, it's not that simple. It's pretty reasonable that a change like that would have unintended side-effects like this one. Whether you want to call it a bug or something else is a purely semantic argument. But it's clear (given Fixed) that the dev team agreed this turned out for the worse. Also, on a tangent, the entire working of a nest, with item spawning in the block center, feels particularly prone to having issues like these show up. If that's not changed, an exception is the next best thing.