Items get sucked by hoppers instantly when pushed by pistons / thrown

post the map. otherwise every mech is gonna read what kevin said and say "oh yeah..."

edit: okay... saw the new video... weird. i had a inconsistent bug a while ago where my hopper wouldnt pic up stuff right on top of it due to, what im gonna geuss was, ingame/update lag. i retested your build from what i could see from the pic/vids. my funnels pick up the broken shulker. duno what to say now.

Ok dcn. I created a map which shows it clearly. But you must be in v1.12.0.4 Beta to play it.

When you enter the world, just turn of the lever and see what's happen.

http://www.mediafire.com/file/9p4v5q9xsf5iz44/My+World.mcworld

i cant test beta on my plat. it does seem like something is going on, but a beta tester will have to check out your save.

Okay, just came back here. I'll test it, wait a bit.

Could reproduce on the beta version. I have a theory, although I wasn't able to confirm. I think the hopper is only picking up items that are in the block above, not inside of them. It's just a theory, and it needs to be fixed anyway.

What if the redstone torch came on before the shulker box had the chance to enter?

EDIT - never mind 😞

CJC - in the video there aren't redstone torches..........

According to the Minecraft wiki, it is an intended feature. Hoppers with containers above them will not pick up items. The game doesn't even check for items to prevent lag. 

Ben R - ok, that's make sense but there are still issues here. Maybe I didn't thought of a good name for this issue. The problem here is that the items somehow get stuck between the hoppers when pushed by pistons - this is the main problem and you can see this in that video: 

The way pistons push the items is wrong. In that case the items should fall down instead of land between the hoppers. Am I right?

I might change the title to: Items get stuck inside containers when pushed by pistons.

And I'm sure this problem that I mentioned is not an intended feature.

That is what I meant in this report.

This issue related to https://bugs.mojang.com/browse/MCPE-33715 and https://bugs.mojang.com/browse/MCPE-49631 howerver, it's a seperate issue.

This has been reported to the developers, who will determine whether it's a bug or works as intended. However, I don't see any bug here. As Ben said, the hopper isn't supposed to suck items since it has a container (another hopper) above it. So in effect this is the same configuration as if you had a bottom slab instead of the lower hopper. When the piston breaks the shulker box, it tries to squeeze it into a glass block. A floating item that finds itself inside a solid block will look for an empty space in an adjacent block to move to. The hopper's collision box has a depression in the middle of the top, which creates an empty space above it just like a bottom slab's collision box leaves an empty space above it. The item is in that space, not inside the hopper, and it's resting on the surface of the hopper's collision box, that is, the inside of the funnel. By my understanding, it does what I would expect given this configuration.

Could not reproduce in 1.13. Items seem to avoid getting stuck inside the hopper hitbox, which is nice🙂 Needs more testing in various ways before this could be marked as resolved

Because the topic is related to the hopper's hitbox, can the top of the hitbox be flattened? Even though a hopper is funnel-like, graphically, it serves no purpose to have a funnel-like hitbox.

If the hitbox were flattened, water streams could be used to move items over hoppers for item sorters, as they can be used in Java, as in this video by Wattles: https://youtu.be/ruw1elYIQo4 As it is now, items fall into the hitbox of a locked hopper, waiting to despawn. Also, more advanced redstone tech using shulkers could be designed. As it stands, shulkers fall into the black hole that is the meaningless hitbox of a locked hopper, instead of being pushed to the side where an open hopper awaits ( good luck recreating this beautiful design by Cass: https://youtu.be/m47ZxtCGRDI ).

Basically, the hopper is a mechanical part of the game, the hitbox should be based on the hopper's mechanical function, not on it's graphical appearance. Can someone talk to the devs about this? Is it intended to have a hitbox that actually breaks functionality, simply because a hopper looks like a funnel?

@unknown: At the moment, we're waiting for the developers to decide whether this is a bug or working as intended. If they conclude that it's a bug, they might decide to fix it in a couple of different ways, but will most likely try to make it work the same way it works on Java.

If they decide it's working as intended, what you're asking for becomes a request for a feature change. That's not something we handle on the bug tracker. To request a feature change, you would need to submit it on the Feedback site. You could actually do that at any time, though you might prefer to wait and see whether they fix this issue to implement Java parity, since if they do your feature request would just be redundant.

This report has been changed since it was originally created.

The original issue reported (May 2019) was that shulker boxes broken by pistons would sometimes get stuck in-between vertically stacked hoppers. The shulker was placed next to a hopper that had another hopper below it, and the piston would push the shulker toward the hoppers. The reason the shulker would get stuck is that when it was pushed against the motion-blocking side of the upper hopper, it would look in random directions for an open space to move to, and sometimes it would find the open space of the lower hopper's funnel and rest there. Based solely on this information, I would say this was working as intended based on MCPE-38628, since it is intended that hoppers have a non-full hitbox that items can get stuck in.

However, the expected behavior was later (August 2019) explained to be that items pushed against a vertical hopper stack by a piston should fall out to the side. So the issue was clarified to be about how items pushed by a piston should behave when pushed into a full side collision box.

More recently, the summary and description was changed again (May 2020) to report that items pushed by pistons into a vertical hopper stack can get collected by the hoppers. Now on the surface, based just on the summary, "items get sucked instantly by hoppers," this issue is working as intended per MCPE-64628. However, part of the expected behavior described is that a container on top of a hopper should prevent it from collecting. That used to be the case, but it was changed as a side effect of the fix to MCPE-54244. We are tracking that issue separately at MCPE-80555.

From my survey of the history of this ticket, I believe it should be revised again to focus on the behavior of items pushed by pistons, and not on hopper behavior. The various hopper behaviors are tracked elsewhere.

Right. I changed the summary and the tite. And are you sure the bug I describe is MCPE-80555? If so, update the status of this bug to resolved, I trust you this is the specific issue that causing this bug.

@@unknown the hoppers collecting when they have a container on top is MCPE-80555, but that is not what you originally reported on this ticket.

The piston pushing items through the side of hoppers is similar to MCPE-46746. However, I've done some more testing and I think MCPE-46746 is actually fixed.

In testing that one I also figured out why pistons can push items through the side of hoppers: hoppers do not have a full side collision box. Instead, the collision box of hoppers actually matches their appearance. I do not know if it was always this way, or if this was changed in 1.16 when the hitbox was changed to fix MCPE-47541. However, I think it is probably working as intended.

There is still a bug though with the wireframe around the hopper when outline selection is turned on, which is tracked at MCPE-59928.