![[Mojang] Gnembon](../../../data/avatars/users/93709.png)
[Mojang] Gnembon
- gnembon
- gnembon
- Europe/Stockholm
- Yes
- No
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
MC-156374![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
Normal
![[Helper] gaspoweredpick](../../../data/avatars/users/80904.png){kind=small}
Mushroom pathfinding favours grass rather than mycelium.
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
{ return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;
In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos)since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution: replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;
replaceto:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;
replaceSideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos)
{ return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 10, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mushroom pathfinding favours grass rather than mycelium.
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
{ return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }
protected Block spawnableBlock = Blocks.GRASS;
In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos)since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution: replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;
replaceto:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;
replaceSideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos)
{ return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 10, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mushroom pathfinding favours grass rather than mycelium.
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
{ return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos)since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution: replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;
replaceto:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;
replaceSideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos)
{ return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 10, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mushroom pathfinding favours grass rather than mycelium.
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
{ return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }
public float getBlockPathWeight(BlockPos pos)since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution: replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;
replaceto:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;
replaceSideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos)
{ return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 10, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mushroom pathfinding favours grass rather than mycelium.
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
{ return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }
public float getBlockPathWeight(BlockPos pos)since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;
this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.Solution: replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;
replaceto:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;
replaceSideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos)
{ return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 10, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mushroom pathfinding favours grass rather than mycelium.
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution: replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;replace to:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;Sideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 10, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mushroom pathfinding favours grass rather than mycelium.
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution: replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;replace to:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;Sideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 10, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mushroom pathfinding favours grass rather than mycelium.
Causes:
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution:
Replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;replace to:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;Sideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:
In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 10, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
M
ushroom pathfinding favours grass rather than mycelium.Causes:
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution:
Replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;replace to:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;Sideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:
In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 10, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mooshroom pathfinding favours grass rather than mycelium.
Causes:
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution:
Replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;replace to:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;Sideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:
In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 10, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mooshroom pathfinding favours grass rather than mycelium.
Causes:
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution:
Replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;replace to:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;Sideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:
In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 1
0, which stays in contrary to the statement in EntityAnimal#122Please and Thank you.
Mooshroom pathfinding favours grass rather than mycelium.
Causes:
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution:
Replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;replace to:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;Sideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:
In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 11, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mooshroom pathfinding favours grass rather than mycelium.
Causes:
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution:
Replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;replace to:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;Sideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:
In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 11, which stays in contrary to the statement in EntityAnimal#122
Please and Thank you.
Mooshroom pathfinding favours grass rather than mycelium.
Causes:
Caused by harcoded use of GRASS block instead of instance attribute, spawnableBlock (MCP for 1.9.4):
In entity/passive/EntityAnimal: #20 (EntityAnimal class):
protected Block spawnableBlock = Blocks.GRASS;In entity/passive/EntityAnimal: #82 (EntityAnimal class):
public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }since MushroomCows redefine their spawnableBlock to mycelium:
In entity/passive/EntityMooshroom: #23 (EntityMooshroom class):
this.spawnableBlock = Blocks.MYCELIUM;this have no effect on their pathing behaviour as the perferred block is hardcoded to GRASS.
Solution:
Replace
In entity/passive/EntityAnimal: #84 (EntityAnimal class):return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;replace to:
return this.worldObj.getBlockState(pos.down()).getBlock() == this.spawnableBlock ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F;Sideeffects of the current state:
Passive mobs are intended to spawn in light levels of 9 or above, as signified by this expression:
In entity/passive/EntityAnimal: #122 (EntityAnimal class):
return this.worldObj.getBlockState(blockpos.down()).getBlock() == this.spawnableBlock && this.worldObj.getLight(blockpos) > 8 && super.getCanSpawnHere();However since mooshrooms will path through grass, the following code takes an effect while spawning on mycelium:
In entity/passive/EntityCreature: #40 (EntityCreature class):
return super.getCanSpawnHere() && this.getBlockPathWeight(new BlockPos(this.posX, this.getEntityBoundingBox().minY, this.posZ)) >= 0.0F;and:
In entity/passive/EntityAnimal: #82 (EntityAnimal class):public float getBlockPathWeight(BlockPos pos) { return this.worldObj.getBlockState(pos.down()).getBlock() == Blocks.GRASS ? 10.0F : this.worldObj.getLightBrightness(pos) - 0.5F; }So instead of light level > 8, what it needs is brightness > 0.5F, which is achieved with light level > 11, which stays in contrary to the statement in EntityAnimal#122
Video with explanation:
https://www.youtube.com/watch?v=sm43geXAgysPlease and Thank you.
Mobs, if crammed in one spot (with maxEntityCramming set to default), will push each other into blocks, which allow them to glitch through them on world load (possibly chunk load).
Not that easy to replicate. Happens 1 in N times, where N is a relatively low integer number.
Attached - 1. before log-out 2. after log-in.
Singleplayer world.
(possibly may be connected with the new entity collisions behaviour with 16w38a)What is different with other similar bug reports is - mobs seem to be in blocks client side only. Relog puts them back into position. Mobs cannot see the player, even it it appears to be outside of the trap, but player can hit them.
When moved by a piston with 2 redstone tick signal, they leave blocks in an improper powered state two blocks away from the observer
#bringUsBackInstantObservers
concrete power metadata is not saved properly when block drops in lazy processing chunks, converting all colors to white.
https://www.youtube.com/watch?v=5D3jSxtJk7Econcrete power metadata is not saved properly when block drops in lazy processing chunks, converting all colors to white.
Video evidence by EDDxample:
Parrots unrestricted spawning causing world to inevitably crash from the number of entities.
Since parrots seem to spawn restricted by hostile mob cap, while they contribute to passive mob cap, this will cause in any world that loads within player range chunks with a jungle biome to crash.
In normal worlds it make take some time, but in general is inevitable, since parrots won't spawn.
I understand the care about existing users which are for the most part not conditioned to passive mob farming using natural spawning, but changing their spawning to follow fully passive mobs would be the easiest, obvious and adequate solution, however the method with ocelots (a.k.a. ozelot) by putting them in the hostile category that spawn in light, on grass and doesn't attack a player, and despawn randomly, would be another solution. Another solution would be to add them to the ambient category (add some company to bats) and make them despawn. Last solution would allow regular hostile mob density in jungle biomes, which is already slightly reduced by presence of ocelots.To replicate:
Create world with jungle biome, works best with superflat worlds for many reasons, and AFK and notice entity count.Video description
(will eventually be published on 31.03.2017):
https://www.youtube.com/watch?v=yvbBhZ2nRdo
Llamas, unlike horses, can be kept feeding hay bales even if in love mode
Information about previous structures (generated in the world) saved in data/*.dat files seem not to load when a 1.12.2 and below world is opened with 1.13 (tested on client and server).
Steps to reproduce:
- Run 1.12.2 client, create a new world, seed 2791111690993685248
- teleport to about 5256.0 65.0 -248.0
- observe guardians frolicking in the autumn mist
- close 1.12.2
- open 1.13 and enter the world
- fly up to Y190 to let the existing hostiles despawn
- descend to Y60
- observer no more guardians to spawn
- confirm the observation typing /kill @e[type
:minecraft:guardian]- sad panda.
The ability to store previously generated structures, even if the newer world generation/format had different opinion about it, allowed for players with stubborn personalities to continue playing in their old and dingy worlds even in the newest and shiniest of Minecraft versions.
PS. Apologies for cutting off their fins and tails - FPS gets 3 times better without them
乁( ⁰͡ Ĺ̯ ⁰͡ ) ㄏInformation about previous structures (generated in the world) saved in data/*.dat files seem not to load when a 1.12.2 and below world is opened with 1.13 (tested on client and server).
Steps to reproduce:
- Run 1.12.2 client, create a new world, seed 2791111690993685248
- teleport to about 5256.0 65.0 -248.0
- observe guardians frolicking in the autumn mist
- close 1.12.2
- open 1.13 and enter the world
- fly up to Y190 to let the existing hostiles despawn
- descend to Y60
- observer no more guardians to spawn
- confirm the observation typing /kill @e[type=minecraft:guardian]
- sad panda.
The ability to store previously generated structures, even if the newer world generation/format had different opinion about it, allowed for players with stubborn personalities to continue playing in their old and dingy worlds even in the newest and shiniest of Minecraft versions.
PS. Apologies for cutting off their fins and tails - FPS gets 3 times better without them
乁( ⁰͡ Ĺ̯ ⁰͡ ) ㄏ
Villagers would pick up beets, and share them with other villagers as food, but they won't use it to get willing and therefore breed.
Inconsistent behaviour. They should either breed with beets, or not consider them in sharing.
Java
Villagers pick up beets, and share them with other villagers like food, but won't breed with beets
if you keep your mouse left button pressed you can mine blocks which you can mine instantly with a tool very quickly. However if you rebind that action to a key on a keyboard - you can only mine blocks once in a while.
Also - if you aim at the air, pressing a mouse key doesn't involve having any extra animations, but doing the same with a rebound keyboard key - keeps "reloading" a tool every half a second or so.
if you keep your mouse left button pressed you can mine blocks which you can mine instantly with a tool very quickly. However if you rebind that action to a key on a keyboard - you can only mine blocks once in a while.
Also - if you aim at the air, pressing a mouse key doesn't involve having any extra animations, but doing the same with a rebound keyboard key - keeps "reloading" a tool every half a second or so.
When pushed via piston from the end to the overworld, shulkers occasionally appear around the world spawn (intended behaviour) or more likely around world (0,64,0) (incorrect behaviour).
What happens:
Shulkers track their position via "attached block" NBT that is copied when a shulker is moved from the end to the overworld. So if it is attached to like (1,64,0) in the end, it will appear in the overworld at world spawn, but with NBT of attached block copied from the end as (1,64,0). If the shulker manages to find a suitable location in his first tick in the overworld, it modifies its "attached block" tag and stays around world spawn. Otherwise next tick its position is reset accordingly to the "attached block in the end":
Proof:
Couple log files of several shulkers pushed via end portal to the overworld:```
[17:44:18] [Server thread/INFO]: gnembon joined the game
[17:44:20] [Server thread/INFO]: Scanning for legacy world dragon fight...
[17:44:20] [Server thread/INFO]: Found that the dragon has been killed in this world already.
[17:44:43] [Server thread/ERROR]:
[17:44:43] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:the_end on tick 518
[17:44:43] [Server thread/ERROR]: - failed to teleport
[17:44:43] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:43] [Server thread/ERROR]: MOVED TO OVERWORLD to world spawn at BlockPos{x=52, y=68, z=77} on tick 518
[17:44:43] [Server thread/ERROR]:
[17:44:43] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 519
[17:44:43] [Server thread/ERROR]: - failed to teleport
[17:44:43] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:43] [Server thread/ERROR]:
[17:44:43] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 519
[17:44:43] [Server thread/ERROR]: - failed to teleport
[17:44:43] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:43] [Server thread/ERROR]:
[17:44:43] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 520
[17:44:43] [Server thread/ERROR]: - failed to teleport
[17:44:43] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:43] [Server thread/ERROR]:
[17:44:43] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 520
[17:44:43] [Server thread/ERROR]: - successfully moved to BlockPos{x=-4, y=65, z=6}
[17:44:43] [Server thread/ERROR]: - attached block NBT: BlockPos{x=-4, y=65, z=6}
[17:44:47] [Server thread/ERROR]:
[17:44:47] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:the_end on tick 595
[17:44:47] [Server thread/ERROR]: - failed to teleport
[17:44:47] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:47] [Server thread/ERROR]: MOVED TO OVERWORLD to world spawn at BlockPos{x=52, y=68, z=77} on tick 595
[17:44:47] [Server thread/ERROR]:
[17:44:47] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 596
[17:44:47] [Server thread/ERROR]: - failed to teleport
[17:44:47] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:47] [Server thread/ERROR]:
[17:44:47] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 596
[17:44:47] [Server thread/ERROR]: - failed to teleport
[17:44:47] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:47] [Server thread/ERROR]:
[17:44:47] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 597
[17:44:47] [Server thread/ERROR]: - successfully moved to BlockPos{x=-7, y=63, z=5}
[17:44:47] [Server thread/ERROR]: - attached block NBT: BlockPos{x=-7, y=63, z=5}
[17:44:47] [Server thread/ERROR]:
[17:44:47] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 597
[17:44:47] [Server thread/ERROR]: - failed to teleport
[17:44:47] [Server thread/ERROR]: - attached block NBT: BlockPos{x=-7, y=63, z=5}
[17:44:50] [Server thread/ERROR]:
[17:44:50] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:the_end on tick 655
[17:44:50] [Server thread/ERROR]: - failed to teleport
[17:44:50] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:50] [Server thread/ERROR]: MOVED TO OVERWORLD to world spawn at BlockPos{x=52, y=68, z=77} on tick 655
[17:44:50] [Server thread/ERROR]:
[17:44:50] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 656
[17:44:50] [Server thread/ERROR]: - failed to teleport
[17:44:50] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:50] [Server thread/ERROR]:
[17:44:50] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 656
[17:44:50] [Server thread/ERROR]: - failed to teleport
[17:44:50] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:50] [Server thread/ERROR]:
[17:44:50] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 657
[17:44:50] [Server thread/ERROR]: - successfully moved to BlockPos{x=-7, y=63, z=3}
[17:44:50] [Server thread/ERROR]: - attached block NBT: BlockPos{x=-7, y=63, z=3}
[17:44:50] [Server thread/ERROR]:
[17:44:50] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 657
[17:44:50] [Server thread/ERROR]: - successfully moved to BlockPos{x=-3, y=63, z=-6}
[17:44:50] [Server thread/ERROR]: - attached block NBT: BlockPos{x=-3, y=63, z=-6}
[17:44:53] [Server thread/ERROR]:
[17:44:53] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:the_end on tick 716
[17:44:53] [Server thread/ERROR]: - failed to teleport
[17:44:53] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:53] [Server thread/ERROR]: MOVED TO OVERWORLD to world spawn at BlockPos{x=52, y=68, z=77} on tick 716
[17:44:53] [Server thread/ERROR]:
[17:44:53] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 717
[17:44:53] [Server thread/ERROR]: - failed to teleport
[17:44:53] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:53] [Server thread/ERROR]:
[17:44:53] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 717
[17:44:53] [Server thread/ERROR]: - failed to teleport
[17:44:53] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0}
[17:44:53] [Server thread/ERROR]:
[17:44:53] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 718
[17:44:53] [Server thread/ERROR]: - successfully moved to BlockPos{x=2, y=65, z=-1}
[17:44:53] [Server thread/ERROR]: - attached block NBT: BlockPos{x=2, y=65, z=-1}
[17:44:53] [Server thread/ERROR]:
[17:44:53] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 718
[17:44:53] [Server thread/ERROR]: - failed to teleport
[17:44:53] [Server thread/ERROR]: - attached block NBT: BlockPos{x=2, y=65, z=-1}
```
Notice inconsistencies between entity position and NBT of attached block
Solution: fix "attached block" to world spawn point when changing dimension to reflect position change.
When pushed via piston from the end to the overworld, shulkers occasionally appear around the world spawn (intended behaviour) or more likely around world (0,64,0) (incorrect behaviour).
What happens:
Shulkers track their position via "attached block" NBT that is copied when a shulker is moved from the end to the overworld. So if it is attached to like (1,64,0) in the end, it will appear in the overworld at world spawn, but with NBT of attached block copied from the end as (1,64,0). If the shulker manages to find a suitable location in his first tick in the overworld, it modifies its "attached block" tag and stays around world spawn. Otherwise next tick its position is reset accordingly to the "attached block in the end":
Proof:
Couple log files of several shulkers pushed via end portal to the overworld:[17:44:18] [Server thread/INFO]: gnembon joined the game [17:44:20] [Server thread/INFO]: Scanning for legacy world dragon fight... [17:44:20] [Server thread/INFO]: Found that the dragon has been killed in this world already. [17:44:43] [Server thread/ERROR]: [17:44:43] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:the_end on tick 518 [17:44:43] [Server thread/ERROR]: - failed to teleport [17:44:43] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:43] [Server thread/ERROR]: MOVED TO OVERWORLD to world spawn at BlockPos{x=52, y=68, z=77} on tick 518 [17:44:43] [Server thread/ERROR]: [17:44:43] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 519 [17:44:43] [Server thread/ERROR]: - failed to teleport [17:44:43] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:43] [Server thread/ERROR]: [17:44:43] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 519 [17:44:43] [Server thread/ERROR]: - failed to teleport [17:44:43] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:43] [Server thread/ERROR]: [17:44:43] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 520 [17:44:43] [Server thread/ERROR]: - failed to teleport [17:44:43] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:43] [Server thread/ERROR]: [17:44:43] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 520 [17:44:43] [Server thread/ERROR]: - successfully moved to BlockPos{x=-4, y=65, z=6} [17:44:43] [Server thread/ERROR]: - attached block NBT: BlockPos{x=-4, y=65, z=6} [17:44:47] [Server thread/ERROR]: [17:44:47] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:the_end on tick 595 [17:44:47] [Server thread/ERROR]: - failed to teleport [17:44:47] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:47] [Server thread/ERROR]: MOVED TO OVERWORLD to world spawn at BlockPos{x=52, y=68, z=77} on tick 595 [17:44:47] [Server thread/ERROR]: [17:44:47] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 596 [17:44:47] [Server thread/ERROR]: - failed to teleport [17:44:47] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:47] [Server thread/ERROR]: [17:44:47] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 596 [17:44:47] [Server thread/ERROR]: - failed to teleport [17:44:47] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:47] [Server thread/ERROR]: [17:44:47] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 597 [17:44:47] [Server thread/ERROR]: - successfully moved to BlockPos{x=-7, y=63, z=5} [17:44:47] [Server thread/ERROR]: - attached block NBT: BlockPos{x=-7, y=63, z=5} [17:44:47] [Server thread/ERROR]: [17:44:47] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 597 [17:44:47] [Server thread/ERROR]: - failed to teleport [17:44:47] [Server thread/ERROR]: - attached block NBT: BlockPos{x=-7, y=63, z=5} [17:44:50] [Server thread/ERROR]: [17:44:50] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:the_end on tick 655 [17:44:50] [Server thread/ERROR]: - failed to teleport [17:44:50] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:50] [Server thread/ERROR]: MOVED TO OVERWORLD to world spawn at BlockPos{x=52, y=68, z=77} on tick 655 [17:44:50] [Server thread/ERROR]: [17:44:50] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 656 [17:44:50] [Server thread/ERROR]: - failed to teleport [17:44:50] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:50] [Server thread/ERROR]: [17:44:50] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 656 [17:44:50] [Server thread/ERROR]: - failed to teleport [17:44:50] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:50] [Server thread/ERROR]: [17:44:50] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 657 [17:44:50] [Server thread/ERROR]: - successfully moved to BlockPos{x=-7, y=63, z=3} [17:44:50] [Server thread/ERROR]: - attached block NBT: BlockPos{x=-7, y=63, z=3} [17:44:50] [Server thread/ERROR]: [17:44:50] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 657 [17:44:50] [Server thread/ERROR]: - successfully moved to BlockPos{x=-3, y=63, z=-6} [17:44:50] [Server thread/ERROR]: - attached block NBT: BlockPos{x=-3, y=63, z=-6} [17:44:53] [Server thread/ERROR]: [17:44:53] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:the_end on tick 716 [17:44:53] [Server thread/ERROR]: - failed to teleport [17:44:53] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:53] [Server thread/ERROR]: MOVED TO OVERWORLD to world spawn at BlockPos{x=52, y=68, z=77} on tick 716 [17:44:53] [Server thread/ERROR]: [17:44:53] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 717 [17:44:53] [Server thread/ERROR]: - failed to teleport [17:44:53] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:53] [Server thread/ERROR]: [17:44:53] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=52, y=68, z=77} in minecraft:overworld on tick 717 [17:44:53] [Server thread/ERROR]: - failed to teleport [17:44:53] [Server thread/ERROR]: - attached block NBT: BlockPos{x=1, y=64, z=0} [17:44:53] [Server thread/ERROR]: [17:44:53] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 718 [17:44:53] [Server thread/ERROR]: - successfully moved to BlockPos{x=2, y=65, z=-1} [17:44:53] [Server thread/ERROR]: - attached block NBT: BlockPos{x=2, y=65, z=-1} [17:44:53] [Server thread/ERROR]: [17:44:53] [Server thread/ERROR]: Trying to teleport, currently at BlockPos{x=1, y=64, z=0} in minecraft:overworld on tick 718 [17:44:53] [Server thread/ERROR]: - failed to teleport [17:44:53] [Server thread/ERROR]: - attached block NBT: BlockPos{x=2, y=65, z=-1}Notice inconsistencies between entity position and NBT of attached block
Solution: fix "attached block" to world spawn point when changing dimension to reflect position change.
Clicking with both mouse buttons on an empty item frame deletes item in hand.
Please check attached reproduction video:
Very bad client FPS when looking at very basic slimestone contraptions
https://youtu.be/E-apKFPM3S0Issue seems to get better when biome blend is disabled, yet still spikes are visible
This causes breakage of the other block at the end. Typically mining another block would cause previous block progress to reset, but it doesn't happen with blocks that break instantly.
As demonstrated in this video evidence
As demonstrated in this video evidence
https://youtu.be/-jtlR-sRJzE
The particles are offset to the side and seem too high:
The particles are offset to the side and seem too high:
https://youtu.be/RCjgYTN4Iw4
https://youtu.be/F8SN7p6FrDI
The effect dissapears when blocks get ~1 chunk close to the player
The effect disappears when blocks get ~1 chunk close to the player
https://youtu.be/CgFnFgHzBmE
Video demonstration: https://youtu.be/0k6QQKSvqtM
Comparing to 1.13 (last time I used this solution) items now not always fall through the following setup. Previously, since gaps between end rods are much larger than item size, they were falling through - now they are getting stuck on end rods. Items also sometimes fall through visually, but revert back due to server side positioning
Video demonstration: https://youtu.be/
0k6QQKSvqtMComparing to 1.13 (last time I used this solution) items now not always fall through the following setup. Previously, since gaps between end rods are much larger than item size, they were falling through - now they are getting stuck on end rods. Items also sometimes fall through visually, but revert back due to server side positioning
Video demonstration:
https://youtu.be/0k6QQKSvqtM
https://youtu.be/mrqTRd3jeZYComparing to 1.13 (last time I used this solution) items now not always fall through the following setup. Previously, since gaps between end rods are much larger than item size, they were falling through - now they are getting stuck on end rods. Items also sometimes fall through visually, but revert back due to server side positioning
Video demonstration:
https://youtu.be/0k6QQKSvqtM
https://youtu.be/mrqTRd3jeZY
https://youtu.be/d9Cy2Qmh8HgComparing to 1.13 (last time I used this solution) items now not always fall through the following setup. Previously, since gaps between end rods are much larger than item size, they were falling through - now they are getting stuck on end rods. Items also sometimes fall through visually, but revert back due to server side positioning
Jugsaw blocks do not disappear post-gen when structure is spawned using the 'Generate' action from an initial jigsawJigsaw blocks do not disappear post-gen when structure is spawned using the 'Generate' action from an initial jigsaw
When spawning a structure from the start piece in a jigsaw block in already fully generated chunks (not proto), jigsaw blocks stay in the structures.
See attached screenshots on how to reproduce
[https://cdn.discordapp.com/attachments/674291887409987625/700121572509483028/2020-04-15_22.29.22.png
] https://cdn.discordapp.com/attachments/674291887409987625/700121602687500389/2020-04-15_22.27.22.png https://cdn.discordapp.com/attachments/674291887409987625/700121572509483028/2020-04-15_22.29.22.pngWhen spawning a structure from the start piece in a jigsaw block in already fully generated chunks (not proto), jigsaw blocks stay in the structures.
See attached screenshots on how to reproduce
https://cdn.discordapp.com/attachments/674291887409987625/700121602687500389/2020-04-15_22.27.22.png https://cdn.discordapp.com/attachments/674291887409987625/700121572509483028/2020-04-15_22.29.22.png
2020-05-03_11.48.52.png
The (not - configured) structure has id "minecraft:endcity" and the struture in the end lists as "minecraft:end_city".
It is now imprtant as worldgen is now publicly accessible via datapacks, not an internal concept
Since all identifiers use snake case consistently, suggesting encoding structure name as 'end_city', the same way you have fixed all instance of 'village_snovy'
Attached screenshots of vanilla world gen json for end_city structure
There are another related issues that point to different identifiers related with end cities:
https://bugs.mojang.com/browse/MC-187911
XP orb entities that collided with the player and were applied to mending, set their xp `Value` to 0, even if the stack `Count` indicates there is more than one orb present in this stack.
Simple solution would be to ignore the rest of xp if its not used in mending and decrease their 'Count' by one, or a more complex would be to 'unstack' that one extra orb with the remaining xp.
See attached analysis and video demo
https://youtu.be/BrVWQKV6uEA
Java 8, Windows 10
Stack trace I got (a few of them):
java.util.ConcurrentModificationException: null java.util.ConcurrentModificationException: null at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1388) ~[?:1.8.0_202] at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) ~[?:1.8.0_202] at net.minecraft.server.world.ServerLightingProvider.method_17312(ServerLightingProvider.java:135) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.server.world.ServerLightingProvider.runTasks(ServerLightingProvider.java:170) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.server.world.ServerLightingProvider.method_17313(ServerLightingProvider.java:108) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.server.world.ChunkTaskPrioritySystem.method_17634(ChunkTaskPrioritySystem.java:58) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.util.thread.TaskExecutor.runNext(TaskExecutor.java:94) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.util.thread.TaskExecutor.runWhile(TaskExecutor.java:137) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.util.thread.TaskExecutor.run(TaskExecutor.java:105) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?]
Using fabric here, but its better that then nothing. Its all from vanilla classes
Stack trace I got (a few of them):
java.util.ConcurrentModificationException: null java.util.ConcurrentModificationException: null at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1388) ~[?:1.8.0_202] at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) ~[?:1.8.0_202] at net.minecraft.server.world.ServerLightingProvider.method_17312(ServerLightingProvider.java:135) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.server.world.ServerLightingProvider.runTasks(ServerLightingProvider.java:170) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.server.world.ServerLightingProvider.method_17313(ServerLightingProvider.java:108) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.server.world.ChunkTaskPrioritySystem.method_17634(ChunkTaskPrioritySystem.java:58) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.util.thread.TaskExecutor.runNext(TaskExecutor.java:94) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.util.thread.TaskExecutor.runWhile(TaskExecutor.java:137) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?] at net.minecraft.util.thread.TaskExecutor.run(TaskExecutor.java:105) ~[minecraft-1.16.4-projectmapped-net.fabricmc.yarn-1.16.4+build.7-v2.jar:?]Using fabric here, but its better that then nothing. Its all from vanilla classes
Lag crash and memory issues when loading of a valid custom dimensions containing igloo above the build limit
The following worldgen datapack causes the POI system to get crazy and the game to explode.
To reproduce
- add datapack
- enter game
- /execute in rift:fail run tp 0 260 0
igloo at -64 260 0 will attempt to place blocks above the build limit messing up POI system with a bed location.
[Mojang] Gnembon![[Mojang] Felix Jones](../../../data/avatars/users/40484.png){kind=small}
[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembonduplicates
is duplicated by
[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon![[Mojang] Moesh](../../../data/avatars/users/10122.svg){kind=small}
[Mojang] Moesh[Mojang] Moesh[Mojang] Moesh[Mojang] Gnembon![[Mojang] Brandon Pearce](../../../data/avatars/users/40932.png){kind=small}
[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon
Important[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon
Vibration particle faces at a constant pitch of about 60 degs, not pointing towards the targetcreate flat world, fly up.
/tp 0 0 0
/particle minecraft:vibration 0 0 0 100 0 0 0 10 10 10 1 100particles create hot mess of waves pointing up regardless where they are flying to.
should be pointing to the center.
![[Mojang] Chi Wong](../../../data/avatars/users/18941.svg){kind=small}
[Mojang] Chi Wong[Mojang] Chi Wong[Mojang] Chi Wong[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] GnembonItems don't respect properties oflowerblockitems dont respect properties of the block they are supported on
[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon
Low[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] GnembonSitting camels pulled by fishing rods aren't moved horizontally and remain sittingin the air
[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] Gnembon[Mojang] GnembonThe bug
Mining lots of blocks at once by holding your mouse while equipped with a tool capable of instamining blocks (efficiency 5 diamond shovel vs dirt, for example) will leave some blocks on the server, but the client thinks they're gone.
This bug can occur on a server running 20 TPS constantly. It only occurs when the time to break a block is instant, e.g. with a diamond pickaxe on Nether rack or high-Efficiency diamond shovel on dirt. While the block in question disappears from the client's view (it is not rendered anymore and is removed from clientside collision), the server says it's still there and pushes the players' movement back when the client tries to move within the block's space. This can be a quite tricky and dangerous situation, especially when taking down a pillar below you: You fall into the ghost block again and again (many times a second) and cannot move. Client and server arrive at no consensus over whether the block is still there or not. Reloading the chunks on the client by pressing F3+A does not resolve this. It can be resolved by trying to place a new block in the old location. This of course fails server-side, the new block is not placed, but the old one reappears client-side. It can also be resolved by rejoining the server.
How to reproduce (with provided structure)
Partwise by franswa
- Download the attached structure bug_instamining.nbt
and place it in the structures folder of your world folder - Stand on the command block, and switch your gamemode to Survival
/gamemode survival
- Press the button
- Hold down the block breaking key (default: left click) and move forward without rotating
→ The red sandstone block became a ghost-block
How to reproduce
See Ghost-block reproduction (1.12).mp4 for the video version
- Build a two block wide sandstone tower
- Give yourself an efficiency pickaxe
/give @p diamond_pickaxe 1 0 {ench:[{id:32s,lvl:5s}]} - Move to the top of the tower and stand in the middle of the two blocks
- Switch to Survival mode
/gamemode survival
- Look at one block
- Hold down the block breaking key (default: left click) and move towards the block you are looking at
→ While falling you get stuck in a ghost block
Code analysis
Based on 1.12 decompiled using MCP 9.40 PRE 1
It looks like this bug is caused by the server thinking that the player is not on ground and therefore cannot instamine a block while the client thinks it can. This can be seen when setting a breakpoint in net.minecraft.server.management.PlayerInteractionManager.onBlockClicked(BlockPos, EnumFacing) for the specific block position where a ghost block will be (see "How to reproduce (with provided structure)") and then following the method calls to EntityPlayer.getDigSpeed(IBlockState).
For lagging servers or clients this another cause could likely be the method net.minecraft.network.NetHandlerPlayServer.processPlayerDigging(CPacketPlayerDigging) which is not sending a SPacketBlockChange packet to resync the block if the block position is too far away from the player.
Suggested fix by [Mojang] Gnembon can be found in fix_miningGhostBlocks.PNG
; explanation can be found in this comment
16w39c reproduction case in MC-108310.
Blocks that are attached to slime blocks can create ghosts blocks if a piston that's receiving a 1-tick pulse pushes the slime block
This very short video explains everything:
https://www.youtube.com/watch?v=HH_FlU6wZW0
To reproduce, download the attached test world (bug_world_MC-54026.zip), press the button to let the machine go up, and then press the upper button for it to go down. Repeat until ghost blocks occur.
World with example contraption provided. It may be necessary to increase the height of the thing to get it to bug out. I've only ever seen it occur on the way down.
There is a button on the bottom for it to go up as well as at the top to make it go down. Movement is triggered by block updates so if you do something to block its path and it stops moving, just place and break a block near the BUD switch and it will start moving again.
Suggested fix by [Mojang] Gnembon can be found in fix_pistonGhostBlocks.PNG
; explanation can be found in this comment
The bug
When I was feeding my horses with golden apple, which are tamed and named, I expected that they would just open their mouths to show happiness. But the cursor instantly moved to the right, moving out of focus. I did not see if they accepted the apple.
How to reproduce
- In creative mode, summon a horse.
- Tame the horse and name it.
- Put golden apple in your hotkey.
- Right-click the horse while the golden apple is in hand.
Note that this is not MC-61535.
Code analysis
Code analysis by Marcono1234 can be found in this comment.
Suggested fix by [Mojang] Gnembon can be found in fix_chestHorseChangingDirection.PNG
; explanation can be found in this comment.
The bug
When a player, while wearing no armor, affected with the Invisibility effect, hostile mobs will still target and attack the player as normal.
In /gamemode survival the following mobs will attack the player:
- Unprovoked: Guardians, Elder Guardians, Blazes, Ghasts, Wither Bosses, Phantom, Shulkers
- Provoked (hit): Creepers, Skeletons, Zombies, Spiders, Cave Spiders, Silverfish, Endermites, Endermen (not when looked at, but when hit), Zombie Pigmen, Wither Skeletons, Shulkers (stops attacking after a bit)
- Ignore you even when provoked: Slimes and Magma Cubes
Have even seen some mobs, under some circumstances trying to attack while in /gamemode creative or /gamemode spectator, while affected with the Invisibility effect. However not always.
Code analysis
Code analysis by [Mojang] Gnembon can be found in this comment.
[Mojang] Gnembon Also, read last line:
| This behaviour disallows setting this gamerule to "when anything touches anything, suffocate them" by giving value of 1. |
As mapmaker, if you want to make use of it without having to set up a CB-apparatus for it, this would mean that "works as intended" as you suggest (of course absolutely unselfishly) is not an option, as it would allow 2 mobs at one spot, if set to "1", like the OP wrote.
If we have to have this gamerule per default now in 1.11 (which I absolutely object by the way, it should be off by default from my perspective), then at the very least I want to have it accurate so it's at the very least usable for mapmakers.
The bug
Witches that have drank a fire resistant potion will no longer despawn if they are farther than 32m from a player but less than 128m from a player.
Hostile mobs normally despawn over time when farther than 32m but less than 128m from a player. Witches that have not drank a fire resistant potion will follow these rules. But if the witch drinks a fire resistant potions it will no longer follow these rules.
How to reproduce
- Place a witch inside a glass box with it standing on a magma block or lava. (see picture)
- Move the player 40m away from the witch.
- Wait indefinitely for the witch to despawn.
May also work with any potions the witch drinks.
These witches will still despawn if the player goes farther than 128m from them.
Code analysis
Code analysis by [Mojang] Gnembon can be found in this comment.
@[Mojang] Gnembon it would need to be net.minecraft.item.ItemStack.EMPTY since the method TileEntityBrewingStand.isItemValidForSlot(int, ItemStack) tests for reference equality. I hope the code analysis in the description describes this correctly and you can agree with the suggested fix.
@Timothy Miller the main problem seems to be a disagreement about wether the player is on the ground or not. The client thinks it is letting you instantly mine a block while the server says the client is in the air which slows down the dig speed and prevents instant mining.
Regarding [Mojang] Gnembon's "fix", I would rather call it a hack. If I recall this correctly it marks the block as changed for all players instead of only the one mining and does this everytime you start mining. A proper fix would probably be to have the client tell the server that it thinks it just instantly mined a block.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
The bug
Drowned causes the game to randomly crash.
A code analysis by [Mojang] Gnembon can be found in this comment.
This is not completely fixed in 1.13-pre10
As [Mojang] Gnembon commented, this affects "all living entities" ie: mobs and players. Players still slow down in lesser water levels. This is inconsistent with previous versions.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
This bug was showcased in this video by [Mojang] Gnembon: https://www.youtube.com/watch?v=3ZEY-lWgfdc
The Bug
Some Mojang employees are not mentioned in the credits anywhere yet, including but maybe not limited to:
- [Mojang] Harald Johansson (Game Developer - Consultant) (LinkedIn)
- [Mojang] Oscar Åkesson (Gameplay Programmer) (LinkedIn)
- [Mojang] Gnembon (Senior Game Developer) (Twitter)
- [Mojang] Timur Nazarov ( ? )
- [Mojang] Pavel Grebnev (C++ Developer) (LinkedIn)
- Åsa Bredin (Head of Engineering) (LinkedIn)
- Mariana Salimena (Concept Artist) (LinkedIn)
- Veronica Ericson (Talent Acquisition) (LinkedIn)
To Reproduce
1. Extract the .jar file.
2. Go to the assets/minecraft/texts folder and open credits.json.
3. Use Ctrl + F and attempt to locate said employees' names.
Observed Result
The Mojang employees are not present.
Expected Result
The Mojang employees would be credited.
Can confirm in 1.18 Pre-release 1. I think that [Mojang] Gnembon would want to say something about this bug.
Oh [Mojang] Gnembon... 
Duplicate of MC-248249.
EDIT: I call that a tie!
Hi [Mojang] Gnembon; I've done some even further testing and have discovered a few things I feel are worth informing you about. 
The fix introduced in 22w14a only appeared to fix this issue with the "city_center_2" structure and both "city_center_1" and "city_center_3" still remain an issue. It's important to note that "city_center_2" is the only structure out of the three city centers to generate with a chest containing food, however, the sculk sensor mechanism used to open the piston doors is present in all three city centers, therefore persuading me to believe that the intention of how you're supposed to open the door is by eating around the top of the redstone room (in all city centers), despite only one of the city centers supplying you with a chest.
If this assumption is correct, the "city_center_1" and "city_center_3" structures still don't consistently detect the vibration that's created through the player eating. To visually show the issue here and to reinforce my claims regarding how "city_center_1" and "city_center_3" still remain issues, I've attached 3 videos demonstrating the difference in behavior across all three city centers.
MC-249800 - city_center_1 Behavior (22w15a).mp4
MC-249800 - city_center_2 Behavior (22w15a).mp4
MC-249800 - city_center_3 Behavior (22w15a).mp4
As you can see, the sculk sensor within the "city_center_2" structure reliably and consistently detects the vibration of the player eating just above the redstone room, whereas with "city_center_1" and "city_center_3", this isn't the case.
I hope this information is helpful.
[Mojang] Gnembon If this is reopened, should MC-249190 and MC-250921 also ne reopened for the same reason, or are they not in a state of disparity?
I'm pretty sure that the resolution of this ticket should be reconsidered and resolved as "Working As Intended".
This comment by [Mojang] Gnembon made on MC-249204 states that:
spawn protection is about player interactions. Sheep can get hungry and eat grass, same sheep can die and spread sculk.
I'm pretty sure that the resolution of this ticket should be reconsidered and resolved as "Working As Intended".
This comment by [Mojang] Gnembon made on MC-249204 states that:
spawn protection is about player interactions. Sheep can get hungry and eat grass, same sheep can die and spread sculk.
I can confirm this behavior though this is highly likely to be "Working As Intended" based on this comment by [Mojang] Gnembon.
Indeed, the center 3 uses 'ancient' redstone thus we have decided for the players to find it out broken and fix it. The door still causes an audible noise with pistons when triggered even if it's in it's broken state, so it still leaves a designed feedback of the secret room existence.
That is separately tracked at MC-225175.
Given the resolution of MC-249204, MC-224203, and MC-224867, it is highly likely that this behavior is working as intended despite the assigned "Mojang Priority". This comment from [Mojang] Gnembon states that spawn protection is supposed to prevent any kind of player interaction, and since lightning can naturally hit spawn protection, this is most likely intentional behavior.
[Mojang] Gnembon that appears to be a different issue, this issue is about the baby villager spawning in a wall, causing it to suffocate.
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
In your own test, this is working as intended. See this comment by [Mojang] Gnembon
It is important to recognize that placement of a sculk vein is required for the sculk vein to spread thus sculk blocks to spread. Second important point in sculk design is that charges can only jump to sculk vein or sculk blocks.
Basically; sculk charges can only travel through sculk. Since the top face of the catalyst is considered sculk, it is able to spread to blocks directly up and over the catalyst, and then further to other blocks. This video shows what I mean:
2023-11-06_15-35-49.mp4
(Notice how the sculk doesn't spread until the veins allow it to)
then they shouldn't spawn more than 128 blocks away from a player. I think it is still an undesirable feature (or bug) as player may not be in control of mobs spawning in the spawn chunks while operating a passive mob farm. So far the rule of the game was that mobs only spawn within 128 blocks from the player - skeleton traps is the first exception from that rule. Overall - it is much more an annoyance, then a cool new feature, but that's just an opinion.
BTW - Enderman do count towards hostile mobs, while being neutral to the player, unless they perform some action. The same applies to horse traps.
Thus, I recommend reopening as an issue (bug).
I have watched James Koon's videos and did some of my own testing, and did some reading over the MCP 9.31 code. Since entire teleportation and changing dimension code is only executed server side, and client is not informed about changing of the coordinates, it might be the case, that the player enters the other dimension at a correct location (A), then client updates player position to (8*A or A/8), clients last known location (for one tick), then server decides to move the player back ('Player moved wrongly' message). It might be just client server dissynchronization issue. It is visible on James Koon's videos, that from the other account perspective (thus not linked with the client of the first account) other account lands on the portal, then moves via clients request to the old coords and then is moved back by the server the third time.
Yep - happend to Xisuma on his stream. crashed the game while going thrgouh the portal and the server were not able to correct his position ('moved wrongly' massage) and end up in the exact coords of the overworld, but in the nether.
https://www.youtube.com/watch?v=-Y6ygA6NiNI
I kindly attached the repercussions of alligning hopper cooldown with global clock (see the attached 1.10 and 1.11 images), This causes, as Panda4994 indicated - dependency of comparator response based on when a hopper receives an item, thus making hopper response time unreliable.
Another possibility I could suggest to solve the issue mentioned in this bug report would be to allign the cooldown of hoppers on chunk load, and then leave them be. This should fix the reported bug, as all hoppers will be loaded aligned to the same central clock when chunks are loaded (in any order), but would keep their response with 1-tick resolution.
It would be really awesome, if, like in the previous bug report, you could give us a small, one sentence, explanation, what is the new behaviour, and how it was fixed.
Suggested - works as intended. maxEntityCramming tells with how many other mobs a mob can collide, so the value of 24 means one mob can collide with other 24, so there can be 25 in one spot.
Its a different issue - I would request to reopen the case. What is different in this case - mobs seem to be in blocks client side only. Relog puts them back into position. Mobs cannot see the player, even it it appears to be outside of the trap, but player can hit them.
blocks that give strong power were always updating up to two blocks away (like repeaters), and weak power ( for instance redstone blocks) - one block away. That's how pistons were informed of a change. The rule was simple. Now it seems that devs try to make complex rules what can and what would not update in which situation. This doesn't seem like a great idea (complicating things, rather then simplifying).
Its not the same issue. Other bug report was about mobs attacking you when you aggro them and is present since forever. which might be WAI to be honest. This reported bug here appeared in 1.9, connected with the feature where certain mob heads worn instead of armour reduce their detection range.
Because of that new feature some code got shuffled to different places and because guardians override nearestAttackableTarget (they also attack squids, not only players) the code that checks for target potion effects etc. got detached from guardian class.
In this case guardians would attack you even if not engaged.
bottom line - the bug that this got attached to is unrelated, got introduced in a different version and arguably the other (parent) bug could be treated as WAI. This is straight up bug.
I would suggest reopening it and fixing it, as it is pretty annoying.
If I could only suggest not to use the proposed fix that was applied to the forge version a few posts back. The true reason why this doesn't work is not because hoppers cannot place items inside brewing stands, but because when hoppers pick up items from containers, they leave 'air:0', instead of 'air:1' which doens't match the definition of empty inventory slot, which is 'air:1'. Currently this bug only affects potion brewers, but if not fixed properly and just patched, it may cause problems in the future. Just make sure that hopper leaves 'air:1' for empty inventory slots, and current brewer code will work as expected without changes to it.
That's what happens when you add a feature without proper testing if it affects other things. Its when they changed player detection mechanics related with introduction of the feature where wearing certain skulls decreases detection range for certain mobs (e.g. wearing zombie, creeper and skeleton heads). Some pieces of code got moved where it shouldn't be and now player detection is kinda broken (i.e. guardians would also detect you through sugarcane, and they shouldn't, according to 1.8) (check mob targeting functions in all the subclasses of mobs).
If there was a test to make sure previous mechanics work, it wouldn't be released in this shape.
Stack overflow via recurrent function call
suggested fix added to the Attachments. Since Client and Server are disagreeing about player speed, updating the client while they are mining the block makes sure client is always informed by the final state of the block, regardless if the client thought they mined it or not.
suggested fix for the bug added to the Attachments. Since Client and Server can end up disagreeing about the status of the piston extensions, updating the client about the blocks left behind removes this dissynchronization.
Suggested fix attached. The problem is that llamas and AbstractHorse behaviour with food and mating is different and llama's code is missing one statement (see highlighted added case in the files). Replicating horse code makes both behaviours equivalent therefore consistent.
Like Xcom explained, I added suggested change in the Attachments. This is only proof of concept solution. Since Llamas and Donkeys as subclasses that use different breeding food items, it is recommended that the call to isValidBreedItem is left abstract in the AbstractChestHorse and is defined as true for Hay blocks in Llama class and true for golden carrots and golden apples for example for Donkeys. Only breedable food items need to be specified.
How it is implemented its up to the devs. This solution is very simple. Going one execution step deeper, you could notify only the proper event listener (not all of them) in World.java, or do it client side, by client reconfirming the block they mined. Its all about the source of the issue - lack of ACK after block is mined.
Indeed this works! I was initially suspecting some more crazy stuff causing it, but the hopper code seemed to be clean, and the actual reason happened to be more trivial than everybody suspected. since tileEntitiesToBeRemoved is only populated via calls from chunk unloading, clearing this list before entities get processed makes sense, and I don't see where this might cause other issues. I was always reluctant in moving stuff around and how they are executed within the tick, but this change makes absolute sense.
I tested it quite thoroughly, and seems like there is no hopper duping happening with this fix.
woudn't just changing the entity width and height from float to double fix the issue? The casting from float to double in setPosition would be the culprit? This way entity AABB should be recreatable from NBT with position and double width.
Adjusting the offset when spawning the entity in the portal accounting for that entity width would fix the issue. Currently if the portals have different widths exit portal position may cause AABB to intersect with the Obsidian frame. Still even if mobs are placed in the middle of the portal, player can still push them into the obsidian somehow, but that's another story.
In the following video: https://www.youtube.com/watch?v=flXSpm5e5QM&feature=youtu.be&t=1377 I suggested the following solution, and here I will argue why in my opinion it solves the problem in a simple and elegant way
"Let fire schedule these fully random ticks (30-40 ticks apart) only if it is not a permanent fire (on netherrack, magma blocks, or bedrock in the end)"
Why effective - the purpose of random ticks scheduled with fire is so fire spreads much faster than randomTickSpeed allows, It makes sense if you light a tree on fire, but with the nether - doesn't make too much sense - the permanent fire won't go away, and won't spread to netherrack, but it still ticks. Fight a few ghasts, and the entire area around you will start tick like crazy "forevar and evar".
If we allow permanent fires to tick only via global random ticks, they will be limited in number, and happen typically only as random ticks do, within 128 blocks of a player (there are a few exceptions in the code, but that's not that important atm). This way when played with render distance of 10 and above, they should not cause any random chunkloading issues, and even with lower render distances, 3 attempts per tick is not sufficient to cause the entire chunk to tick.
The fire from these fires will still spread, in the same speed it spreads from lava, so lighting a portal through them would still be possible.
And the last point - the change would be minimal to the code. The Fire block already determines if it is permanent before it calls to shedule the tick, so replacing:
to:
where flag is defined earlier already as:
I think this simple change could improve greatly performance of the game especially in the nether, without affecting too much existing game mechanics.
BTW, for these who would want to check how this works, I added an option to the carpet mod in 17w38a release as /temprule calmNetherFires true/false which can be toggled and tested, but anybody who has access to the code or MCP, should be able to easily replicate this solution.
Also the previous proposed fix to check if the area is loaded within +-32 blocks might be too taxing on the game.
This can be observed easiest with Witches as they drink their own potions, but it is affecting all mobs taking any damage they are not eligible to be taking for whatever reason (fire is the most obvious) (apart from general invulnerability, like blazes).
Reason:
Mobs despawn outside of the 32 block player radious randomly when their Entity.age (MCP 1.12 names) reaches 30s (600ticks) and RNG gods are against it. The reason why witches are not despawning is because in the EntityLivingBase.attackEntityFrom function the first thing that's set is Entity.age = 0 which I suppose is meant to refresh mobs AI tasks allowing them to wonder but as a side effect their despawn timer is reset as well. The problem is, that an entity damage can be voided within this function, yet still their age is reset. So a witch standing in fire, or magma blocks is attempting to take fire damage every tick which is voided due to their fire resistance effect, but this sets their age to 0 anyways. This is not desirable as the entity carries no sings of taking damage.
Solution:
I propose removing "this.entityAge = 0;" from beginnign of EntityLivingBase.attackEntityFrom and move it further down just after:
or even together with playHurtSound call. The reason is that's where entity takes a visual damage (tint is changed to red, hurt sound is played) which is much more intuitive that this entity woul not despawn for the next 30s from this point.
The reason for this behaviour is that in 1.9 the check for invisibility has been moved from entity.ai.EntityAINearestAttackableTarget to world.World.select_closest_player_to_attack or something like that and placed code that handles wearing skulls and their effect on the detection distance in this place.
The target selection (based on the supplied predicates is called in three if-else clauses in EntityAINearestAttackableTarget.shouldExecute()
This code works fine IF the class of entities to target is specified as Player, and many mobs has it this way even having many adversaries:
Zombie:
However Guardian doesn't have it specified as EntityPlayer.class but rather as a custom predicate:
replacing single AI task with two calls, like with Zombies, would be a quick fix but removes the ability for players to avoid guardian attacks hiding within a flock of squids. The proper fix involves reorganizing the shouldExecute() function so it checks properly for things that getNearestAttackablePlayer does:
/** * Returns whether the EntityAIBase should begin execution. */ Add a comment to this line public boolean shouldExecute() { if (this.targetChance > 0 && this.taskOwner.getRNG().nextInt(this.targetChance) != 0) { return false; } else if (this.targetClass != EntityPlayer.class && this.targetClass != EntityPlayerMP.class) { List<T> list = this.taskOwner.world.<T>getEntitiesWithinAABB(this.targetClass, this.getTargetableArea(this.getTargetDistance()), this.targetEntitySelector); if (list.isEmpty()) { return false; } else { Collections.sort(list, this.theNearestAttackableTargetSorter); - this.targetEntity = list.get(0); - return true; + if (!((list.get(0) instanceof EntityPlayer))) + { + this.targetEntity = list.get(0); + return true; + } } } - else - { + //CM removed condition - if previous block executes it always exists unless its a player that got selected this.targetEntity = (T)this.taskOwner.world.getNearestAttackablePlayer(this.taskOwner.posX, this.taskOwner.posY + (double)this.taskOwner.getEyeHeight(), this.taskOwner.posZ, this.getTargetDistance(), this.getTargetDistance(), new Function<EntityPlayer, Double>() { @Nullable public Double apply(@Nullable EntityPlayer p_apply_1_) { ItemStack itemstack = p_apply_1_.getItemStackFromSlot(EntityEquipmentSlot.HEAD); if (itemstack.getItem() == Items.SKULL) { int i = itemstack.getItemDamage(); boolean flag = EntityAINearestAttackableTarget.this.taskOwner instanceof EntitySkeleton && i == 0; boolean flag1 = EntityAINearestAttackableTarget.this.taskOwner instanceof EntityZombie && i == 2; boolean flag2 = EntityAINearestAttackableTarget.this.taskOwner instanceof EntityCreeper && i == 4; if (flag || flag1 || flag2) { return 0.5D; } } return 1.0D; } }, (Predicate<EntityPlayer>)this.targetEntitySelector); return this.targetEntity != null; - } + // removed condition }This allows for AI tasks that does call for a broader class than EntityPlayer, use proper player target selection method if a player got selected across all specified mobs.
Othe approach that can be taken would be to put all the universal checks for detection radius for all targets (like wearing a skull, or having invisibility) in one place and check it for all targets. It would be a better approach because then invisibility potions or wearing skulls would work on other entities as well (i.e. villager wearing zombie skulll will be less prone to attract zombies, or golems will not target invisible Zombies), which is not the case currently.
I tested with other mobs listed in this bug report and they were not affected by this bug from my testing. However organizing better the target selection code would help solve these unknown cases and prevent problems in the future.
If I may add to the discussion based on my observation based on using this fix for extended time. Sending updates to the client while a player mines a block is a way to prevent this issues, however the update that the block is still there occasionally reaches the client after they mined it, which sometimes causes flickering of the blocks after they got mined:
Currently the server only knows only about the current block mined by the client, and doesn't do anything when a client starts mining a new block.
The "proper" fix in this situation would be to let the server keep track of the previously mined block and the current mined block. If a player aborts mining of a current block server side and moves to the other block, the previous block could be safely updated with no flickering effects (its either still there client side, client just skimmed over a block to mine something else), so update will have no effect, or it is actually mined client side, and is a ghost block and needs updating).
Another approach - server can assume different scenarios when client reports new block mined. Most if not all ghost blocks come from the situation where player is standing client side (faster mining speed) and floating server side (jumping, ladder, what have you). If player abandons mining a block ss, and had mining penalty ss, the server can compute time it would have taken the client to mine it without penalty, and if it would be possible - send a preventative update to the client.
Both of these solutions would fix these typical scenarios with minimum required updates sent to the client and it woudn't cause any extra visual flickering client side.
Bottom line: even occasional flicker feels much better than dealing with these pesky ghost blocks.
I did verify it code-wise with 1.12. For obvious reasons didn't verify it under 1.13
here is the partial solution that I implemented (names based on MCP 9.40 pre1)
Location: world/Teletporter.java#placeInExistingPortal
its a partial fix - fixes offset in X and Z dimentions, not the Y. In essence translated offset in the exit portal doesn't account for enity width/height which may end up it spawning inside obsidian blocks.
Side note - I presented the fix in a video of mine with a poll (along other fixes and QOL improvements and this one got the most upvotes)
added simpler case, just with one rail. Seems like rails either reorient or change power, but not both.
I added screenshots what happens if you create a world with said seed and tp to said location for each version separately (18w07c and 1.12.2). 18w07c didn't create Monument.dat file yet the monument generated when teleported to this place. Did the location of saved structures changed?
I concur, however technically fishes despawn, so the issue is more less similar to ocelots - which are not restricted. The issue in this case is that it seems they spawn with water mobs, and count towards passive, so spawning is not every 20s, but every tick, so while technically they would despawn, they would build up within couple of seconds into thousands crashing the game anyways. They should count towards the water mobs cap no doubts.
Parrots crash was slow but inevitable, as they didn't despawn. Ocelots can still crash the server but its slow and requires special arranement of spawn conditions (only allowing spawning withn 24-32 range). Fish covfefe should not happen in normal worlds (but as long as you make a water tank above the oceans at build limit (no squids spawning, so no spanwing restrictions) you can crash the game within minutes maybe)
by analyzing decompiled sources of 18w11a, I managed to track down that afn and afj classes both descend from afk class, which happened to map to net/minecraft/pathfinding/PathNavigate in 1.12 and afn and afj to zb and zf in 1.12 source, which is net/minecraft/pathfinding/PathNavigateGround and net/minecraft/pathfinding/PathNavigateSwimmer. Seems like zombies AI tasks are wrongly mapped between these two subclasses.
The error happens in the equivalent class of net/minecraft/entity/ai/EntityAIDoorInteract (wu in 1.12)
based on the lines and code structure, this happens when Drowned tries exexute this statment (attached screenshot)
Got same error while cloning "replace move" an area that contains hoppers by two blocks
java.lang.IllegalArgumentException: Cannot get property bph{name=facing, clazz=class en, values=[north, east, south, west]} as it does not exist in Block{minecraft:hopper}java.lang.IllegalArgumentException: Cannot get property bph{name=facing, clazz=class en, values=[north, east, south, west]} as it does not exist in Block{minecraft:hopper} at boe.c(SourceFile:95) at cyk.a(SourceFile:71) at cyi.a(SourceFile:148) at cyi.a(SourceFile:128) at cwh.a(SourceFile:694) at cwb.b(SourceFile:984) at cwb.a(SourceFile:893) at cwb.a(SourceFile:753) at ciq.c(SourceFile:814) at ciq.a(SourceFile:379) at net.minecraft.client.main.Main.main(SourceFile:144)Client crashes, server is ok - reports player logged out.
RIP waterstreams in cold biomes. pic attached
Yes, I did rebind it to Q. I have to check. If that's the case I guess the case is closed. But I used the same setup (with Q) in 1.12 with no problems. I guess it might be a recurring issue.
Ok, checked with other keys - all react the same way. It would be nice actually if different keys had different repeat pattern, but currently you can only achieve continous press with the actual mouse...
Affects all living entities and the speed of being pushed seems to be dependent on the immersion, like a creeper that tries to float up in the 2 high tunnel gets stuck in the middle of the stream right around water level 4.
But why 5 days before scheduled release? Eh...
introduced primarily in pre-3
its already resolved in 1.13. I just didn't have a chance to give it a proper test to verify, that it is the case, but it is already changed in code.
Its rather when they are trying to move over to the endermite. (might be leaves messing up with the pathfinding, dunno).
Still in 1.14.1 pre1 - see attached screenshot and profiler dump
To overcome high memory turnaroundn and high CPU usage problem in creating mobs, I propose to use a level-specific cache of one mob per mob type and until they are not spawned, they remain in the cache, and get reused to check the spawning conditions.
On top of that, to combat high CPU requirements to measure block collisions, since most worlds are created mainly with solid and 'non-collidable' blocks, I propose an extra check if a spawn mob is in a non-collidable area. This on the other end is very cheap and allows to accept most cases quickly.
You might need to test this solution, but I don't think its incorrect:
https://youtu.be/hxWk72xfAjY
The following test were performed based on this partifular modification to the source code.
To add some data points to the discussion: run simple experiments in a regular world and 1 high flat world. Spawning cost in tested environments were using 1.3% and 62% of the 50ms tick. After fixing these two solutions: 0.74% and 7.2% respectively.
This is WAI. Since light went to its own thread, spawn algorithm uses a different heightmap to determine topmost spawnable block as the top block that is not air, rather than top block that is not transparent. There is no other heightmap that the spawning algorithm could currently use. That change was deliberate and intended. Just remove all the blocks above your farms and not worry about it.
here is another demo:
https://youtu.be/pTMX3hX7mZE
Well, just happened randomly when I was testing some datapack driven world generation. The inspecting of the stack trace revealed that it has nothing to do with modding in this case, and I thought if might be helpful to post a stack in here - should be fairly easy to find that spot in the original code and inspect for potential concurrency issues.
As most issues with concurrent stuff - they are sparse and far in between and hard to catch.
The only thing, as I said, that might be relevant is I was running a heavy worldgen datapack in that world. (Starmute terralith) that may have exposed some issues with lighting chunks
a renamed biome to a new one causes that as well - don't need to have a configured structure feature.
With this one / attached happens almost immediately and spams render thread:
Attached dimp2n14.zip datapack with renamed biome with one configured feature to replicate.
This also happens when a dimension defines a lower bounds than a previous usual 0-256, for instance the following datapack (attached) requests height to be limited to 160 blocks, and that crashes vanilla feature decorators. dimn10n8.zip
After dissecting the issue and the json file, figured out what's going on:
That was very helpful. Thank you.
Won't happen for 1.18 due to closeness to the release
its happening in 1.18.0, so its an old problem and not 1.18.2 critical
Sculk spreads through veins eating into blocks they are attached to. If the spread is blocked, sculk cannot take over.
Yeah, but its far enough not to cause any extra damage. The ticket author was concern about the damage that lava can make. There is lava at the bottom of the world in random caves, There is ancient cities at the bottom of the world as well. Not seeing anything weird about it. Floating column would be a different issue and I would guess we won't be looking into that.
This is intended behaviour. It is important to recognize that placement of a sculk vein is required for the sculk vein to spread thus sculk blocks to spread. Second important point in sculk design is that charges can only jump to sculk vein or sculk blocks. If you kill a mob on a platform of dirt with buttons on top, it will not spread the vein thus charge will not persist. If you kill a mob on a platform on sculk blocks with buttons on top, vein will not place, but sculk charge would be able to move to it via adjacency rules (so not obstructed with solid block faces), it will be able to move and continue roaming through sculk.
The intent is for players to interact with the chest, eat and notice piston noises around the top of the redstone room - like with two other entrance contraptions. The doors are hidden and covered with other structures, and not meant to be open while standing at the bottom of the structure. Fix provided with 22w14a should give enough space to trigger the entrance mechanism reliably.
spawn protection is about player interactions. Sheep can get hungry and eat grass, same sheep can die and spread sculk.
We have decided for non-living entities to not really emit killed events
You are correct, Sensors are 'off' in the flat worlds due to special treatment of block layers in flat worlds only. This is not a new issue since the same is happening if you create a world of hoppers for example. This is still a valid issue, just more general and not isolated to sculk sensors.
The other issue is saved state of sensors in structure files. Sculk sensor is one of those annoying blocks that need some extra manual treatment, for example removing of last vibration data to work properly. This is similar to other blocks of this type, like loot chests, with the extra care here that sculk sensors cannot be tripped before saving, or need to be cleaned manually afterwards.
Reopening since its still in disparity between bedrock
In both of those cases provided the center structure is not take over by aquifers and properly immersed in deep dark. At this point we have decided not to restrict structures more than it needs to be to keep the center structure dry. The following examples are within parameters we have set for the ancient cities. At this point, the placement of these ancient cities is working as we have intended.
There still IS a possibility for center frames to be submerged, but it should be extremely rare at this point.
Indeed, the center 3 uses 'ancient' redstone thus we have decided for the players to find it out broken and fix it. The door still causes an audible noise with pistons when triggered even if it's in it's broken state, so it still leaves a designed feedback of the secret room existence.
also bedrock doesn't have the camel to tilt their head when getting out of cooldown
When setting camel LastPoseTick to a very large number (i.e. future) there are certain bits of camel logic that take effect:
I would add one extra bit:
What is not WAI is incorrect player position on the camel. Player should always be position where the saddle is visually located. This will be fixed for this ticket.
The item seems to slide on the ice only - I don't see any other blocks underneath.
The bug report is valid
Seems unrelated to mc-1133. Present in 23w17a where no changes were made towards fixing mc-1133.
Bug is still valid though
Please provide seeds of the problematic worlds
Thanks for the seeds - all will open correctly now.
Can't replicate while making sure I don't spring forward in mid air. I can't even make a 3 block jump without sprinting.
As weird as it is, sprinting can be 'added' when mid air. Can you confirm you have done this without engaging sprinting?
Won't Fix isn't a promise to never fix, it just means it is not currently planned to get fixed
As per https://bugs.mojang.com/browse/MC-260034 and bedrock parity
Camel hooks to the groun unless you lift it, it won't budge.
Seems fixed as of 1.20
The problem seems not to occur anymore. or more concrete examples are needed to replicate the problem.
Testing a few usecases verified its no longer a problem.
If there is a reproduction scenario given current production (not snapshot) version of the game, please provide seed and position. For now it is considered fixed.
Is correct. Affects chest loot in various structures
Attached another village with only baby villagers in it.
This is intended as per https://www.minecraft.net/en-us/article/minecraft-snapshot-23w33a
This is intended as per https://www.minecraft.net/en-us/article/minecraft-snapshot-23w33a
The mount of a mob now extends its horisontal reach to match mounts hitbox.
We have decided to address this by adding a new gamerule that can be switched on an adventure map. Its called `projectilesCanBreakBlocks`
Piglins react to players breaking chests and things that look like chests from their point of view. The Decorated Pot is not a part of this set, so we see this as a feature request and not a bug
Please confirm if it is still an issue in 1.20.3-pre2
Will include the wolf collar for non-reddness.
I confirmed
Counter that with a pack of 5
/execute in minecraft:overworld run tp @s -47920.85 104.54 -1335.56 -1401.82 26.70
same seed
Pack of 4-8 unfortunately means 4-8 attempts not guaranteed mobs.
Cannot reproduce.
Wolves have difficulty stand still for a second, since if they are attacked back, they unsit.
Pulling them apart and sitting them down seems to work as expected - wolves after unsitting are friendly towards each other.
If you can record the video of the issue occurring that would be great.
in-game entity and block animations are supposed to slow down with tick rate lower then 20, and remain the same with tick rates above 20. Item spinning is not its movement, which would be affected, just the animations.
As designed. Creaking will trigger if a player looks at it from less than 12 blocks. Otherwise it remains neutral. Player can stand next to creaking facing away from it and also won't get targetted.
We like it this way
Happy little accident. It's a keeper.
all idle ambient sounds should use the same subtitle: Eerie noises, subtitles.ambient.sound
Feature request - enderman cannot provide state definition, and default state of resin clump (no sides) have empty loottable, Similar to glow lichen
ok, providing proper state demonstrates it is not an issue with the enderman. I was not correct with initial justification, but it turns out it is a feature request/wai at least
/summon minecraft:enderman ~ ~ ~ {NoAI:1b,Health:1f,carriedBlockState:{Name:"minecraft:resin_clump",Properties: {"east":"true"} }}works just fine
invulnerability frame is used for other things, like sounds etc. and creaking should still have them.
ok folx. the title is little bit missleading.
The creaking respawns when the creaking heart got their previous creaking despawned via day/night cycle for example. Then any subsequent creakings will have problem persisting.
Java duration is intended.
Bedrock duration is wrong
Bug is now tracked as a bedrock issue.