The bug
Minecart with high motion values are not able to pick up entities. Instead they just collide with them and stop.
Note: Armor stands are a special case which is described in MC-90923.
How to reproduce
Place multiple powered rails behind each other and power them
Spawn for example a pig somewhere on the track
Place a minecart at least two blocks away from the pig on the track and push it towards the pig
Code analysis
Partwise by @unknown
Based on 1.12 decompiled using MCP 9.40 PRE 1
The problem is that the picking up of entities happens in the method net.minecraft.entity.item.EntityMinecart.onUpdate()
while the minecart is moved and stopped in the method net.minecraft.entity.Entity.moveEntity(MoverType, double, double, double)
. The onUpdate()
method already uses an extended bounding box to pick up entities but if it has a high motion this extending is not enough. Increasing it even further might cause other problems.
Maybe the method Entity.moveEntity
could call some methods for handling collision with entities.
Related issues
is duplicated by
relates to
Attachments
Comments


Came here to report the same; tested using various entities, results are the same. Worked in 15w44b, doesn't work in 15w45a.
Tested in Minecraft 15w45a on Windows 8.1 using Java 1.8.0_25 64 bit.

Still in 15w46a.

stopped working correctly in 15w45a I believe.. Still the same behavior in the latest snapshot 46a.
The Minecarts don't pick up villagers now at all but in 15w44a they still would pick up.

It is possible to pick up some entities but very difficult. You have to place the mob directly on the rail and place the minecart on that same rail. There are many other bugs with mincarts such as when riding minecarts they stop and crash the server shortly after. Anyways this is a frustrating bug I hope they fix it soon.

@Vincenzo Cilino Don't worry it'll get fixed! I can't imagine them going into the release in their current state. Minecarts are totally useless currently, as we can't use them to transport entities, and we can't use them to travel either (chunks don't load and we get stuck in them, forcing a relog or crashing).
Of course it's annoying but we have to be more patient with showstopper bugs like this. Cosmetic bugs get fixed quickly because they're easier to isolate, are more obvious, thus easier to fix.
But I agree minecarts should receive some sort of priority because they are REALLY broken. This one, MC-89915 & MC-64836 are the most important ones.

Still in 15w47a.
11 votes? I guess no one uses minecarts to transport mobs/animals. Is there any quicker/better way that I'm not aware of? 😃

@Early Reflections
Water can work, if you plan around it from the start, but I find minecarts much easier (and worth the resources)... when they work, anyway.
Believe me, I feel your pain; I had just finished building (& laying track for) a villager trading hall when the server I play on updated to 15w45a.

I have found a workaround.
(Snapshot 15w47c, might work for the others too)
It's not perfect, and requires some "trial and error", but eventually I managed to get my Villagers into minecarts.
The setup:
I have a villager breeder, where the output of new villagers is a water stream to temporary holding cell.
It is built above my made-up village (few doors + 1 villager, underground), and because of that, durring the night time, villagers are always trying to fight the current, jumping up and down, bumping into eachother and trying to make it back to village center (to hide from zombies).
The temporary holding cell represents of just one block drop, where the output water streem ends, so i can lay a track on it, without being washed away by the water (rail, ending into a solid block).
The rest is encased into glass blocks (for visibility), leaving 1x1 block space, where the rails are heading.
Adult villagers will be encased and will not suffer any damage, during transportation, but if you end up with baby villagers - they might escape thru the hole.
Anyhow..
The "broken mechanics":
1) It has to be night time, so villagers will be willing to "go home".
2) Reach with empty bucket and take out the last water streem (tricky, while villagers are on your way and want to trade)
3) When your Holding cell is empty, you can place the minecart on the rail.
4) Put back the water streem where it was.
The result:
Eventually, a few villagers are getting pushed along on top of the minecart.
When the first villagers "lands", it king of push it away (bump it).
Then he tries to jump back into the water streem, towards "home" and being pushed back down, or the next villager drops down.
When the minecart is about 33-50% (part) pushed into the next railed block, the villager, that is dropping down (again) kind of bump it again, but then it lands into it, when the minecart moves away. (glitch into it).
It doesn't always work. (Villagers are pushing the cart away too much and then you can't place it under them or push the cart in their direction (under them).
In that case, you need to restart that last water streem, until villagers are out of the way.
Notes:
I have used a switched off powered rail. It might work with normal rail as well (not tested). If it's powered, the first bumping villager will send it on it's way.
When a villager ends up successfully into a minecart, the next dropping (jumping) down villager gives him a boost of a few (5-7) blocks along a rail track.
Good luck!

Still in 15w50a.

This is your ticket, you can add affected versions yourself.

@redstonehelper
Oh! I didn't notice that. Thank you for pointing this out! 🙂
Confirmed for 16w04a

Gads, this bug is annoying.


Further, once you coerce them into a minecart, villagers are able to walk with full force and speed either direction along a rail path. This make transporting villagers by minecart a virtual impossibility. When trying to push them in a direction, they are able to push against me and move me in the exact opposite direction I am walking. It seems to me that if they are on wheels and I am not, I should be able to push them along the tracks.

@Jeffrey King
I know, the mobs controlling minecarts is MC-64836. And it won't get fixed for 1.9. It's very likely that this issue will make it into the release too.
We can discuss these issues on the reddit thread I created for that (my previous post). Unfortunately, no one cares about reddit, not even Mojang, the Devs, the mods, and the community.

confirming bug still exists in 1.9-pre1

Confirmed

This is still in 1.9-pre2. I can't get a minecart to pick up any entities from a level surface. The only way I could make it pick up entities is if it's moving down a slope at the time that it collides with the entity (even going up doesn't seem to work).
Here is a short video demonstrating this (and another minecart/mobs related issue), watch from about midway onwards: https://youtu.be/d0EQvFNb9bQ

Minecart can pick up mob when minecart is on curved rail. With straight rails it can't. 1.9 pre 2 is affected.

I've added a Reddit thread to discuss this issue, it's in the description. Mods keep saying we should discuss issues there but even them and the devs don't seem to be paying any attention to Reddit. It's a bit paradoxal. It reminds me of a South Park episode where one says "If you have any comments or suggestions to make, put them in writing and deposit them in the trash bin behind the building." 😃
We should all discuss this over there. I have issues accepting crippled minecarts in the upcoming release because, yes, this is going into the 1.9 release if the trend doesn't change.
@mods
I receive email notifications for all the issues I voted on and those that I'm watching. I receive nothing for this one, which I created.

@@unknown, make sure you are watching the report. Your settings may be configured to not watch issues when you create them.

@Matti Ruohonen
Good video showing the issues, and a decent workaround. I've put the link to it in the description. Thank you!

@CubeTheThird
Ok good to know that! After posting my previous comment, I suddenly received all the emails for the comments before it. Weird. Settings are OK. I just didn't receive anything up until now.

confirming present in 1.9-pre2 – unacceptable bug still present in pre-release versions let alone snapshots has me worried about the future state of minecraft
it's bad enough activator rails can't be reliably controlled for mob ejection direction let alone to air blocks – not being able to get mobs in the minecart in the first place is just flat unacceptable.
and don't forget to vote for the issue

I'm still seeing this issue in Pre-3

confirmed in 1.9-pre3

Confirmed for 1.9-pre4

the worst part of this bug is that it is preventing me from even testing another bug I want to file about, but since I can't even prove it exists right now let alone the funky WAYS in which it acts, due to the minecart problem here; I can't even report it, as no one will be able to reproduce it. Sure I can prove it existed back in 1.8.9 in certain ways and I can document the behaviour there, but a LOT has changed in these snapshots, and during this whole ongoing process I haven't been able to move forward with it even ONCE. So I've put it off, continually thinking that there's NO WAY they would let this bug go on for as long as it did.
Boy was I wrong.

@Scott R. Godin - Why not use the spawn command to spawn entities in minecarts? I assume that's what you want to do 🙂

if basic things like getting them in the minecart in the first place aren't going to work in survival on their own, what would be the point of testing further? no one's gonna give a damn about what the activator rails do, if you can't get a mob in the cart in the first place
"I'm not dead! I don't want to go on the cart!"

I'd really like to see this fixed, but in the meantime I have found another semi-workaround that I don't believe I've seen mentioned here yet. Minecarts that are dispensed onto the rails with a dispenser while the mob is standing on the block, do pick up the mob. For me this solves moving villagers around as I can herd them easily into a minecart loading spot. It still doesn't help me with other uses like my overworld enderman farm design which was able to work in 1.8, and is now just is broken completely because of this bug, and possibly also the bugs that @Scott R. Godin is talking about with activator rails, which ya can't really test on scale till this is fixed.

This is not a discussion forum.

No one is assigned to this bug?

One hopes that will change.

Issues are typically only assigned once a developer actually begins work on fixing that particular bug, and are usually fixed shortly thereafter. However, they will occasionally assign themselves to an issue because it's their field of expertise, or they have a specific plan to address the bug. Often, bugs will be fixed without ever being assigned, just because one of the developers happens to be looking through that piece of code, whether because they're working on a feature, or in the process of fixing some other bug. Basically, whether or not an issue is assigned provides little information as to an expected timeframe for resolution, and publicly wishing for it to be assigned accomplishes nothing, other than irritating everyone watching the issue in hopes of receiving useful information about it or the good news that it's been fixed.

confirmed for 1.9.1-pre1 and 1.9.1-pre2 and 1.9.1-pre3

Please link to this comment in the description
The following is based on decompiled version of Minecraft 1.9 using MCP 9.24 beta.
It looks like the problem is that the method net.minecraft.world.World.func_184144_a(Entity, AxisAlignedBB)
stops minecarts before their collision box can intersect with the one of a mob. Currently the collision box is expanded by 0.25. I do not know if this rather high expanding is really needed. Having some method that tests if a mob can be picked up and if so not adding the entity to the list of colliding entities could solve this problem.
Their collision box is not in general expanded by 0.25, only for this one method which expands it for all entities. For most entities however this has no effect because they do not return a collision box themself (method net.minecraft.entity.Entity.getCollisionBoundingBox()
, for example Shulkers return a collision box causing it to act as block) or the entity which is tested for if it collides returns no collision box for the entity (method net.minecraft.entity.Entity.getCollisionBox(Entity)
, minecarts and boats return a collision box when colliding with certain entities which causes them to stop). The expanding might not even be the major problem, probably rather that minecarts collide with entities before they can pick them up (happens without expanding as well). This is also caused by the fact that minecarts need a certain (rather low: motionX * motionX + motionZ * motionZ > 0.01
) minimum speed to pickup entities. However, if they were stopped before they do not have any speed at all.
Note: Besides that boats have the call to pickup an entity in the method net.minecraft.entity.item.EntityBoat.onUpdate()
whereas minecarts have it in the net.minecraft.entity.item.EntityMinecart.applyEntityCollision(Entity)
method.

May I ask why Marcono1234 isn't a moderator? I've seen many code analysises of him and he always asks to link it in the description. If he was a moderator, he could just write it in there. I personally haven't seen any spam or not helpful message from him.</ad>

@unknown Currently the collision box is expanded by 0.25. I do not know if this rather high expanding is really needed. |
As minecarts are vehicles but also entities, I wonder if their collision box issue should be added to MC-50367 and make it related to this bugpost, what do you think?

@unknown, I have not asked for it. But thank you for worrying about it 🙂
@unknown Their collision box is not in general expanded by 0.25, only for this one method which expands it for all entities. For most entities however this has no effect because they do not return a collision box themself (method net.minecraft.entity.Entity.getCollisionBoundingBox()
, for example Shulkers return a collision box causing it to act as block) or the entity which is tested for if it collides returns no collision box for the entity (method net.minecraft.entity.Entity.getCollisionBox(Entity)
, minecarts and boats return a collision box when colliding with certain entities which causes them to stop). The expanding might not even be the major problem, probably rather that minecarts collide with entities before they can pick them up (happens without expanding as well). This is also caused by the fact that minecarts need a certain (rather low: motionX * motionX + motionZ * motionZ > 0.01
) minimum speed to pickup entities. However, if they were stopped before they do not have any speed at all.
I will also add that to the comment above 😉
Confirmed for 1.9.3-pre3

This is still and issue in 16w20a, how has this still not been resolved I feel this is a big enough issue to deem it almost game breaking
This change is rather scary, please test it 😞
Seems to work with my limited testing setups.

@unknown I'll inform the Tech Community and ask them to test the fix and leave feedback here then.

I can confirm the issue for 16w20a.

@unknown this issue is fixed for the next upcomming snapshot.

@unknown Is it possible to push this fix into the 1.9 version? No offense, but knowing the Mojang update schedule this will be rolled out to the majority of players not earlier then a year. And it certainly is quite a game-breaking bug, at least for some portion of the game.

seconding the desire to see this folded into 1.9 as a fix rather than wait for the next major release. I have other bugs I want to report on and cannot move forward with the testing until this is actually part of the game. I had wanted to address my issues back before 1.9 became final, and it was impossible to move on any of it due to the nature of the problem

Seems fixed for me in 16w21a. \o/

@unknown added a comment - Yesterday 9:53 AM
This change is rather scary, please test it
Seems to work with my limited testing setups.
somebody mind checking?

I already sent an appeal to the tech community yesterday, waiting for Panda to RT it when he's at home.
Testing some contraptions (or people/Redstoners being at home) need a bit time, but I'll make sure people will reply in here }=)

I am also sad to see this is marked for 1.10. It is quite disappointing that issues like MC-51987 were fixed in 1.9 to make ejecting entities from minecarts reliable, yet getting entities into minecarts (this bug) was made too unreliable for automation.

I don't see where this is fixed. An entity on a rail does not get picked up by a moving minecart. It does get picked up if the minecart is created on the very same block the entity is standing on - placed manually below the entity or by a dispenser - but not when moving minecarts collide with the entity.
For me personally it's at least as important that moving minecarts pick up entities then non-moving minecarts (and I'm pretty sure this goes for a lot of people). So I argue this bug is not fixed.

Ah, this is odd (screenshots attached, tested in 16w21b).
I thought at first it's the direction of where the mobs are facing, or because when I added more powered rails the pickup gotten better, but turned out that the Minecart still could become stuck.
From what I can tell with quick testing, of course velocity is important, a slow Minecart can't pickup an entity, it will get stuck in the entity.
But here's another thing I ran into, it would be nice if someone could confirm that:
If I've got a design with powered rails and regular rails, it seems the Minecart always gets stuck at the entity (does not pick it up), IF the entity's hitbox is less than half a block (8 pixels) on a regular rail AFTER a POWERED rail.
As soon as it's more than half a block on that regular rail after the powered rail, the Minecart can pick it up.
If I turn basically the whole railway into powered rails, it becomes worse, the entity can't be pickuped at all anymore.
Is there some problem relating to powered rails, or am I imagining things?!

Reopened as it's not fully fixed.

Powered rails:
Seems as if, when the entity's hitbox edge is congruent with the block's edge, the Minecart can't pick it up.
If the pig is just 1 pixel away from that block's edge, the Minecart can pick it up.
(The Minecart came from the left, on a powered-rails-only railway with sufficient velocity to pick the entity up, velocity can't be the reason imo).

Changed reporter to @unknown please update this issue accordingly.

It really seems to be something with powered rails, or rather if the entity's hitbox is congruent with the edge of it.
In a design with regular rails before and after a powered rail, the minecart could pick up the pig when the pig's hitbox was at least 1 pixel onto the powered rail.
With 3 consecutive regular rails, the Minecart could always pickup the Pig, even if its hitbox' edge was congruent to a regular rail's edge.
The pickup on the 3 consecutive regular rails failed though, when the pig's hitbox was the same or less than 5 to a bit less than 2 pixels on one of the outer of the 3 rails' edges.
Hard to describe, basically there are a few locations where it'll fail, and others that won't.
Maybe someone else can figure out more and make better conclusions, or better setups, I'll do some more tests next week if no one else does.
@unknown Thank you, but the odd thing is that the Minecarts had sufficient velocity, it was a matter of 0.01 in the coordinates as for where the entity stood whether or not the Minecart picked it up (with the same amount of speed, I even made the railway longer with more powered rails.
I teleported the mob always to the very same coordinates, just different in 0.01 steps which made a difference in being picked up or not, dependant on what type of rail were around it.
I will test it with several different mobs and railway setups.
If you look at the screenshot of RimaNari, you can clearly see a "pattern" of sorts, which partially mirrors what I also encountered when I tested it so far.

@unknown I'll conduct more tests in a few days, I'm currently busy with other community work, and foremost I need to wrap my head around this bug here and think of a good setup where I can pinpoint it to something 100% certain.
I will also ask Panda who hosts the hitbox-bugpost (and knows in general game mechanics possibly way better than anyone else), maybe he can help figuring it out.
Will update the bugpost as soon as possible with the new results.

I did some further but simpler testing myself and found some strange behaviour already. I spawned an entity (a villager) on a rail track using a spawn egg therefore placing the villager at the very center of the block always. I then run a minecart into it.
A screenshot is attached where several tests are visible - a green wool block next to a rail block means a villager placed on this rail block would get picked up while a red one means it would not get picked up. The minecart was run into the villager by being placed on the tracks next to the black wool block (no further accleration by pushing it).
Looking at each of the tests from left to right in the screenshots there is some pattern visible of positions able to pick up the villager alternating with those that are not. While the before last test shows expected behaviour due to reduced minecart speed because of less power rails, the very last test with even further reduced speed shows very unexpected behaviour.
It is also noteable that when pushing the minecart additionally to the speed build-up from the power rails it is able to pick up the villager when else it was not.
Therefore as a first guess I'd say the problem lies within the code that links minecart speed to the ability to pick up entities.

"it turns out that..."?

After going over the bugtracker through minecart-bugposts and also conducting some other tests, I feel that, even though this bug could be fixed by extending the bounding box towards where the cart is heading to, to prevent colliding with the entity and thus picking it up before, I should rather suggest a complete overhaul of minecarts, as some other oddities could cause other bugs; e.g. the minecart always "looks" South (activate hitboxes with F3+b), no matter how you place it.
After it went through curves, the way it looks changes from cardinal South to "diagonal", always in this pattern:
diagonal-left down, diagonal-left up, diagonal-right down, diagonal-right up, diagonal-right down, diagonal-left up
(I recorded a video, if needed).
In my opinion the way a minecart faces should always be where it is heading to.
If minecarts are driving side by side in a North-South-railline, their hitboxes seem to "rub" against each other and boost each other, not so in East-West, only if they went through curves.
The texture sticks out if you place blocks against it, once to one side, then to the other, etc. pp.
TLDR; Maybe all oddities should be fixed, minecarts done completely anew, analogue to the boats which were never fixed, but instead replaced by new boats.
As minecarts, hopperminecarts, minecartchests etc. are essential for many people in the tech community, this should be done slowly and thoroughly to prevent breaking of contraptions but instead be even more helpful for them.
To be more clear: I don't think all single bugposts regarding minecarts should be fixed, it should be a "big fix" that would resolve each one of them automatically as all "oddities" of minecarts would be gone.

Please do not mark unreleased versions as affected.
You don't have access to them yet.

Confirmed for 18w22c

Still in 1.13-pre1

Confirmed for 1.13-pre3

Confirmed for 1.13-pre4
Confirmed for 1.13-pre6.
Confirmed for 1.13-pre7.

Seems to be fixed for 1.13-pre8.

Still able to reproduce in 1.13-pre8. The motion of the minecart was propably not high enough when you tested.

Confirmed for 1.13-pre9.

Confirmed for 1.13-pre10.

Confirmed for 1.13.

Confirmed for 18w30a.

Confirmed for 18w31a.

Confirmed for 18w32a.

Confirmed for 18w33a.

Confirmed for 1.13.1.

Confirmed for 1.13.2-pre1.

Confirmed for 1.13.2-pre2.

Confirmed for 1.16 Pre-release 2.

Confirmed in 1.16-pre3.

Confirmed in 1.16-pre4.

Confirmed in 1.16-pre5.

Confirmed in 1.16-pre6.

Confirmed in 1.16-pre7.

Confirmed in 1.16-pre8.

Confirmed in 1.16-rc1.

Affects 1.20.1.

You could use a hotbox accounting for the delta motion of the minecart.

it's also in 24w06a and 1.20.4
Fixed with the 24w34a minecart experiment:
[media]