Preliminary remark
Despite sounding similar to MC-31100, this report is not a duplicate. MC-31100 covers redstone components which do not notice that they should be powered, this report here covers special cases in which redstone power supplying blocks do not update all required blocks.
The bug
Redstone power supplying blocks do not update all affected blocks when placed using commands. Mainly the do not update blocks which are currently receiving or should receive power through a block.
This affects commands like /setblock as well as falling block entities.
How to reproduce
Build a setup as shown in
Stand on the lapis block and use a command to place a lever
/setblock ~ ~ ~ lever[face=floor,powered=true]→ ❌ The redstone wire which should be powered through the block was not updated
Code analysis
MCP 9.40-pre1 names
In order to resolve the issue for placing a new block, the method net.minecraft.block.Block.onBlockAdded(World, BlockPos, IBlockState) needs to be overridden in the classes of power supplying blocks (lever, button and similar):
@Override
public void onBlockAdded(World worldIn, BlockPos pos, IBlockState state)
{
if(state.getValue(POWERED))
worldIn.notifyNeighborsOfStateChange(pos.offset(state.getValue(FACING).getFacing().getOpposite()), this, false);
}This method is however not called by net.minecraft.world.chunk.Chunk.setBlockState(BlockPos, IBlockState), when the block type it is placing is the same that was there previously.
One possibility would obviously be to remove the check, but that might have side effects elsewhere that I am not aware of. Some code would become redundant at the very least.
Another, probably more clean way of fixing it would be to add an additional method to Block, like onStateChange that gets called in this case. With this soloution some of the code of net.minecraft.block.BlockLever.onBlockActivated(World, BlockPos, IBlockState, EntityPlayer, EnumHand, EnumFacing, float, float, float) would become redundant as it is already changing the state in there and the new onStateChange method would take care of that anyways.
Related issues
is duplicated by
Attachments
Comments
migrated
migrated
It's the same problem: lack of block update(s).
NeunEinser
Not really. MC-31100 is not about missing block updates or a lack of them. It is more about a block getting placed and the placed block not checking if it should be powered and thus do stuff.
This is about a block getting placed and not causing other blocks to update. Also in MC-31100 this will always happen, no matter what block has been at the position before. This will only happen if you replace the block with the same block, but different state.
Besides that, I created the report to provide code analysis. I cannot do that in MC-31100 since that is also codewise a totally different problem which my code analysis will have no effect on.
NeunEinser
Also, to clarify a bit here, the issue description of MC-31100 is actually wrong. /setblock does cause block updates. And the issue also does not describe, as I said before, missing block updates. It doesn't even have to do anything with /setblock. If you have a command block with data in your inventory and place it, the command also does not get executed. This bug is really just describing a bug with command blocks only. It probably is just the command block not checking if it is powered when placed.
And yes, a block update on the command block will result in the command block executing, but that does not mean that the code should have caused a block update here. Blocks do not update themselves when placed in general.
NeunEinser
Uhm, is it now considered a duplicate or not? @unknown reopened it, but didn't update issue links.
marcono1234
@@unknown, I am seeing this behavior even if the same block was not there before. Are you still seeing the behavior you originally described, in 18w06a or are the changes I made to this report fine for you?
Edit: If so, may I mark your code analysis as outdated or remove it for now?
NeunEinser
@unknown Interesting, just placing it does the same in 1.12.2. Code analysis are incomplete then. The lever actually does not override the onBlockAdded method. It is however true, that adding this method in 1.12.2 to the lever class only fixes the issue for placing a new block and not a mere state change.
Avoma
Can confirm in 20w51a.
[Mod] Jingy
Affects 1.20.4 and 1.20.5 Release Candidate 2
NeunEinser