[MC-11142] Placing a Redstone Torch/Block next to a rail junction does not change the rail direction Created: 06/Mar/13  Updated: 18/Sep/20  Resolved: 01/Jan/18

Status: Resolved
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Snapshot 13w10a, Snapshot 13w10b, Minecraft 1.5.1, Minecraft 1.5.2, Snapshot 13w18c, Snapshot 13w19a, Minecraft 1.7.2, Minecraft 1.7.4, Minecraft 14w08a, Minecraft 14w20b, Minecraft 14w29b, Minecraft 14w30c, Minecraft 14w31a, Minecraft 1.8-pre1, Minecraft 1.8, Minecraft 1.8.1-pre3, Minecraft 1.8.8, Minecraft 15w33c, Minecraft 16w04a, Minecraft 1.9, Minecraft 1.9.1 Pre-Release 1, Minecraft 1.9.1 Pre-Release 2, Minecraft 1.9.1 Pre-Release 3, Minecraft 1.9.4, Minecraft 16w21a, Minecraft 1.11.2, Minecraft 1.12 Pre-Release 6, Minecraft 1.12.1, Minecraft 1.12.2, Minecraft 17w43a, Minecraft 17w43b
Fix Version/s: Minecraft 17w50a

Type: Bug
Reporter: Marcono1234 Assignee: Unassigned
Resolution: Fixed Votes: 10
Labels: rail, redstone, redstone_block, redstone_torch

Attachments: PNG File 2013-03-06_15.52.27.png     PNG File 2013-03-06_15.52.55.png    
Issue Links:
Cloners
is cloned by MC-167257 Powering rail junctions from the side... Open
Duplicate
is duplicated by MC-98185 Rail Junctions Don't Update Properly ... Resolved
is duplicated by MC-103912 Junctions in rails do not update when... Resolved
Relates
relates to MC-8184 Redstone block and torches don't powe... Resolved
CHK:
Confirmation Status: Confirmed

 Description   

The bug

Please look at the screenshots first to understand

When you place three rails like I did and you place at the bifurcation a redstone torch it will not update the rail, BUT when you place it under the rail it works

Code analysis

The following is based on decompiled version of Minecraft 1.9 using MCP 9.24 beta. All method and class names are the names used in the decompiled version.

The reason why this happens is very likely a wrong IBlockState being returned by the method net.minecraft.world.chunk.Chunk.setBlockState(BlockPos, IBlockState). The IBlockState it returns is the one from the block that was replaced. This means the rail is receives a neighbour update with air as source which does not update the rail.

public IBlockState setBlockState(BlockPos pos, IBlockState state)
{        
    int i = pos.getX() & 15;
    int j = pos.getY();
    int k = pos.getZ() & 15;
    int l = k << 4 | i;

    if (j >= this.precipitationHeightMap[l] - 1)
    {
        this.precipitationHeightMap[l] = -999;
    }

    int i1 = this.heightMap[l];
    IBlockState iblockstate = this.getBlockState(pos);

    if (iblockstate == state)
    {
        return null;
    }
    else
    {
        //...
        
        if (extendedblockstorage.get(i, j & 15, k).getBlock() != block)
        {
            return null;
        }
        else
        {
            //...

            this.isModified = true;
            // Replaced this; now returns the new state
            //return iblockstate;
            return state;
        }
    }
}

If this method is supposed to returns the old state, then methods like net.minecraft.block.BlockRedstoneTorch.onBlockAdded(World, BlockPos, IBlockState) are not working correctly because they pass themself which means at the end the new state is passed.
Besides that the method net.minecraft.block.BlockRail.onNeighborChangedInternal(World, BlockPos, IBlockState, Block) will still not work correctly. It should test if the new placed block state provides power and if the rail was powered before (it looks like this is currently not tracked).



 Comments   
Comment by [Mod] NeunEinser [ 20/Jun/20 ]

woodensword See MC-167257.

Comment by A Full Name [ 08/Jun/20 ]

This is happening in 1.15.2.

Comment by Marcono1234 [ 07/Dec/19 ]

@LoekTheKing, you are right, thank you very much. I have cloned the report as MC-167257 since this report is so old and the bug has been fixed a rather long time ago.
Do you want to become the reporter of the new report and keep it up to date?

Comment by Loek van Vucht [ 04/Dec/19 ]

This bug has re-appeared in 1.14.4

Comment by [Mod] NeunEinser [ 11/Dec/17 ]

Fixed in recent snapshots (tested in 17w50a)

Comment by [Mod] NeunEinser [ 26/Oct/17 ]

Can confirm for 17w43a/b

Comment by SunCat [ 16/Sep/17 ]

chyx, 1.12 is outdated, and a newer version (1.12.1) was already marked as affected

Comment by chenyuxuan [ 16/Sep/17 ]

Still in 1.12

Comment by SunCat [ 25/May/16 ]

Still in 16w21a

Comment by SunCat [ 19/Mar/16 ]

Still in 1.9.1-pre3

Comment by Jarmo Merinen [ 14/Aug/15 ]

Confirmed for 15w33c

Comment by Itouch2 [ 08/May/14 ]

Confirmed for 14w18b.

Comment by kbk [ 27/Apr/13 ]

Still not fixed as of 1.5.2pre.
To clarify, if you place a torch adjacent to a t-rail, the t-rail actually can change direction when said torch is controlled by some signal. Placing and removing the torch, however, does not affect t-rail direction even when the circuit that provides that signal exists. In such case t-rail also disregards a zero-tick pulse created on torch placement when the circuit is on.

Comment by kbk [ 06/Mar/13 ]

This has been described previosly in MC-8581 (and maybe elsewhere too).

Comment by Tails [ 06/Mar/13 ]

Confirmed.

Generated at Sun Jan 12 12:26:40 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.