mojira.dev
MCPE-55824

Hoppers don't pick up items above non full blocks > 5/8 block tall

Updated description by @unknown
The bug: hoppers do not search the entire block space above themselves for items to collect, as they do on Java. Instead, they search only + 0.625 Y (5/8 block or 10 pixels) above themselves.

Steps to reproduce

  1. Put a pointed dripstone, enchanting table, or horizontal grindstone on top of a hopper.

  2. Drop an item on top.

    [media]

Expected result

The hopper collects the item.

Observed result

The hopper does not collect the item.

Note: The original report here focused on hoppers not collecting items from above soul sand, dirt path, and farmland blocks, as they do on Java. However, those blocks (along with honey blocks) have full-height collision in Bedrock (MCPE-12109, MCPE-87458) so they cannot be used to show the bug in the hopper collection range.


Hoppers will not pick up items through soul sand, path, and farmland blocks.

Related issues

Attachments

Comments

migrated
[media][media]
Auldrick

Confirmed in 1.13.1 on Windows 10.

I have attached a demo world MCPE-55824.mcworld. I suspect that the reason it works this way is that when an item entity is floating above one of these blocks, its Y coordinate is 1.1 blocks above the hopper, which would put it out of range. For an item entity floating above a bottom slab, on the other hand, its Y coordinate is 0.6 blocks above the hopper, which is in range so the hopper sucks it in.

migrated

Could we potentially see this as a feature? It would match Java, and also be super useful, as well as make sense. When a player stands on soul sand, they are lower than a full block.

Auldrick

There's a difference between an item entity, which floats above the surface, and other kinds of entities that rest on the surface, and that might be the issue here. I don't have Java so I can't compare the behavior, but if Java hoppers suck item entities floating on these blocks, I believe the developers will treat this as a parity bug and fix it.

I find it suspicious that item entities have the same Y coordinate for all three of these blocks as they do for a full-size solid block. I know the hit boxes of these blocks are < 1 block tall, and if the item entity sinks to the hit box of a bottom slab or pressure plate (which it does) then why wouldn't it do the same for these? Maybe they did something weird like hard code the item entity Y calculation instead of doing collision detection, who knows?

migrated

Confirmed on 1.14.0. The following non-cubic solid blocks let hoppers suck in item entities on them:

  • Bottom-half slabs

  • Lower trapdoors

  • Carpets

But these don't:

  • Farmland

  • Soul Sand

  • Grass Path

GoldenHelmet

Farmland and grass path blocks actually have full-block collision boxes, so it's no mystery why hoppers underneath don't suck items floating on top of them. See MCPE-12109.

Soulsand was given a full collision box in 1.16. See MCPE-87458. This was probably done in 1.16.0.63 beta, based on the changelog statement:

  • Mobs can now pathfind on Soul Sand blocks

migrated

They cant pick up items from over honey blocks

migrated

Something similar applies to honey blocks. Their top surface is slightly higher up so that mobs can pathfind on them.

migrated

Yes this affects honey blocks too (on 1.16.40). Most likely MCPE-12109 is the cause of this, as it is natural that hopper can't pick up items through blocks which have (wrongly) a full hitbox.

The horizontal hitbox of Honey is smaller than the full box (correctly), but the vertical one is as tall as Stone.

GoldenHelmet

Hoppers do not collect items from above anything higher than a stonecutter. In other words, they search only within the lower 5/8 of the block space above them for items. (Items on a stonecutter sit at +0.5625 and get collected by hoppers, while items on an enchanting table sit at +0.75 and do not get collected by hoppers.) This is inconsistent with the fact that hoppers pull from hopper/chest-minecarts sitting on top of bocks like enchanting tables and horizontal grindstones. I can't think of a reason why the hopper's item collection range should be restricted to less than a full block while their pulling range is not.

migrated

Affects 1.16.201

kmpoppe

This still affects 1.16.210

migrated

Affects 1.17.41

migrated

In MCPE-155479, it had describe the difference between java and bedrock edition with a detail analysis, which the difference feature is more or less causing players unable to manipulate most hopper-related contraption that collect item entities.

GoldenHelmet

Comment updated 8/24/22 with new analysis based more precise test results from teleporting items to fractional coordinate positions on every tick.

From the hopper's exact Y coordinate (its bottom edge) , it collects items whose positions are +0.375 Y < POS < +1.625 Y, or in other words within 5/8 of a block (10 pixels) above or below its top. Presumably, the search range of the hopper starts below the top of the hopper instead of at the top (at +1 Y) so that it can collect items that sit inside the funnel. I have also checked Java for comparison, and in Java hoppers can also pick up items at +0.375 Y from the bottom of the hopper (-0.625 Y or 5/8 block below the top) of the hopper.

It may be that the search range actually starts at +0.625 and it grabs items that sit at > +0.375 because their collision box extends upward by 0.25 and, therefore, into the search range. If that is the case then the full search range in Bedrock is actually 1 block. That sure looks like a simple mistake of thinking only of the space above the hopper and forgetting that collection starts deep inside its funnel. The range ought to be 1.375 blocks if it does start at +0.625, or if I am wrong about the impact of items' collision box height and the search starts at +0.375, then the range ought to be 1.625 blocks.

migrated

Affects 1.19.40.21.

Since the collision height of mud and soul sand has been lowered from 1.19.40.21, this has become a very urgent issue for technology users(even for users who just make sugar cane or bamboo farms!).

migrated

Affects 1.19.31

migrated

(Unassigned)

140972

Confirmed

Multiple

java-parity

1.19.60.22 Preview, 1.19.60.20 Preview, 1.19.50.22 Preview, 1.19.50.21 Preview, 1.18.32, ..., 1.19.21 Hotfix, 1.19.31 Hotfix, 1.19.40, 1.19.50, 1.19.51

1.19.70.20 Preview, 1.19.70

Retrieved