Minecarts that have passengers within them riding mobs can move automatically when not on rails

Confirmed for

• 15w44b This only relates to MC-64836 as in this case here it also happens without the minecart being on rails

This seems to happen for mobs which AI is overridden by default, so chickens and spiders:

Chicken Jockey

/summon MinecartRideable ~ ~ ~ {Passengers:[{id:"Chicken",Passengers:[{id:"Zombie"}]}]}

Spider Jockey

/summon MinecartRideable ~ ~ ~ {Passengers:[{id:"Spider",Passengers:[{id:"Zombie"}]}]}

Note: For spiders the movement seems to be inversed so they move away from their target

Ticket is yours, please update the description. Skeleton warriors might be affected too.

What do you mean by "Skeleton warriors"? Skeletal horses?

Yes.

Still in 16w06a

Done 🙂

Thank you very much! 🙂

Thanks @unknown. Though could you please in the future not completely reformat bug reports. I think for the reproduction steps using an ordered list (1., 2., ...) makes more sense than an unordered list. The code block with the example command also belonged to the previous list item, now it is a separate list item which is a bit confusing. I would recommend to edit on Jira here in "Text" mode (in case you aren't using it already) and switch only to "Visual" mode for previewing the changes. That gives your greater control over the formatting, and also avoids somes issues and bugs Jira has with the Visual editor. The Text Formatting Notation help shows how it can be used.
Though please don't go through every report you have edited to revert your changes.

Additionally I am not sure if updating the summary and description in this way is ideal; one important aspect of this issue is that the minecart is not on rails (previously it said "track"). This should behave similar to a player in a minecart which is not on rails, where the player cannot move either. However, if the minecart is on rails, then it might be desired that mobs can control the movement (similar to how players can control it, even without powered rails).

Hi @unknown; thanks for your reply.

The reasoning for reformatting the bug report is just to make it crystal clear regarding what the problem is here and allow pieces of information to be easily gathered through an initial glance, hence why I created the "Steps to Reproduce", "Observed Behavior", etc... subheadings. Additionally, the reason why I prefer to use bulleted lists for the "Steps to Reproduce" section is that the ordered lists (1., 2., ...) in my experience have several issues and sometimes become unordered when using code blocks and other types of text formatting. For example, the list will say "1, 2, 3, 1, 5" instead of the expected "1, 2, 3, 4, 5", which of course, creates confusion. I find the bulleted list to be more direct and easier to follow and that's why I prefer to use them; I hope this is okay.

Additionally, following on from what you've said, I've just made slight alterations to this ticket to mention that this problem occurs when the minecart is not on a rail. After rereading this report in its entirety, I was educated that this information should/needed to be included. As a final note, I will try my best to not completely reformat bug reports in the future, and I apologize if I caused any inconvenience by doing so. Thank you 🙂

Additionally, the reason why I prefer to use bulleted lists for the "Steps to Reproduce" section is that the ordered lists (1., 2., ...) in my experience have several issues and sometimes become unordered when using code blocks and other types of text formatting. For example, the list will say "1, 2, 3, 1, 5" instead of the expected "1, 2, 3, 4, 5", which of course, creates confusion. I find the bulleted list to be more direct and easier to follow and that's why I prefer to use them; I hope this is okay.

At least with the Jira "Text" mode editor, you can create proper ordered lists quite easily by writing #, e.g.:

# First
# Second
{noformat}
With block
{noformat}
# Third

Jira will then take care of the numbering and formatting, so there is no risk that the list numbers will become incorrect. For example the rendered version from the text above is:

1. First

2. Second

   With block

3. Third

That is also why I was recommending the "Text" mode editor; you can more precisely control how the result will look like and don't have to click on buttons to format text.

In my opinion ordered lists might make it easier to track at which step you are and which step you need to execute next, and they also make it easier to refer to a specific step when something is not working as expected, e.g.: "Command in step 7 failed for me", instead of "Command <long command> failed for me" (which might also be ambigous if there are multiple commands)
Though I don't mind that much if you keep an unordered list here.