The bug
Flint and steel places fire at invalid positions, for example on the side of non-inflammable blocks like stone which causes the fire block to disappear the next time it is updated.
How to reproduce
Right click with a flint and steel on a side of block that can't normally catch on fire (Stone for example).
The fire block will appear for a tick.
Note: The fire does not set any entities at the position on fire.
Code analysis
The following is based on decompiled version of Minecraft 1.8 using MCP. All method and class names are the names used in the decompiled version.
The reason for this is that the fire block is actually created. However, the public void onBlockAdded(World worldIn, BlockPos pos, IBlockState state) method of the net.minecraft.block.BlockFire class is called right after it was placed and removes the block as it is at an invalid position.
This could / should be fixed by having the public boolean onItemUse(ItemStack stack, EntityPlayer playerIn, World worldIn, BlockPos pos, EnumFacing side, float hitX, float hitY, float hitZ) method of the net.minecraft.item.ItemFlintAndSteel class only place a fire block is the position is valid. Other items like the bucket might be affected as well, however currently you can place water and lava on every block so it causes no problems.
/**
* Called when a Block is right-clicked with this Item
*
* @param pos The block being right-clicked
* @param side The side being right-clicked
*/
public boolean onItemUse(ItemStack stack, EntityPlayer playerIn, World worldIn, BlockPos pos, EnumFacing side, float hitX, float hitY, float hitZ)
{
pos = pos.offset(side);
if (!playerIn.func_175151_a(pos, side, stack))
{
return false;
}
else
{
// Changed this
//if (worldIn.getBlockState(pos).getBlock().getMaterial() == Material.air)
if (worldIn.getBlockState(pos).getBlock().getMaterial() == Material.air && Blocks.fire.canPlaceBlockAt(worldIn, pos))
{
worldIn.playSoundEffect((double)pos.getX() + 0.5D, (double)pos.getY() + 0.5D, (double)pos.getZ() + 0.5D, "fire.ignite", 1.0F, itemRand.nextFloat() * 0.4F + 0.8F);
worldIn.setBlockState(pos, Blocks.fire.getDefaultState());
}
stack.damageItem(1, playerIn);
return true;
}
}Notes
A similar fix would be needed for the
fire_chargeitem and also for thenet.minecraft.init.Bootstrap.registerDispenserBehaviorsfor these items.This fix does not include the use of these items at invalid locations to activate a Nether portal, which could then be moved from
net.minecraft.block.BlockFire.onBlockAdded(World, BlockPos, IBlockState)to the respective methods when using an item to create a fire block.
Linked issues
is duplicated by 10
MC-43018
Sand Lighting Glitch
Resolved
MC-1370
Using Flint and Steel on non-ignitable blocks should be blocked
Resolved
MC-1658
If you burn one side of the block, for a moment there is light
Resolved
MC-8202
invinsible 1 tick farmland fire
Resolved
MC-9695
lighter works on wall
Resolved
MC-13338
Flint and steel lighting bug
Resolved
MC-14820
Using Flint&Steel in an unusable place causes it to still "light up" the area
Resolved
MC-30477
Client fire flashes
Resolved
MC-60633
Create single-frame flying fire using flint and steel
Resolved
MC-68914
Flint And Steel Cant Light The Side Of Blocks.
Resolved
relates to 3
Attachments
Comments 31
You can set the top of a non-flammable block on fire, not the side. Fire will appear if you right-click the top of the block, but it won't if you click on the side.
I'm talking about when you right click the side.
Is this still a concern in the latest Minecraft version 14w08a? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Confirmed for 14w27b.
Confirmed for 14w28a
Also somehow with dispensers: MC-8232
Confirmed for 1.8-pre2.
Still in 1.8.
Still in 1.8.1. Strangely, this does not occur with fire charges.
Confirmed for 1.8.2-pre1.
Still in 16w05b
Also, this can be done in creative.
Confirmed for 1.9-pre1
Please link to this comment in the description of the report.
The following is based on decompiled version of Minecraft 1.8 using MCP. All method and class names are the names used in the decompiled version.
The reason for this is that the fire block is actually created. However, the public void onBlockAdded(World worldIn, BlockPos pos, IBlockState state) method of the net.minecraft.block.BlockFire class is called right after it was placed and removes the block as it is at an invalid position.
This could / should be fixed by having the public boolean onItemUse(ItemStack stack, EntityPlayer playerIn, World worldIn, BlockPos pos, EnumFacing side, float hitX, float hitY, float hitZ) method of the net.minecraft.item.ItemFlintAndSteel class only place a fire block is the position is valid. Other items like the bucket might be affected as well, however currently you can place water and lava on every block so it causes no problems.
/**
* Called when a Block is right-clicked with this Item
*
* @param pos The block being right-clicked
* @param side The side being right-clicked
*/
public boolean onItemUse(ItemStack stack, EntityPlayer playerIn, World worldIn, BlockPos pos, EnumFacing side, float hitX, float hitY, float hitZ)
{
pos = pos.offset(side);
if (!playerIn.func_175151_a(pos, side, stack))
{
return false;
}
else
{
// Changed this
//if (worldIn.getBlockState(pos).getBlock().getMaterial() == Material.air)
if (worldIn.getBlockState(pos).getBlock().getMaterial() == Material.air && Blocks.fire.canPlaceBlockAt(worldIn, pos))
{
worldIn.playSoundEffect((double)pos.getX() + 0.5D, (double)pos.getY() + 0.5D, (double)pos.getZ() + 0.5D, "fire.ignite", 1.0F, itemRand.nextFloat() * 0.4F + 0.8F);
worldIn.setBlockState(pos, Blocks.fire.getDefaultState());
}
stack.damageItem(1, playerIn);
return true;
}
}Notes:
A similar fix would be needed for the
fire_chargeitem and also for thenet.minecraft.init.Bootstrap.registerDispenserBehaviorsfor these items.This fix does not include the use of these items at invalid locations to activate a Nether portal.
Confirmed for 1.9
Still in 1.9.1-pre3
Still in 1.9.2
Still in 16w15b
1. Is this the same bug as when clicking on the top of a non-flammable block?
2. Is the usage of one durability point when doing that also a bug?
3. Would fixing this bug prevent people from causing block updates with flint and steel e.g. on slime block machines?
In case you are talking about a full block on which the fire can stay, no. But I don't think that this is a bug anyways.
Currently it happens also when you are no fire block could be placed. Place for example a fence on a block and right click the top of the block below the fence.
I might create a report for that.It is now MC-105591Yes. For new slime block contraptions people could have a full cube block diagonally below the piston. My personal favourite would be to have the class
BlockPistonBaseoverride the methodnet.minecraft.block.Block.onBlockActivated(World, BlockPos, IBlockState, EntityPlayer, EnumHand, ItemStack, EnumFacing, float, float, float)to notify the block itself. Then the player could update the piston by clicking with any item that does not interact with the block or is not used, or if the player is not holding an item.
Confirmed for 16w42a
@unknown, it was already marked as affected
Sorry I was only looking at the comments not the versions.
Up to now flint and steel was used to update observers manually, but since that fix it won't work. I think that fixing 1-tick fire as bug destroys feature of manual activating observers by flint and steel without placing block. This is used by many youtubers and players. Should I report a new bug with future version affected?
No don't make reports for versions that aren't even released yet, and don't bother after the snapshot is released either. The fix will be the intended behavior, so if you report it, it will be resolved as works as intended really fast.
at least provide an intended alternative for this widely used behaviour without any downsides.
so to summ this up: dont make reports about old versions, dont make reports about not released versions and the version thats full release right now counts to old version already bc mojang is already in the snapshot development. I would realy like to know when its appropiate to make any bugreports at all from you FVBico!
@@unknown That's incorrect, reports for the latest release are always accepted (currently 1.12.2)
so 1.12.2 is still worked on? we both know nothing is going to change in 1.12.2 nor is there gonna be a 1.12.3 especially not since snapshots are beeing worked on i just think its realy funny how 1 moderator on this bugtacker usually makes completly false statements , tells ppl to not even bother making reports etc. if we shouldnt report bugs in snapshots why are snapshots beeing made? whats the point of this bugtracker ?
Please re-read @unknown's comment, he never said that reports for the current release aren't accepted; he just said that reports for future snapshots and releases aren't accepted before those versions are released, and that the new behaviour is very highly likely most definitely probably certainly intended and won't change.
Also, no off-topic comments anymore here, please.
@FVbico I will report that tho. This maybe was a bug based feature, but used worldwide and accepted as a feature that was removed since 17w48a. I can only ask mods to not closing it and leaving it for devs to look at our-gamers problem.
New report:
MC-122651
Not fixed for fire charges, they have the same problem.
As of 18w02a it no longer creates a fire block (it seems), but still triggers observers and BUD pistons.
migrated
I don't think this is a bug. I'm pretty sure that flash of fire is how a nether portal knows it needs to be lit.