This issue is very similar to MCPE-57637, except that it only applies to hoppers in a very specific configuration. It also appears to be at least partly a hopper problem and not just a minecart with hopper problem.
The attached world contains the following demo build:
[media][media]
Steps to reproduce:
Open the attached demo world.
Place a few stacks of any item in the hopper.
Ensure the hopper minecart is empty.
Press the button to send the hopper minecart to the other end of the track.
Look at the hopper minecart's inventory.
Expected results;
The inventory is empty.
Actual results:
The inventory contains one item for each time it passed the hopper.
Notes:
The problematic behavior depends on all of the following being true:
The hopper's output funnel must be pointed downward. If it's pointed to the side, no item is transferred.
The hopper must be enabled (deactivated, i.e. it must not be powered directly by a redstone component nor adjacent to a powered solid block). Activating the hopper disables its ability to push an item out, which makes it seem like that's a crucial element of what's happening, and that would suggest that it's at least partly a hopper bug.
Either there must not be a container-type block below the hopper, or the container must not be able to accept the items being pushed by the hopper (no empty slots and no partial stacks of the same item type).
The hopper minecart must roll through a curve adjacent to but one block below the hopper. If the track is straight or on the same level as the hopper, no item is transferred.
Note that a hopper pointing downward to another hopper (or hopper minecart, as in this case) is the special configuration that transfers items between them at double the normal speed. I tend to think of this is the upper hopper pushing one item and the lower hopper or minecart pulling one item, both in the same redstone tick. That's why this seems like this could be partly a hopper bug.
I believe what's happening is that as the hopper minecart rolls through the curve, its collision box intersects the block space below the hopper, so it tries to pull items from the hopper just as it should if it were moving below it on a straight track. However, this is relatively recent behavior, and it's also puzzling because in configurations such as this there is usually a second hopper below the first. So the minecart should be crashing into the lower hopper. yet there is no indication of interference. The demo world is a much simplified version of my auto-smelter, which worked properly when I built it last year. It no longer works exactly right because when the hopper minecart, which is loading the items to be smelted into furnaces, is making its final trip or two, its inventory usually has an empty slot that allows it to accept bamboo from the fuel hopper as it passes by. The bamboo then winds up in the input slots of some of the furnaces. All the desired items have been smelted by the time this happens, so the machine is still usable, but it's inconvenient to have to remove the unsmeltable bamboo from the input slot of each furnace after the job is done.
Linked issues
relates to
Attachments
Comments
GoldenHelmet
Auldrick
I am able to get the problem to occur with a hopper or barrel under the "misbehaving" hopper. The reason it didn't work for you is probably that the hopper was successfully pushing items into the lower hopper or barrel. While it's doing that, it doesn't push anything into a minecart.
I see now that the gist of this problem is that there are several behavioral oddities around the interaction between minecarts with hoppers and hoppers diagonally above them. I'm not sure whether these behaviors are intended or not, and I'm unable to test them in Java. The oddities are:
A minecart with hopper or minecart with chest that follows a curved rail will briefly intersect the block space inside that curve while it is turning. While it is intersecting the space, a hopper above the space is able to push items into the minecart. However, for the hopper minecart the minecart is not able to pull items from the hopper, which it can do if the rail runs directly through the block space below the hopper. This directional non-equivalence of item transferability seems inconsistent and unintuitive (though I accept that it may very well be necessary, to prevent bigger problems).
The hopper in this configuration will only push items into the minecart if it has items that it cannot push into a container beneath it, either because there is no container there or because it has no empty slots and no partial stacks of the type of item being pushed. In other words, the hopper will not concurrently push items into a container and a hopper minecart or chest minecart, but instead will fill first the container, then the minecart if it's still available. This is also unintuitive: I can think of no other mechanic that serializes item paths when multiple paths are present.
These unintuitive behaviors make me wonder whether they're intended, but I'm not able to test them in Java and don't know another way to determine whether there is a bug here. So I'm leaving this ticket open for the present time, in came someone wants to test it in Java or has additional input.
GoldenHelmet
I can think of no other mechanic that serializes item paths when multiple paths are present.
Actually this is how hoppers and hopper-minecarts work when checking for items to pull or collect as well. While testing MCPE-38963 I found that hoppers and hopper minecarts run 3 separate checks of the chunk data in series, always in the same order. They look in turn for
blocks with inventory
hopper/chest-minecarts
collectible items
Prior to 1.16 they would stop checking at the first thing they found in range. This had a few notable consequences:
A block with inventory above a hopper/hopper-MC would "lock" it from sucking in free-floating items or items in a hopper/chest-MC. For example, items pushed up against the side of a chest by a water stream could not be collected into a hopper below the chest.
If there were multiple hopper/chest-minecarts above a hopper, then the hopper would only be able to pull from the first of those hopper/chest-minecarts in the chunk entity list, even if that one was empty and others in the space contained items. This was reported as a bug in MCPE-54244.
If there were multiple free-floating items above a hopper/hopper-MC (or in the same block as a hopper-MC), then the hopper/hopper-MC would only be able to collect the first of those items in the chunk entity list, even if it already contained partial stacks of the other items. In other words, an item that did not match any of the partial stacks in a hopper/hopper-MC would "lock" the hopper/hopper-MC from collecting matching items. This was reported as a bug in MCPE-38963.
In 1.16 MCPE-54244 was fixed, but the fix eliminated both (1) and (2). The elimination of (1) is reported as a bug in MCPE-80555, and it was discovered in connection with MCPE-68912. The behavior reported in the present ticket is analogous, the difference being that it concerns the pushing function of hoppers rather than pulling.
In other words, just like
hoppers pulling from an hopper/chest-MC that crosses the block above them on a slanted track (MCPE-68912) is a behavior that always existed but was not discovered and did not have much impact until the fix to MCPE-54244 reversed (1) and created the behavior reported in MCPE-80555,
so
hoppers pushing into a hopper/chest-MC that crosses the block under them on a curved track is a behavior always existed but was not discovered and did not have much impact until the fix to MCPE-54244 enabled the hopper to push into the hopper/chest-MC even if there was a block with inventory below the hopper.
Both the errant pulling reported in MCPE-68912 and the errant pushing reported in the present ticket are blocked when the hopper is actively transferring to/from the block with inventory.
Neither of these issues actually relates to MCPE-57637 at all, since the issue there is the incorrect spatial range of the hopper-minecart's search for entities. Here and in MCPE-68912 the issue is how hoppers handle hopper/chest-minecart collision boxes that partially cross their correct search range (something that was unnoticed until (1) above was reversed).
(For the record, (3) was not impacted by the fix to MCPE-54244, so it still occurs.)
GoldenHelmet
I have re-thought this report and the companion report on hopper pulling (MCPE-68912) and want to recommend that they be closed Works As Intended or Won't Fix. Both behaviors have always been in the game and both are actually important for advanced storage tech. The only reason they were reported as bugs is because MCPE-80555 caused existing builds to behave differently. Now that MCPE-80555 has been fixed in beta 1.16.100.51 the behavior of hoppers toward hopper/chest-minecarts should once again be controllable in traditional ways. (I cannot test the present report in the beta but I expect that the fix to MCPE-80555 affects both pushing and pulling.)
The underlying cause of the issue reported here is that hoppers push into hopper/chest-minecarts based on the hitbox of the hopper/chest-minecart overlapping the hopper's pushing range. This behavior is the basis for builds that position hopper/chest-minecarts under 2 or 4 hoppers in order to fill the hopper/chest-minecarts quickly. If this behavior were removed from the game it could break advance item transport and storage builds. See the picture below.
[media]
migrated
Affects 1.16.201
[Mojang] Mega_Spud (Jay)
Thank you for your report!
However, this issue has been closed as Won't Fix.
If you'd like to post a suggestion or give further feedback, please visit the Minecraft Feedback Site or choose a link below.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki
This also occurs if you replace the hopper-minecart with a chest-minecart. It does not occur if you replace the hopper with a barrel. So it is clearly the hopper pushing, not the hopper-minecart pulling.
This could be related to the fix to MCPE-47541, if that included an adjustment to the hopper’s push range or push detection function to accommodate its new hitbox and collision box. Or, it could be related to the fix to the push-side of MCPE-54244.
Update: I was not able to get the errant transfer to occur after placing either a hopper or barrel under the misbehaving hopper. I think that means it is unlikely to be related to MCPE-54244. Edit: actually this can occur if the hopper is not able to push items into the block with inventory underneath; see Auldrick's comment below.
Since It’s due to the hitbox of the hopper-minecart overlapping the range of the hopper, this issue is more related to MCPE-68912 than it is to MCPE-57637