pupnewfster

While looking into a bug that got reported to Mekanism about a similar issue with block placement sounds not being properly played I think I found the cause of this issue with redstone ore. Using my debugger I tracked it down to this block of code (in PlayerController#func_217292_a):

boolean flag = !p_217292_1_.getHeldItemMainhand().doesSneakBypassUse(p_217292_2_,blockpos,p_217292_1_) || !p_217292_1_.getHeldItemOffhand().doesSneakBypassUse(p_217292_2_,blockpos,p_217292_1_);
boolean flag1 = p_217292_1_.isSecondaryUseActive() && flag;
if (event.getUseBlock() != net.minecraftforge.eventbus.api.Event.Result.DENY && !flag1) {
   ActionResultType actionresulttype = p_217292_2_.getBlockState(blockpos).onBlockActivated(p_217292_2_, p_217292_1_, p_217292_3_, p_217292_4_);
   if (actionresulttype.isSuccessOrConsume()) {
      this.connection.sendPacket(new CPlayerTryUseItemOnBlockPacket(p_217292_3_, p_217292_4_));
      return actionresulttype;
   }
}

Looking at forge's patches the only part they added to the above snippet is the event result check. onBlockActivated for RedstoneOre is implemented as such:

if (worldIn.isRemote) {
   spawnParticles(worldIn, pos);
   return ActionResultType.SUCCESS;
} else {
   activate(state, worldIn, pos);
   return ActionResultType.PASS;
}

Which means that on the client it will always return success, thus having isSuccessOrConsume be true, and exiting the method func_217292_a. The placement sound code is lower down in that method where itemstack#onItemUse gets called so that BlockItem#tryPlace gets fired.