The Bug
When anything other than iron golems walk on barriers, walk particles don't appear. This makes sense since the block is invisible. What doesn't make sense is the fact that when an iron golem walks on a barrier block, red walk particles appear when I don't think they should.
Steps to Reproduce
Switch into creative mode, give yourself some barriers, and place them down.
/give @s minecraft:barrier
Summon an iron golem on top of the barrier blocks and wait for it to begin walking.
Take note as to whether or not iron golems produce walking particles when traveling over barrier blocks.
Observed Behavior
Iron golems produce walking particles when traveling over barrier blocks.
Expected Behavior
Iron golems would not produce walking particles when traveling over barrier blocks.
Related issues
Attachments
Comments

Can confirm in 20w51a.
Can confirm in 21w03a.
Can confirm in 21w06a.
Can confirm in 21w07a.
Can confirm in 1.16.5 and 21w08b.
Can confirm in 21w10a. Video attached.
Can confirm in 1.17.1.
I am able to confirm this behavior in 21w41a. Here are some extra details regarding this problem.
The Bug:
Iron golems produce walking particles when traveling over barrier blocks.
Steps to Reproduce:
Switch into creative mode, give yourself some barriers, and place them down.
/give @s minecraft:barrier
Summon an iron golem on top of the barrier blocks and wait for it to begin walking.
Take note as to whether or not iron golems produce walking particles when traveling over barrier blocks.
Observed Behavior:
Iron golems produce walking particles when traveling over barrier blocks.
Expected Behavior:
Iron golems would not produce walking particles when traveling over barrier blocks.
I can confirm this behavior in 1.18. Here's a code analysis of this issue.
Code Analysis:
The following is based on a decompiled version of Minecraft 1.19.2 using MCP-Reborn.
net.minecraft.world.entity.animal.IronGolem.java
public class IronGolem extends AbstractGolem implements NeutralMob {
...
public void aiStep() {
super.aiStep();
...
if (this.getDeltaMovement().horizontalDistanceSqr() > (double)2.5000003E-7F && this.random.nextInt(5) == 0) {
int i = Mth.floor(this.getX());
int j = Mth.floor(this.getY() - (double)0.2F);
int k = Mth.floor(this.getZ());
BlockState blockstate = this.level.getBlockState(new BlockPos(i, j, k));
if (!blockstate.isAir()) {
this.level.addParticle(new BlockParticleOption(ParticleTypes.BLOCK, blockstate), this.getX() + ((double)this.random.nextFloat() - 0.5D) * (double)this.getBbWidth(), this.getY() + 0.1D, this.getZ() + ((double)this.random.nextFloat() - 0.5D) * (double)this.getBbWidth(), 4.0D * ((double)this.random.nextFloat() - 0.5D), 0.5D, ((double)this.random.nextFloat() - 0.5D) * 4.0D);
}
}
...
If we look at the above class, we can see that there is only one necessary check that is carried out before allowing an iron golem to produce walking particles. This check is to see if the block below them is air, and if it is, walking particles won't be produced, but if it isn't, walking particles based on the block that the iron golem is standing on will be produced. The game doesn't check the RenderShape
of the block that the iron golem standing on before allowing it to produce walking particles, therefore resulting in this problem occurring.
Fix:
Simply changing some lines of code to check the RenderShape
of the block that the iron golem is standing on before allowing it to produce walking particles, will resolve this problem.
Current Code:
...
BlockState blockstate = this.level.getBlockState(new BlockPos(i, j, k));
if (!blockstate.isAir()) {
...
Fixed Code:
...
BlockPos blockpos = new BlockPos(i, j, k);
BlockState blockstate = this.level.getBlockState(blockpos);
if (blockstate.getRenderShape() != RenderShape.INVISIBLE) {
...
Can confirm in 1.18.1.
Can confirm in 1.18.2.
Can confirm in 1.19 and 1.19.1 Pre-release 1.
Can confirm in 1.19.2.
Following on from my code analysis, I've double-checked my proposed fix and I can confidently confirm that it's fully functioning and works as expected, so I've attached two screenshots to this report, one of which shows the current code and the other that shows the fixed code. I feel this information may be quite insightful hence my reasoning for providing it. 🙂
[media][media]
This does not seem to happen anymore as of 1.20-rc1. Can we find the exact fix version (possibly pre-release 3 as per MC-262505)?
This issue was present in 1.20 Pre-release 2, but no longer occurs in versions above or equal to 1.20 Pre-release 3. This issue was fixed in 1.20 Pre-release 3.