[MC-2023] Minecart rails break when moved with a block under certain conditions

The Bug

Pushing and pulling a minecart rail simultaneously with the block it's on will cause the rail to break once the extension/retraction has completed. This holds true for normal rails, powered rails, and detector rails.

Note:

A ghost rail can also be created in this setup when the rail breaks (see MC-75716).
The directional randomness in the described setup has been fixed with the 24w33 redstone experiment. The lever closer to the piston is now consistently is the one which causes the rail to break. The rail breaking is the only remaining bug here with the experiment enabled.

Related issues

is duplicated by

MC-9990 Rails break when pushed up by pistons

MC-16911 Rails will be destroyed by Pistons

MC-44008 Pistons can push minecart rails in all directions but one

MC-58438 Piston + Slime Block Doesn't Move Rail

MC-101557 Rails drop when pushed up by piston

MC-128625 Pushing rails randomly destroys them based on their relative position to the piston and direction of the pushing

MC-135108 Rails in the fly machine will de broken.

MC-266311 Rails glitching when powered by piston in a specific way

relates to

MC-75716 Pistons can create ghost blocks of rails

MC-179573 Ghost rail is created when pushing a rail on top of a gravity block which starts falling

MC-204889 Slanted minecart rails break after being moved by pistons in certain circumstances

Attachments

Comments

migrated 2012-11-03T00:52:35Z

[media][media][media][media][media]

migrated 2012-12-06T15:52:03Z

If you put the rail and the block underneath it on an ABBA circuit, it works (push block first and then rail to extend, pull rail first then block to retract). I agree that it shouldn't be that way, and you should be able to push them both at the same time, but that is a currently working fix (used that for my toggleable destination train station).

migrated 2013-01-21T23:11:02Z

Confirmed in 13w03a. Really want my train station to work again.

migrated 2013-01-25T22:23:06Z

Confirmed in 13w04a.

migrated 2013-02-07T20:56:44Z

Confirmed in 13w05b and 13w06a.

migrated 2013-02-27T19:07:56Z

Confirmed in 13w09b.

migrated 2013-03-15T17:50:57Z

Confirmed in 1.5.

migrated 2014-01-22T17:09:38Z

Affects beta 14x03b. When retracting the rails, all are broken. When pushing the rails, all are broken, but the visual of the rail typically remains (you get the rail back but it looks like it is there; when you place a minecart on it, both the rail and the minecart disappear).

migrated 2014-10-24T19:17:55Z

Confirmed to still be an issue in 1.8.1pre3.

galaxy_2alex 2014-10-24T19:19:04Z

Reopened, Thanks.

FaRo1 2016-06-22T21:29:27Z

Confirmed for 1.10.1.

migrated 2018-07-28T12:16:48Z

Confirmed for 1.13 & 18w30b.

migrated 2018-08-01T19:58:10Z

Confirmed for 18w31a.

migrated 2018-08-08T14:51:31Z

Confirmed for 18w32a.

migrated 2018-08-15T15:37:03Z

Confirmed for 18w33a.

migrated 2018-08-22T20:11:07Z

Confirmed for 1.13.1.

migrated 2018-10-19T16:35:16Z

Confirmed for 1.13.2-pre2.

Jack McKalling 2018-11-29T16:24:13Z

Does not appear to happen anymore in 18w48a. Might have been fixed earlier.

migrated 2018-11-29T18:30:45Z

Did you push with the block it's on?

Jack McKalling 2018-11-29T18:49:17Z

Pushed both the rails plus the block that supports it, yes.

FaRo1 2018-11-29T21:26:16Z

It's different now (18w48a), but definitely not fixed: Pushing a rail and the block it's on sideways together (or a diagonal rail and the block it's leaned on) drops it, but the rail is still there visually (ghost block).

Up/down movement seems to be completely fine.

Jack McKalling 2018-12-03T00:33:52Z

Please show picture of what you're doing where it drops the rail, as I cannot reproduce.

I've tried all orientations and positioning I could think of that would follow the rule "rail and the block it is attached to". The only way my rails drops is when I push the block below it but not the rail itself.

FaRo1 2018-12-03T13:56:03Z

OBS isn't properly set up yet, so the file is too big for an attachment: https://drive.google.com/open?id=1BV3xRXw_iAclGNIPndg9hTU8eo0oz0i3

FaRo1 2018-12-03T14:36:57Z

Apparently the sharing setting wasn't correct before. Should be fixed now, everyone should be able to view the file.

Jack McKalling 2018-12-03T21:10:31Z

Thanks. I've summarized your and my findings in one hopefully more convenient screenshot. (as of screenshot, in 18w48b)

[media]

Jack McKalling 2018-12-03T22:19:48Z

I think the problem is more complicated or incomplete from above observations.

I tested the same configuration in four different mirrored orientations (more exist even!), and the problem doesn't happen consistently. Observe the piston orientations and each lever. Red blocks lead to dropped rails, green ones don't.

[media]

Jack McKalling 2018-12-05T15:58:19Z

Confirmed for 18w49a, the above conclusions still apply

Jack McKalling 2018-12-12T15:41:37Z

Confirmed for 18w50a, as above

Jack McKalling 2019-01-09T16:46:46Z

Confirmed for 19w02a

Jack McKalling 2019-01-16T17:40:28Z

Confirmed for 19w03a

Jack McKalling 2019-01-17T17:41:30Z

Confirmed for 19w03b

Jack McKalling 2019-01-19T16:40:35Z

Confirmed for 19w03c

Jack McKalling 2019-01-24T16:32:10Z

Comfirmed for 19w04a

Jack McKalling 2019-01-31T00:03:00Z

Confirmed for 19w04b and 19w05a

Jack McKalling 2019-02-07T11:49:11Z

Comfirmed for 19w06a

Jack McKalling 2019-02-13T17:16:02Z

Confirmed for 19w07a

Jack McKalling 2019-02-28T09:42:26Z

Confirmed for 19w09a

Jack McKalling 2019-03-13T17:21:46Z

Confirmed for 19w11a

Jack McKalling 2019-03-14T16:20:27Z

Confirmed for 19w11b

Jack McKalling 2019-03-20T22:20:59Z

Confirmed for 19w12a

Jack McKalling 2019-03-21T16:59:30Z

Confirmed for 19w12b

Jack McKalling 2019-03-27T19:58:13Z

Confirmed for 19w13a

Jack McKalling 2019-03-29T14:16:48Z

Confirmed for 19w13b

Jack McKalling 2019-04-03T15:59:29Z

Confirmed for 19w14a

Jack McKalling 2019-04-08T09:47:53Z

Confirmed for 19w14b

Jack McKalling 2019-04-10T15:33:13Z

Confirmed for 1.14 pre-1

Jack McKalling 2019-04-15T09:18:56Z

Confirmed for 1.14 pre-2

Jack McKalling 2019-04-16T14:49:01Z

Confirmed for 1.14 pre-3

Jack McKalling 2019-04-17T16:40:41Z

Confirmed for 1.14 pre-4

Jack McKalling 2019-04-18T13:11:05Z

Confirmed for 1.14 pre-5

Jack McKalling 2019-04-23T19:56:03Z

Confirmed for 1.14

Jack McKalling 2019-05-07T16:22:29Z

Confirmed for 1.14.1 pre-1

Jack McKalling 2019-05-09T15:29:22Z

Confirmed for 1.14.1 pre-2

Jack McKalling 2019-05-13T13:31:40Z

Confirmed for 1.14.1

migrated 2020-06-10T19:30:41Z

Confirmed in 1.16-pre3.

migrated 2020-06-12T19:31:14Z

Confirmed in 1.16-pre5.

migrated 2020-06-15T21:59:40Z

Confirmed in 1.16-pre6.

migrated 2020-06-17T09:10:47Z

Confirmed in 1.16-pre7.

Jack McKalling 2020-08-03T10:10:50Z

I've rotated and mirrored the exact same structure in all directions now, and the results of whether the rail breaks and leaves a ghost block (red) or behaves normally (green) is consistent and seems directional. I can't figure out exactly how or why, but this is what it does:

[media]

PR0CESS 2022-01-28T00:32:29Z

So just to clarify what is actually happening here. It's not random or sometimes happens.
It's redstone update order.

All you need to create this bug is have the power source update the bottom piston before the top piston. It's that simple!

What's a reliable way to do this you may ask?

[media]

migrated 2022-06-05T22:06:54Z

Can confirm in 1.19-rc2

migrated 2022-06-07T04:36:27Z

This could be fixed by postponing the rail's check for a block beneath it till the next tick (ie in the code check for unsupported rails BEFORE performing piston pushes, this would delay rail check to the next tick)

Brain81505 2023-01-25T07:26:24Z

Can confirm in 1.19.3 and 23w04a

Brain81505 2023-02-01T16:06:14Z

Can confirm in 23w05a

Brain81505 2023-02-11T15:33:42Z

Can confirm in 23w06a

Brain81505 2023-07-05T16:01:38Z

Can confirm in 1.20.1

[Mod] Jingy 2024-08-21T05:17:51Z

The rail breaking and leaving behind a 'ghost rail' still exists, but the directional randomness of the issue is fixed with the 24w33a redstone experiment:

[media]

The lever 'closer' to the pistons will always be the one to result in a ghost rail being created/the rail breaking. I've added the 'experimental_redstone_fixed' label indicating that the randomness is fixed, however the behavior of MC-75716 still exists.