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 @unknown can be found in this comment.
Linked issues
is duplicated by
relates to
Attachments
Comments
I think this is intended? I mean sure it makes no sense why it would be but it just is, I could be wrong though.
still present in 15w42a
I believe intended behavior is for provoked mobs to track you as normal, the being able to see you regardless of potion effect seems like the bug portion of this report.
Confirmed for 16w04a
Looks like Magma Cubes are not ignored anymore in 1.10-pre1. Can anyone confirm?

No, it's still the same.
still in 16w43a
still in 16w44a
still in 1.11 Pre-Release 1
Tested in survival with no armor
AI behavior the same with or with out invisibility potion (ie potion has no affect):
Guardian, Elder Guardian, Blaze, Ghast, Wither, Rabbit, Ocelot
Did not test with all hostile/neutral mobs, but those I did worked until hit with the exception of Magna Cub/Slime - they seemed to still not see me.
Still in 1.11.2
Still in snapshot 17w06a
Was already marked as affected...
i spawned some guardians and changed my game mode after slipping an invisibility potion but they still shot lasers at me
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.
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()
IF random THEN fail
ELIF target != EntityPlayer THEN world.getEntitiesWithinAABB(...) // no checks for anything, as long as the selector predicates apply
ELSE (target=EntityPlayer) THEN world.getNearestAttackablePlayer(...) //does check for various aspects including invisibilty
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:
protected void applyEntityAI()
{
this.tasks.addTask(6, new EntityAIMoveThroughVillage(this, 1.0D, false));
this.targetTasks.addTask(1, new EntityAIHurtByTarget(this, true, new Class[] {EntityPigZombie.class}));
this.targetTasks.addTask(2, new EntityAINearestAttackableTarget(this, EntityPlayer.class, true));
this.targetTasks.addTask(3, new EntityAINearestAttackableTarget(this, EntityVillager.class, false));
this.targetTasks.addTask(3, new EntityAINearestAttackableTarget(this, EntityIronGolem.class, true));
}
However Guardian doesn't have it specified as EntityPlayer.class but rather as a custom predicate:
this.targetTasks.addTask(1, new EntityAINearestAttackableTarget(this, EntityLivingBase.class, 10, true, false, new EntityGuardian.GuardianTargetSelector(this)));
...
static class GuardianTargetSelector implements Predicate<EntityLivingBase>
{
...
public boolean apply(@Nullable EntityLivingBase p_apply_1_)
{
return (p_apply_1_ instanceof EntityPlayer || p_apply_1_ instanceof EntitySquid) && p_apply_1_.getDistanceSqToEntity(this.parentEntity) > 9.0D;
}
}
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.

Still present in 1.13-pre6

Confirmed for 1.13
Confirmed 1.13.1
Bug still in 1.13.2 and 19w02a
Still happens in 19w08b, but the guardians will not target invisible players unlike other mobs when attacked.
Also, zombies and their variants will permanently be able too see you from a normal range if you hit them. This is different from non-zombie mobs because other mobs detect the invisible player at the expected distance after losing sight, but zombies will continue to be able to see you as if you weren't invisible. (Same glitch applies to zombie pigmen, husks, and drowned.)
Still happens in 19w09a
Can confirm this is still happening in latest release.
Confirmed for 19w46b.

The "provoked" behaviour listed in the report is intended.
Should also add to the unprovoked, shulkers because as soon as you get near them they start attacking with invisibilty still present in 1.15.1
Also affected by hoglins in 1.16 snapshots.
Hoglins are covered by MC-172479.

I think the bug has been fixed at some point.
It is intentional that mobs can sometimes see invisible players up to a distance of 3.5 metres (or even further if the player is wearing armor).
It is intentional that mobs (except slimes) who are attacked by invisible players can see their attacker and fight back.
Many players thinking a return of MC-89309
I think remaining issues with invisibility should have their own reports.
can confirm bug exists in 15w39c on OSX 10.10 java 1.8