Endermen picking up blocks don't count towards the mob cap, and don't despawn, potentially cluttering up the world with endermen if they cannot place the block down

This is an intended change in one of the 1.16 pre-releases or snapshots, though I can't remember which one.

Working as intended as MC-124812 was fixed by 20w22a

WAI

Confirmed from MC-197178.

Added steps to reproduce. Also note that Endermen can get stuck under the following conditions:

• Endermen holding anything can get stuck above the Nether's ceiling forever, as they cannot place blocks on bedrock

• Endermen holding anything can get stuck forever, if they pick up a block and get trapped in a place where there's no valid position to place a block

• Endermen holding crimson/warped roots/fungi can get stuck forever, if they get trapped somewhere in a Nether wastes or basalt deltas.

• Endermen holding cactus can get stuck forever if they teleport into a cave with no escape

• Endermen holding flowers can get stuck forever if they teleport into a cave with no dirt surfaces or escape

My proposed fix for this is endermen should teleport away under conditions where they would get stuck forever. I think they should teleport whenever they can't place a block, which will prevent them from getting stuck.

Can confirm that an enderman holding a cactus that teleports into a cave won't despawn... have an enderman hanging around on a ledge underground that has been in that same place after a week of playtime.

First suspected something was wrong when I noticed an unusual number of endermen hanging around in the daytime around my desert base and not despawning when I left the area to unload the chunks. Since some of the endermen are holding sand or grass, I think there may also be an issue that lowers the chance of an enderman placing a block.

@unknown which version?

Can confirm, have  multiple enderman all around the world stuck with an item in their hand, unable to despawn and not willing to tp away.

One of them ended up in an enclosed bamboo farm.

Another one stole a cactus in the nether and can't place it cause no sand around.

Another two are in a digged-out perimeter between bedrock (can't place blocks on bedrock).

I would prefer to just go back to pre 1.16 behaviour and let them despawn even with a block in their hand. It worked well like that. It also produces less enderman trash all around. Some caves here are really filled up with random enderman placed blocks now and i am scared about them breaking redstone contraptions with them.

Edit:

Also note that now because they can pick up roots and fungi, they are more likely to pick up blocks (and therefore can't despawn).
A fungi, root and flower is some seperate block sticking out and they are very likely to pick those. Fungis are also very picky to where they can be placed, further elevating the chances of the enderman getting stuck.

Edit 2:

Workaround would be to just not allow them to pick anything up with a datapack:

https://www.madcatgaming.com/enderman-anti-grief-data-pack/

I also want to give a shout out to the mods who were overzealous and originally immediately marked this bug as WAI and closed it as invalid, together with a dozen other reports of the same problem, because a never ending source of mobs that never despawn and an ever increasing number of entities is apparently how it should be... until one of their own Helpers encountered the issue too.

Always remember:

They do it for free. They work for free for Microsoft.

Hi,

Just to add some more information. I'm currently spending a lot of time afking in a nether wastes Biome near warped forest. My preformance fell way off down to 25-30 fps. I used a command to kill all enderman and it jumped to around 80 fps it also killed 1043 Enderman. About 12 hours later I killed all endermen again and was up to 950. That's a lot of mobs to process for lowly computers.

due to bad AI along with jagged nether terrain, endermen may stuck in a pit and if you stay in warped forest biome around over 300 minecraft days, type in /effect give @e[type=enderman] glowing 100 then the output will say like 150 units are applied to the effect meanwhile the mob count at the debug screen tells you there's only 70 hostile mobs

i understand this may not be considered as a bug, but should be fixed by either one of these ways:

1. endermen picking up terrain blocks no longer be prevented from despawn

2. endermen picking up terrain blocks still counts towards the mob cap

3. fix mobs AI so that they never fall into a pit where they could not escape out

Can confirm this is still happening. I have found lots of "endermen holes", specially in the nether (I was doing a lot of things trying to fix a laggy nether, and I think this may be the reason behind it). I just took a screenshot of a corridor where they also gathered 

Version 1.16.5

I have hundreds of hundreds of enderman that will not despawn around my main nether portal because they picked up mushrooms. Hundreds!!!
This has happened multiple times and I endup having to open the game up to Lan so I can enable cheats and run the command to kill enderman.

This however is only a temporary fix because If I sit near the portal for about half an hour there are hundreds of them carrying items again not counting against the mob cap. This is absurd. Please fix it. 

This fxxking bug plz turn it into "very important" plz plz plz

version 1.16, 1.16.1, 2, 3, 4, and 5, 1.17 ,1.17.1pre1, 1.17.1pre2 and 1.17.1rc1, this bug has crashed a lot of servers. In our server, the nether where was always loading were full of endermans and they broke everything. In another server, someone placed a red mushroom in the end, then they have to replace the end - these fxxking enderman destroied everything. They make a video.

plz mojang repair it we can't stand

I think they should drop held blocks when despawning.

So my framerate has been going down for quite a while in my original world I made over 10 years ago. I attributed it to age and the amount of stuff I have, but recently noticed I had 900 entities loaded, and my framerate was low because I had over 300 rendered.

They turned out to be mostly Endermen, and it took a lot of looking (by that I mean X-ray glitch, finding them would have been difficult). Dozens of endermen clumped up in small holes in the cave floor, surrounded by their collection of dirt, gravel, and mushrooms. A prison of their own making, unable to despawn due to the stuff in their hands.

This takes a long time to make an impact on the game, many many hours since 1.16 when this seems to have started. The biggest issue seems to be that the Endermen somehow become unable to teleport, despite the fact they have plenty of valid areas nearby. They did still teleport after being hit, proving that there were valid areas nearby.

How I would fix this:

1. Endermen holding blocks are not allowed to teleport into lazy chunks.
2. When an enderman is chosen for despawning, if it is holding a block it will not despawn, but it starts searching for a place to place the block. It is also prevented from picking up more blocks. After it places the block, it needs to be chosen for despawning again before it despawns. If it is chosen for despawning 10 times while holding a block, the holding-a-block check is skipped and it despawns.
3. Replace or augment the global "mobgriefing" game rule with separate game rules for each mob.

This bug is related to MC-148494. That bug describes entities not despawning in ticking chunks, whereas this bug report shows how persistent entities can get into ticking chunks (endermen holding blocks).

Regarding my list of possible fixes, the reasons for each:
1. This prevents endermen from teleporting to a location where they cannot despawn because their AI becomes frozen. Similar checks could be made for other mobs that are conditionally persistent, eg: zombies holding items.
2: The core fix. The endermen AI needs a few tweaks so it cannot get stuck in a world unable to despawn because it is holding a block. In addition to the changes listed, other changes may be needed: stricter application of mob caps, and endermen that tried but failed to place a block would be more likely to teleport to a new location.
3: More a suggestion than anything, this change allows server owners to use a game rule to stop endermen picking up blocks while leaving other mob griefing unchanged. This can also be implemented with custom block tags for blocks that endermen can hold.

Can confirm in 1.19.2 and 1.19.3

still an 1.19.4 and 23w18a

Related to MC-197126

For anyone suffering this problem, I've attached a screenshot from my community facing changelog on discord. In here I describe the problem, the problems with making a solution, and how the solution we settled on works to not disable the vanilla mechanic of endermen placing blocks entirely. If you want to do that, vanilla tweaks has a nice datapack to disable them picking blocks up. 

The solution we settled on actually works really well! People still deal with (and sometimes complain) about Enderman placing blocks on their base so we maintained the mechanic, but the scoreboard in the datapack reports more than 400,000 enderman pruned and we no longer have carpets in commonly loaded areas and no endermen pockets when they dead-end. 

For anyone from Mojang that makes it to this bug, if you don't want to roll back enderman holding blocks being persistent the easy solution I'd suggest is to simply just fix it so block holding Endermen utilize and respect the PersistenceRequired tag. Not sure why they don't in the first place (there could be a reason of course), and with a problem on a smaller scale with zombies picking up mob drops and building up it was much much simpler to make a datapack to more cleanly just mark certain zombies non persistent. but gain persistence when they are holding diamond or netherite items or things of similar value. I think there are similar datapacks out in the wild that people are quite happy with and it makes it a non-issue for servers where these types of problems are actually important, but I found no such thing for endermen.  I hope the 400,000 number highlights the severity of the issue, and the datapack has only been in place less than a year on a map that started just a couple of months before the datapack. In addition, we had cleaned up the pockets by commands regularly before the datapack, so the number is not a result of the pile-up. I never actually dialed it in more aggressively either, it's quite conservative with the frequency of pruning.