Hopper minecarts pull items from other hopper/chest-minecarts which are diagonally up to the south or east

Confirmed in 1.14.30 exactly as the reporter describes. Hopper minecarts will pull from other hopper minecarts that are 1 block above to the south or east when there is no block with an inventory above the pulling hopper minecart.

With further testing after reviewing duplicate reports I have determined:

• Hopper minecarts also pull from minecarts with chest above them to the south or east.

• Hopper minecarts also pull from other hopper minecarts and minecarts with chest 2 blocks above them to the south or east.

To sum up, hopper minecarts pull from other hopper minecarts and minecarts with chest that are relatively positioned (+1 X OR +1Z) AND (+1Y OR +2Y).

Note that a duplicate of this report, MCPE-61362, points out that

• this behavior does not occur on Java, and

• this behavior does not occur when blocks with inventory are placed in the same locations diagonally above hopper minecarts, or when hopper minecarts or minecarts with chest are placed diagonally above hopper blocks.

A moderator in outside discussion raised the question whether pulling from an inventory at +2 Y is intended at all. So, I have uploaded a video showing a hopper minecart pulling from a minecart with chest 2 blocks directly above it (+0 X, +2 Y, +0 Z) to confirm that it does not happen only when the entity with inventory is offset in the X or Z direction.

Just saw this issue on my creative world today. Doesn't have inthe issue in the one axis on my super smelter, then I added a corner, and suddenly getting spillage from the one Hopper minecart to the other. I'm on the Xbox One and have the most recent update. I would greatly appreciate a fix for this one. Thanks!

1.16.0.57 also

Does the fix to minecart hitboxes in 1.16.0.57 (MCPE-59302) not impact this bug?

Nope, it's unrelated. This bug is in the the hopper-minecart search function.

Now, the fix for MCPE-54244 in 1.15.0.53 does impact this bug, because that fix allows hoppers and hopper-minecarts to ignore blocks with inventory above them and continue searching through hopper/chest-minecarts above and/or to the S or E side of those blocks. So now this bug is worse. (See MCPE-80555.)

also the latest 1.16.0.66

Affects 1.16.0.67

I am Currently having this issue where a minecart hopper is "steeling" from an adjacent hopper one block above: attached is you tube video link: https://youtu.be/mhNsP4oifu4

It was discovered whilst following a tutorial for a Bedrock super smelter and occurred both before and after the 1.16.1 hotfix for player skins (unrelated but thanks for that fix)

 this is on PC Bedrock

my apology's for having created an unnecessary thread elsewhere 

Affect 1.16.1 as well. 

Affects 1.16.20.54 Beta

the hopper is hopping items too fast 

affects 1.16.20

In an earlier comment I mentioned that hopper minecarts can pull from hopper/chest minecarts 2 blocks directly above (+0 X, +2 Y, + 0 Z). That behavior was not included in the original report here, but the question was raised whether it might also be unintentional and therefore related to this bug. After giving it some thought I want to urge that it be left alone in the fix to this bug.

Pulling from +2 Y straight above has not been reported to have any negative impact and it does not introduce any inconsistency. You could say it's inconsistent with not pulling from container blocks at +2 Y, however, it is consistent with pulling item entities from +2 Y. It can only be consistent with one or the other. Leaving it as-is is surely the simplest option (in terms of recoding). More importantly, hopper minecarts pulling from hopper/chest minecarts at +2 Y opens up design posssibilities, including the following.

Currently you can make a fast item sorting filter by placing, from the bottom up, hopper + activator rail w/ hopper minecart + glass/upper-slab + detector rail w/ hopper minecart + solid block (especially ice). Behind this column a comparator reads the minecart on the detector rail, and sends a signal to a block that inverts a torch that powers the activator rail. This setup allows items to be sorted from on top of the ice (possibly from a water stream) much more quickly than a filter made with hoppers, so it can be useful for bulk storage. But using hopper minecarts in a filter in this way depends on them sitting on the right kinds of rails, which would not be possible if they could not pull from other hopper minecarts at +2 Y. If you just fix the diagonal pulling, then it will be safely 1-wide tileable. Here is a picture:

Affects 1.16.200.53 Beta.

Dear Mod's and Dev's,

I hope you will read this as I did a number of experiments which collectively answer the question "why does it happend?".
So, we all know that this applies only to the container-carts.
Only towards X+1, Y+2, Z+1.

Issue 1: do hopper-carts scan larger area towards positive coordinates?

Answer: No, based on seen contraption made to deal with random droppers drop and uneven acceleration from water, also with hopper-cart placed on different Y levels observation confirms that scan range is not the case of an issue.

Issue 2: hitboxes of container chest overlapping?

Answer: Also no, different configurations also evidence that this bug does not care for the respective rail placement (e.g. bottom rail facing N-S and upper W-E)

Issue 3: What makes a hopper - hopper?

Answer: A short line of code "minecraft:item_hopper" - not really helpful but name itself doesn't specify if thats a hopper-cart or hopper block.

Note: Hopper to hopper-cart is in its essense a trade-off of ability to push items for the mobility and additional pulling range. Although, using shared "components_groups" theoretically, suggest that any changes targetted to hopper behaviour will result in same behaviour change to hopper-cart, right?

Issue 4: Did recent changes to hoppers had an impact on hopper-carts?

Part_A: Fix from ticket MCPE-80555 denies hoppers the ability to pull through blocks.

Part_A - Anwer: Fix intended to prevent hoppers from collecting free-floating items above blocks with inventory applied to Hopper-carts!

Part_B: Fix from ticket MCPE-54244 give hoppers bellow ability to scan entities above when they're stacked.

Part_B - Answer: The fix intended for Hoppers alone applied to Hopper-cart!

Issue 5: Will container-carts slammed into honey block be within pulling range of hopper underneath?

Note: If both container-carts have equal "reactive" range to "active" pulling by a hopper bellow would further suggest that:

Behaviour to manage distance form entities towards X+ and X- must've been mathematically corrected and then hard-coded into the game.
Since hopper-carts are basically a "buff" for hoppers range of pulling indicates these two are being treated same by the behaviour control code that controls things like hopper serializing (detailed description found in comments section of tickets MCPE-94293 and MCPE-68912)

Finally, with full confidence in my findings, I say that the reason this happens in game is because hopper-carts inherit behaviour controls that were intented only for hoppers.

@@unknown: thank you for contributing your testing results. Your discoveries #2-4 are correct. However, I think your conclusion, that this bug is due to hopper-carts using behavior intended for hoppers, is not correct. As best I understand your points, I think you have overlooked a couple of facts:

• For both hoppers and hopper carts, there are separate checks for hopper/chest-carts, and for item entities. That makes your "Issue 1" conclusion invalid.

• Hoppers and hopper-carts pull from hopper/chest-carts differently. That makes your "issue 5" test irrelevant to this bug.

Update: moved chart to a newer comment.

Affects 1.17

this bugs also didn't fixed in 1.18.12,

Affects 1.19.20

Affects 1.19.63. Built up a storage system for a mob grinder and had used a lot of hopper minecarts. The minecart would take items from the item filter to the south, and would basically break the entire system because it would drain one minecart (allowing it to take anything that passes over it, which is made even worse after the fix of MCPE-38963) and has the ability to break filters around it. It was very annoying to discover what I thought was a redstone issue was actually a 3 year old bug...

Affects 1.19.70 and the current betas/previews. This bug affects a multitude of possible storage systems and pretty much anything that uses hopper minecarts with precision.

With the fixing of MCPE-38963 we are now almost one step away from good item sorting systems. If this bug was fixed it would go a LONG way to achieve that goal. 

Still in 1.20.41

Still an issue.

1.20.81.01 still affected

The bug here is actually a +0.5 offset in each direction in the reference point that the check range for containers entities is based on. The breadth of the range is correct. This is just like MCPE-167490 but in the opposite direction. The likely origin of the bug is that the code for hopper minecarts pulling from container entities was copied from the code for hoppers pulling from container entities without accounting for the fact that the hopper' position is the lower north-west corner of a block space (integer coordinate), while the position of a hopper minecart on a rail is the center of a block space.

Based on this image, you can see why hopper minecarts pull from hopper/chest minecarts and chest boats up and to the southeast. You can also see why hopper minecarts cannot pull from a chest boat that is resting directly on top of them or a block next o them and hanging over. The boat collision box is less that 0.455 blocks high, so it can fit under the area where hopper minecarts check for storage entities.

Below is a full table of check ranges for hoppers and hopper minecarts based on my testing. The bugged offset range behind this bug is highlighted in red.