Chumbanotz
- chumbanotz
- chumbanotz
- America/New_York
- Yes
- No
MC-3498![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
Low
MCPE-1679
When an Iron Golem attacks a fast-moving hostile mob(Enderman, Zombie Pigman, etc.), the hostile mob will continously hit and knock back the Iron Golem while it does nothing about it. Iron Golems will also move slowly and glitchy when hit and walk glitchy too. Occasionally after killing a mob, they will continue to hit where the mob died.
Steps to Reproduce:
1. Create an Iron Golem in Creative.
2. Spawn an Enderman or Zombie Pigman near the Golem.
3. When the Iron Golem attacks the mob, it will keep getting hit until it dies or manages to kill the mob.
Endermen don't open their mouth when attacked by other mobs
Back in 1.2.5, Endermen would open their mouth and shake when attacked by an Iron Golem. Not sure what happened.
Upon entering the End in Creative mode, the Ender dragon will try to attack the player instead of acting like neutral mob as all other hostile mobs do.
Steps to Reproduce:
1. Make a new Creative world.
2. Create and activate an End Portal.
3. Fly to the Ender Dragon and notice how it attempts to attack you.
Swords enchanted with Sharpness, Knockback, and Fire Aspect do not convey their specific effects on the Ender Dragon. However, bow enchantments such as Power do inflict more damage.
Steps to Reproduce:
1. Make a new Creative World.
2. Construct an End Portal and enter it.
3. Get two diamond swords from the creative inventory.
4. Enchant one sword with Sharpness V using an Anvil and an enchanted book. Leave the other one un-enchanted.
5. Hit the Ender Dragon with both and notice the same amount of damage is dealt.
Swords enchanted with Sharpness
, Knockback, and Fire Aspectdo not convey their specific effects on the Ender Dragon. However, bow enchantments such as Power do inflict more damage.Steps to Reproduce:
1. Make a new Creative World.
2. Construct an End Portal and enter it.
3. Get two diamond swords from the creative inventory.
4. Enchant one sword with Sharpness V using an Anvil and an enchanted book. Leave the other one un-enchanted.
5. Hit the Ender Dragon with both and notice the same amount of damage is dealt.
Swords enchanted with Sharpness d
o not convey their specific effects onthe Ender Dragon. However, bow enchantments such as Power do inflict more damage.Steps to Reproduce:
1. Make a new Creative World.
2. Construct an End Portal and enter it.
3. Get two diamond swords from the creative inventory.
4. Enchant one sword with Sharpness V using an Anvil and an enchanted book. Leave the other one un-enchanted.
5. Hit the Ender Dragon with both and notice the same amount of damage is dealt.Swords enchanted with Sharpness deal more damage to the Ender Dragon. However, bow enchantments such as Power do inflict more damage.
Steps to Reproduce:
1. Make a new Creative World.
2. Construct an End Portal and enter it.
3. Get two diamond swords from the creative inventory.
4. Enchant one sword with Sharpness V using an Anvil and an enchanted book. Leave the other one un-enchanted.
5. Hit the Ender Dragon with both and notice the same amount of damage is dealt.
Swords enchanted with Sharpness do not deal more damage to the Ender Dragon. However, bow enchantments such as Power do inflict more damage.
Steps to Reproduce:
1. Make a new Creative World.
2. Construct an End Portal and enter it.
3. Get two diamond swords from the creative inventory.
4. Enchant one sword with Sharpness V using an Anvil and an enchanted book. Leave the other one un-enchanted.
5. Hit the Ender Dragon with both and notice the same amount of damage is dealt.
Swords enchanted with Sharpness do not deal more damage to the Ender Dragon. However, bow enchantment
s such asPower do inflict more damage.Steps to Reproduce:
1. Make a new Creative World.
2. Construct an End Portal and enter it.
3. Get two diamond swords from the creative inventory.
4. Enchant one sword with Sharpness V using an Anvil and an enchanted book. Leave the other one un-enchanted.
5. Hit the Ender Dragon with both and notice the same amount of damage is dealt.Swords enchanted with Sharpness do not deal more damage to the Ender Dragon. However, the bow enchantment Power does inflict more damage.
Steps to Reproduce:
1. Make a new Creative World.
2. Construct an End Portal and enter it.
3. Get two diamond swords from the creative inventory.
4. Enchant one sword with Sharpness V using an Anvil and an enchanted book. Leave the other one un-enchanted.
5. Hit the Ender Dragon with both and notice the same amount of damage is dealt.
Changed description as well.
Withers cannot be hit where the other two heads are, including the "arms" conn
necting to the heads. The same applies to their collision box, as a Wither can fly through a one block hole upwards.Steps to Reproduce:
1. Make a new Creative world.
2. Spawn a Wither.
3. When you try to hit the two smaller heads, notice how the Wither takes no damage.
4. Also, press F3+B to show entity collision boxes and notice the box on the Wither only includes the main head and spine.
Mobs that use projectiles as their weapon, such as Skeletons and Withers, canno
nt deal damage to the Ender Dragon but projectiles fired by a player does deal damage, such as an arrow.Steps to Reproduce:
1. Make a new Creative world.
2. Construct an End Portal and enter it.
3. Spawn a Wither.
4. It may be difficult, but get the Wither to chase the Ender Dragon.
5. Notice that when a Wither Skull manages to directly hit the Ender Dragon, no damage is dealt. Sometimes, only the explosion damage is dealt.
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
The Bug:
Enchantments from items held in the main hand are applied to other items when entities are killed.
Steps to Reproduce:
- Summon a husk, hold a bow in your offhand, and a sword enchanted with a high level of looting in your main hand, by using the commands provided below.
/summon minecraft:husk ~ ~ ~ {NoAI:1b}/item replace entity @s weapon.offhand with minecraft:bow
/item replace entity @s weapon.mainhand with minecraft:diamond_sword[enchantments={levels:{"minecraft:looting":100}}] - Shoot and kill the husk using the bow.
- Look if the looting enchantment on the sword affected the number of items that the husk dropped.
- Take note as to whether or not enchantments from items held in the main hand are applied to other items when entities are killed.
Observed Behavior:
Enchantments are applied to other items when entities are killed.
Expected Behavior:
Enchantments would not be applied to other items when entities are killed.
Potential Fix:
A potential fix by Chumbanotz can be found in this comment.
The bug
When an entity randomly rotates, while standing on the same position, the server does not update the entity's rotation, causing the Rotation NBT and local coordinates to be inaccurate to what players see.
How to reproduce
- Summon a zombie
- Run this command in a repeating command block:
/execute at @e[type=zombie] anchored eyes run particle flame ^ ^ ^4 0 0 0 0 1
→
When the zombie randomly looks around without moving, the particle will stay in the same place, rather than move with the zombie's looking direction
Code analysis
Potential code analysis by Chumbanotz can be found in this comment.
The bug
When killing mobs, they usually are knocked back when they die. But there are a few mobs for which this is no longer the case.
Affected mobs
It seems like all rideable mobs are affected:
- Pigs
- Horses
- Donkeys
- Mules
- Llamas
- Trader llamas
- Skeleton horses
- Zombie horses
- Striders
- Camels
Video
Code analysis
Code analysis by Chumbanotz can be found in this comment.
The bug
When baby sheep follow adult sheep it eats grass while walking.
Code analysis here by Chumbanotz
How to reproduce
- Summon baby sheep
- Summon adult sheep near baby sheep
→ Baby sheep will start following adult sheep and sometimes will eat grass while walking
The bug
Using a lead on an iron golem changes their nature so that the will no longer attack hostiles, including a player that attacks them. Found this on an iron golem "farm" using a zombie; dragging 7 golems that were out of range so that they were within aggro and releasing them from the lead caused them to walk around in a somewhat glitchy way, with no apparent path finding (never really leaving the area they were dragged to), and not interested in chasing after the zombie. Lead two more zombies within range and the iron golems ignored them. I even attacked a golem myself and was not attacked.
Other iron golems in the village still act as normal. It only affects the iron golems that have been moved using leads.
To reproduce
- Place a zombie inside of an iron golem trap
- Summon an iron golem
- Leash the iron golem
- Unleash the iron golem
→
The iron golem will try to get to the zombie, but won't succeed, turn around sometimes, and it looks quite confused in general - Close and reopen the world
→ Now the iron golem is as angry onto the zombie as ever
Videos
Survival, village golems: https://youtu.be/sVl5fxA6GAY
Creative, self-built golems: Minecraft 1.15.2 - Singleplayer 2020-04-04 22-25-32.mp4
Code analysis
Code analysis by Chumbanotz can be found in this comment.
The bug
Enemies like Zombies and Endermen are sometimes suddenly attacking quickly 2 times in a row instead of at their normal attack-rate. (Melee attacks only as far as I know). Sometimes the attack animation or sound won't even play.
This can seemingly mess with blocking too, though it could also just be MC-100949
Code analysis
Code analysis by Chumbanotz can be found in this comment.
The Bug:
Whilst a melee-type mob pursues a player/entity, they may stop attacking once in a while when pathfinding towards their targets. This is also an issue with certain passive mobs as certain passive mobs (e.g. a villager) may randomly stop fleeing for a second if a player hits that entity. (This issue is just like the MCPE counterpart, MCPE-48144).
Affected Entities:
Please note that there may be more entities affected by this issue that aren't listed below.
- Cave Spider
- Creeper
- Enderman
- Endermite
- Iron Golem
- Silverfish
- Skeleton (without bow)
- Spider
- Stray (without bow)
- Villager
- Vindicator
- Wither Skeleton
- Wolf
- Zombie
- Zombie Villager
- Zombified Piglin
Steps to Reproduce:
- Summon any of the affected mobs listed above.
- Provoke it if necessary and allow the said entity to attack you.
- Observe how sometimes, the entity randomly stops and starts pathfinding even though it hasn't made it to its target.
Observed Behavior:
Entities stop and start pathfinding at random intervals even though they haven't fully approached their target. This happens randomly and can last several seconds before it starts to pathfind again.
Expected Behavior:
Entities would not stop and start pathfinding at random intervals when pursuing their target.
Code Analysis:
Code analysis by Chumbanotz can be found in this comment.
The Bug
Despite being an undead mob, Ghast are harmed by potions of harming when they should be harmed with potion of healing.
Code analysis from Chumbanotz found in this comment
The Bug:
Unlike other mob entities, environmental damage deals extra damage to items, boats, and minecarts causing them to disappear instantly instead of a few seconds.
To Reproduce:
1. Throw an item onto a cactus.
2. Summon a chicken on a cactus.
Results:
Although items have more health than a chicken, they disappear quicker than the chicken.
Code Analysis:
Code analysis by Chumbanotz can be found in this comment.
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
The bug
Most mobs seem to stop walking (do not wander around / pathfind randomly) when there is only a spectator player nearby. The mobs might start moving, but then eventually stop. They still rotate and can bob up and down, but eventually they never actually leave its position.
Though this is likely intended (MC-46843, MC-48868), it leads to potential gameplay issues as described in MC-202512 and MC-212687. It also behaves inconsistently, because if it is intended behavior, it should apply to all mobs (MC-136206).
Steps to reproduce
This can be reproduced by switching the gamemode from creative to spectator, or by simply remaining in spectator mode and summoning the mobs listed below.
Notes
Logging out and relogging seems to (temporarily) fix the issue for some mobs.
When mobs interact with one another (i.e. cats and rabbits, for example) they might actually move around until the interaction is completed (that is, for example, the cat kills the rabbit). Then the mob stops moving again. Other examples include villagers fleeing from illagers and striders moving around when it rains.
Fixing this issue (if it is not intended) improperly might cause severe performance issues.
Affected mobs
This affects the following mobs: blazes, cats, chickens, cows, creepers, dolphins (MC-202512), donkeys, drowned, elder guardians, endermen (only teleport, don't walk), endermites, evokers, fish (cod, salmon, pufferfish, tropical fish), guardians, horses (including skeleton and zombie horses), husks, illusioners, iron golems, llamas and trader llamas, mooshrooms, mules, ocelots, pandas (they only roll, but don't walk), parrots, pigs, pillagers, polar bears, rabbits, ravagers, sheep, silverfish, spiders and cave spiders, skeletons, snow golems, squids and glow squids (MC-212687), strays, striders, vindicators, wandering traders, witches, wither skeletons, wolves, zombie villagers, zombies and zombified piglins.
This does not affect: axolotls, bats, bees, ender dragons, foxes, ghasts, goats, hoglins, magma cubes, phantoms, piglins, piglin brutes, slimes, turtles, vexes, villagers, withers and zoglins. Shulkers and giants are not affected because they already don't move in creative.
Other mobs, if any, were not tested.
Analysis
Analysis by Chumbanotz provided in this comment.
Can also confirm this behavior in 21w40a. Here are some extra details regarding this problem.
The Bug:
Ghasts are damaged by potions of harming despite being undead mobs.
Steps to Reproduce:
- Summon a ghast and obtain a potion of harming.
/summon minecraft:ghast ~ ~ ~ {NoAI:1b}
- Throw the potion of harming at the ghast and as you do this, take note as to whether or not it's damaged by the potion.
Observed Behavior:
Ghasts are damaged by potions of harming despite being undead mobs.
Expected Behavior:
Ghasts would not be damaged by potions of harming as they are undead mobs. Instead, they should be damaged with potions of healing, just like other undead mobs.
Code Analysis:
Code analysis can be found in this comment by Chumbanotz.
This is based on an observation by Chumbanotz on this comment.
Code analysis (Mojang mappings, 21w11a): The issue seems to stem from implementations of HurtByTargetGoal#alertOther(Mob, LivingEntity). These mobs are programmed to alert other mobs of the same type when hurt (either with a custom hurt goal that extends HurtByTargetGoal, like aggressive pandas and bees, or by adding a HurtByTargetGoal(this, new Class[0]).setAlertOthers(class)) to its target selector). When this happens, the mob sets its attack target to the first mob's target, ignoring the fact that it might be itself.
{
...
protected void alertOthers() {
double $$0 = this.getFollowDistance();
AABB $$1 = AABB.unitCubeFromLowerCorner(this.mob.position()).inflate($$0, 10.0, $$0);
List<Entity> $$2 = this.mob.level.getEntitiesOfClass(this.mob.getClass(), $$1, EntitySelector.NO_SPECTATORS);
for (Mob ayr2 : $$2) {
if (this.mob == ayr2 || ayr2.getTarget() != null || this.mob instanceof TamableAnimal && ((TamableAnimal)this.mob).getOwner() != ((TamableAnimal)ayr2).getOwner() || ayr2.isAlliedTo(this.mob.getLastHurtByMob())) continue;
if (this.toIgnoreAlert != null) {
boolean $$4 = false;
for (Class<?> $$5 : this.toIgnoreAlert) {
if (ayr2.getClass() != $$5) continue;
$$4 = true;
break;
}
if ($$4) continue;
}
this.alertOther(ayr2, this.mob.getLastHurtByMob());
}
}
protected void alertOther(Mob $$0, LivingEntity $$1) {
$$0.setTarget($$1);
}
}
There needs to be a check in alertOther(...) to verify if the mob is not setting the target to itself.
The Bug
For the strike, Wardens have to hit tamed Wolves twice to kill them.
For the Sonic Boom, Wardens have to shoot tamed Wolves four times to kill them.
Sources
Strike: https://www.bilibili.com/video/BV1S94y1d7AA
No Sonic Boom sources yet.
Code analysis
Code analysis by Chumbanotz can be found in this comment.
They always teleport if you look at their upper legs, which is where they will be aggroed to you if you look there. If you look at their feet, they will not teleport.
Baby animals do not have less health than adult animals in the PC version.
It has been a while, but I can confirm that this has been fixed some time ago. Not sure exactly when.
Appears to be fixed in snapshot 20w13a
Having looked at the code, there is no evidence that ghasts are undead. Looking at the related issue
MC-162557, the reason withers won't attack ghasts anymore is that there is a general check for all mobs that prevent them from attacking ghasts.Here is the piece of code that controls this from MobEntity.class, taken from MCP mappings.
You can test the cat by spawning a rabbit for it to attack, and for the ocelot you can spawn a chicken. The dolphin really can't even be tested, but I thought I would include it anyway from my findings.
The reason I reported this is because of
MC-4069.Applies to slimes and magma cubes as well.
Based on Mojang's mappings, the class FollowParentGoal controls the AI for baby animals to follow the nearest adult of the same type. This class needs to call Goal::setFlags with the value Goal.Flag.MOVE to prevent other goals that set this flag from executing.
The mobs that have this issue all use the MeleeAttackGoal class or their own class that extends it. There is a field called lastCanUseCheck, which is the first check if the goal can be used. This field is used to ensure if at least one second has passed since the last time this goal executed before any other checks are done.
For the goal to execute, the mob then must have a target that is alive and the mob must either have a path to the target, or be within melee range. While the goal is running, a field called followingTargetEvenIfNotSeen is checked to allow the mob to pathfind toward the target even if it cannot be seen. Some mobs have this set to false, and others set to true.
The method MeleeAttackGoal::canContinueToUse is called each tick while the goal is running to check if the goal should continue. The field followingTargetEvenIfNotSeen is checked again in this method and if it's not true, the goal will stop if the mob does not have a path. Which means that when mobs occasionally can't find a path to the target and have followingTargetEvenIfNotSeen set to false, the goal stops and begins the checks to start again as described in the first and second paragraph.
The field lastCanUseCheck should be removed entirely, and the check for followingTargetEvenIfNotSeen in the method MeleeAttackGoal::canContinueToUse should also be removed.
This issue is directly responsible for MC-191642. The field that controls the attack timer is called ticksUntilNextAttack. When the goal starts, this field is set to zero, which, as a result of the above description, causes the timer to reset and allow the mob to attack twice in a row. The method MeleeAttackGoal::start should remove where the field ticksUntilNextAttack is set to zero.
The cause of this issue is likely located in the BodyRotationControl class. The yRot field is not updated when the mob is not moving. Here's an example of a fix in the method BodyRotationControl::clientTick. The only change is the addition of the last line.
if (this.isMoving()) { this.mob.yBodyRot = this.mob.getYRot(); // Take the logic from here this.rotateHeadIfNecessary(); this.lastStableYHeadRot = this.mob.yHeadRot; this.headStableTime = 0; } else { if (this.notCarryingMobPassengers()) { if (Math.abs(this.mob.yHeadRot - this.lastStableYHeadRot) > 15.0F) { this.headStableTime = 0; this.lastStableYHeadRot = this.mob.yHeadRot; this.rotateBodyIfNecessary(); } else { ++this.headStableTime; if (this.headStableTime > 10) { this.rotateHeadTowardsFront(); } } this.mob.setYRot(this.mob.yBodyRot). //And apply the opposite here } }The reasons for this is most likely related to MC-198068. See the comment here for an explanation.
When any mob is attached with a lead, a field called restrictCenter is set to the leash holder's position and another field called restrictRadius stores the restriction distance which is set to 5 blocks when a mob is leashed. This field is tested for in various mob AI classes to check if a mob is allowed to navigate outside of the restrictRadius from the restrictCenter position and whether a mob should try to or continue to attack another mob if the target or the attacker is outside of this restriction. The issue is that when a mob has its lead removed, restrictRadius is not reset to the sentinel value of -1 (which means the mob has no restriction) until the game is reloaded.
This is also the cause for
MC-221754.Players and mobs use a timer to count down the next time they can take damage as described here called invulnerableTime. Which means that non-mob entities don't take more damage, but take damage every tick instead of every 10 ticks. Interestingly, the field invulnerableTime is available in the Entity class, so all that needs to be done is to take the logic from players/mobs and apply it to the other entities.
The mobs listed above all override the method LivingEntity::travel which controls the movement logic for mobs and players alike. Horses, donkeys, mules, llamas, trader llamas, zombie horses and skeleton horses all extend the same base class called AbstractHorse. Pigs and striders implement the interface ItemSteerable which handles its movement when ridden while its rider is holding the needed item for steering.
In the beginning of this method, these mobs checks if it is alive, which means all motion is skipped when it is dead. This check was likely put to stop these mobs moving when dying while being ridden. This check should be removed from the travel method and instead the method LivingEntity::isImmobile should be overridden which if true stop all AI logic for mobs. By default this method returns LivingEntity::isDeadOrDying. It seems this was attempted in the AbstractHorse class, however there is a simple mistake. Instead of this:
The logical AND should be replaced with logical OR after super.isImmobile(), like this:
The above code should be applied to pigs and striders as well without the specific horse methods.
I can confirm that this is still an issue in 1.17 Release Candidate 1.
Duplicate of
MC-148458.Mobs have an integer field called noActionTime which is increased every tick so long as the mob is alive and has its AI enabled. When a mob is within 32 blocks of the closest non-spectator player, this timer is set to zero. This field is also used to determine when a mob can randomly despawn. When this timer is greater than 100 ticks (10 seconds), most mobs are programmed to not wander around. This seems to be intentional given the name of the field. My guess is this was implemented to not use up the game's resources for mobs trying to pathfind that are far from any players. This value is not saved to NBT which means noActionTime is set to the default value of zero when the world is reloaded.
The blaze is attacking itself. When a blaze gets hurts, it alerts other blazes within its follow range that it has been hurt and sets their attack target to the original blaze's target.
I believe this may be the same issue as
MC-121048.It will still be possible to hit invisible entities, the name of the entity simply won't show on the debug screen.
This class is called net.minecraft.util.Mth in Mojang's mappings.
Wolves are programmed to take less damage from a damage source with an associated entity that isn't a player or arrow, essentially taking a mob's damage on easy mode. My guess as to why is to make tamed wolves more useful when fighting mobs. Here's the relevant part of the code:
I think this is related to my comment on MC-198068, but to summarize, the AI that controls them looking at their target is the same class that makes them pathfind to and attack their target, which keeps starting and resetting when they cannot find a path to the target, thus causing the mobs to briefly look at and away from the target.
Spiders and Wolves use the class LeapAtTargetGoal which handles the leaping at their target. This class calls Goal::setFlags in its constructor with the values of Goal.Flag.MOVE and Goal.Flag.LOOK. These flags prevent other AI goals with the same flags from executing. The MeleeAttackGoal handles the melee attack and has the same goal flags set. To fix this, remove the call to Goal::setFlags from the LeapAtTargetGoal to allow it to run at the same time as MeleeAttackGoal.
A possible solution is to cache the ItemStack that causes the action in the DamageSource instance that will be used to cause the damage and check for enchantments against this item instead of the player's currently held item. The DamageSource will also need to be cached for projectiles and written to NBT in case the world is closed before the damage is applied.
On second thought, the DamageSource likely doesn't need to be written to NBT for projectiles, saving the ItemStack to the projectile should suffice. The ItemStack can be passed to the DamageSource when needed.
The classes EntityDamageSource and IndirectEntityDamageSource override the method DamageSource#getLocalizedDeathMessage and check for the currently held item in the main hand of the attacker. As explained in this comment, the ItemStack responsible for the action should be stored in the projectile then passed to the DamageSource and used in the death message instead.