The bug
The Fire
tag works in a way that negative values mean an entity is not on fire and positive numbers mean an entity is on fire. 0 is kind of special because when the fire value increase from -1 to 0 the entity is "really" set
on fire for 8 seconds.
For players the default value is -20 acting as 19 ticks of buffer before actually catching fire, for all other entities it is -1 meaning there is no buffer.
The problem is that in some situations the fire value is reset by setting it to 0 instead of the correct default value. This results in situations where a mob or player is standing in fire but not actually catching fire.
How to reproduce
Build a setup as shown in
Place a cow inside the free space and make sure it is in the water
Set the log block, on the side the cow is at, on fire
Remove the water before the cow is dead
→ You will see that the cow is not catching fire, but still takes damageand does not drop cooked beef
Affected methods
These are the methods which reset the fire value not correctly.
Last updated for 20w07a, Mojang names
net.minecraft.world.entity.Entity.clearFire()
net.minecraft.world.entity.Entity.setSecondsOnFire(int)
: Fire protection could result in fire value of 0 (?)
Linked issues
relates to 1
Attachments
Comments 5
Cannot reproduce either in 1.17.1. However, net.minecraft.world.level.block.BaseFireBlock.entityInside(BlockState, Level, BlockPos, Entity)
still has the check for whether the fire value after incrementing it is 0, and some methods, such as net.minecraft.world.entity.Entity.clearFire()
still reset the fire value to 0.
But I cannot tell at the moment in which situations this might cause issues.
I will resolve this report as Cannot Reproduce; please let us know in case you can still reproduce this bug.
Looks like it's now always set to -1 properly in 20w07a.