Immaterialise
- Immaterialise
- immaterialise
- Europe/London
- Yes
- No
MCPE-15796Confirmed for 1.9-pre1
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
If you have a detector rail it can affect rails directly connected to it. A powered rail for example is powered and a curved rail can change orientation. Imagine now to have a t-junction setup like in
The detector rail is on the left and passing it will cause the curved rail to change orientation. We start our cart not from the detector, but from where the rail is bend to. After starting the cart it goes into the bend and before leaving it, the detector will react. This causes a flicker in which the cart and the rail change orientation several times to then finally settle in the right-side position as in 
This basically means the detector rail caused a change of orientation for the bend rail before the minecart was even standing on it.
I assume that the signaling goes by this: If the cart, would in a next step touch the detector rail, it fires. Since the rail is then bending in another direction there is an update as the minecart will now not go over the rail, causing another oriantation change. This then causes the detector to fire again going back to the situation in the beginning. The reason why this does not cause an endless loop is that each action takes one tick. Depending on the speed of the cart you will see a longer or shorter flicker then.
What I expected was that the cart will go to the left, not the right as it actually did.
Code analysis by FX - PR0CESS can be found in this comment.
- Fixed in 16w02a? Using the setup described in start.png, the minecart sometimes "bounces" off the rail and goes backwards.
- Half-fixed
for 1.9.1-pre3.
- Slow-moving minecarts will go the correct way, while fast moving minecarts will bounce back?!
- Confirmed for 1.9-pre1. It seems to be affected by the speed of the minecart as well. Fast and slow minecarts don't trigger it, but minecarts with a medium-ish speed do.
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1. Affects torches, levers, redstone torches, buttons (both), tripwire hooks, end rods and string.
Confirmed for 1.9-pre1. It affects coordinates shown in F3 as well.
Confirmed for 1.9-pre1. It seems to be affected by the speed of the minecart as well. Fast and slow minecarts don't trigger it, but minecarts with a medium-ish speed do.
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Not sure if still present in 1.9-pre1. I just killed 512 zombies in 1 hit, every single one played the death sound. Is it that rare, or has it been fixed?
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1, although glowstone doesn't seem to be affected anymore. It still occurs with water and cobwebs.
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1. The zombie can still jump and hit the top of the door (Playing sound effects and showing cracking), but can't destroy it in the brief moment that it's in range.
Confirmed for 1.9-pre1. As said previously, it only affects minecarts travelling North or South, and in both cases they turn towards West. It also affects all minecart variants. After waiting a while, or reloading the world/chunks, the minecarts correct themselves, and face the correct direction.
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Can't recreate in 1.9-pre1. Probably fixed. I tested both piston types in all orientations.
Fixed in 1.9-pre1. Tested on iron golems and skeletons.
Confirmed for 1.9-pre1
It now drops when punching the top AND bottom. Tested in all orientations in 1.9-pre1.
Confirmed for 1.9-pre1. The beacon beam and glowing effect caused by spectral arrows are still visible.
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
I checked if this was still true with shield blocking (1.9-pre1), and it isn't. Blocking with a shield has exactly the same movement speed on ice (And packed ice) as it does on other blocks, both when walking straight, and when walking diagonally. And as sword blocking isn't a thing anymore, this bug is obsolete.
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Ok, tested again, but this time killing them with two hits in quick succession, and it is still present in 1.9-pre1. It occured twice in 167 attempts.
Still present in 1.9-pre1; it occurs with all fence/fence gate types, including nether brick fence and cobblestone wall.
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1. It affects furnace, tnt, hopper and command block minecarts, but not chest minecarts.
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
This affects Windows 10 Edition as well, v0.15.0
Still an issue in 0.15.1. As a bit of extra detail, before moving the mouse, the cursor appears as the default windows arrow cursor overlaying the in-game minecraft cursor. As soon as it's moved, the windows cursor disappears