In mob farms that rely on mobs falling, mobs often despawn in mid-air due to the new despawning system. This prevents fall-damage based systems from being viable without significantly hurting the max rates of the farm.
Keywords for search: mob despawn chute chute shoot de-spawn fall grinder disappear range radius ticking spawn rule sphere spherical cylindrical cylinder vertical range hostile
Related issues
is duplicated by
Attachments
Comments


this is intentional with the new despawning sphere thing added in the beta were mobs instantly despawn if they are outside of it.

Hi 77Tigers,
As mentioned by Damien this technically isn't a bug, its working as the new rules are implemented, its just affecting mob farms in an adverse way.
Feedback on new and changed features in BETA, when not caused by a bug, have a specific place on the feedback site specifically to gain insight into the communities feelings on how the BETA is tracking.
In regards to this specific change, Prowl has already created a post that is accumulating votes and has a much better chance of being seen. I would suggest heading over there and voting for it to show the devs you agree.
As always, from a fellow community member and volunteer, thank you very much for participating in the bug tracker and your enthusiasm for Minecraft. This community is amazing 😃
Ionic

This issue is marked as fixed in 1.16.0.61, but the described issue is still occuring. In fact, it seems like the instant despawn range has been reduced for sim distance 4❓ .
The changelog in 1.16.0.51 states that mob despawning range is now tied to simulation distance.
Which could mean one of two things: Either the ranges scale depending on your simulation distance, or a mob will instantly despawn when not within simulation distance. I figured it was the latter, but it's not. Meaning that despawning still is a sphere and the mobs despawning midair issue is still present.
I still think that having it configured to despawn mobs instantly outside of simulation distance and removing the R32-54 1/800 despawn chance is a good option,, and even better would be a cylinder that has a 54 block radius and is limited vertically (ideally 128 blocks up and 128 blocks down from the player).
The mention in the 1.16.0.61 changelog is a little vague, so it's hard to draw conclusions from this and I haven't conducted good enough testing yet to determine the proper despawning conditions, but what I can tell you is that the issue still persists.
If you have a test world available that shows the issue, you might like to upload a copy of it for investigation.
If the world is larger than 10MB you can upload the world to OneDrive or a similar file sharing site, and then share the link.

One farm this really would impact is endermen farms. They have to fall 43 blocks to die. I'll see if I can find a test world.

I've attached a test world.

Also attached is a world showing the beginning of a slime farm that no longer spawns slimes with the reduced vertical instant despawn radius in 1.16.0.61. Players with existing farms anything like this will find that their farms are broken or their rates reduced with the change. While farms can be adjusted, it seems worth considering that since slimes spawn in slime chunks over a y-level range of about 35 blocks, a max-rate slime farm from 1.14 will be heavily nerfed by the 1.16.0.61 change from a 30-block spawn range (r24 to r54) to a 20-block effective spawn range (r24 to r44).
[media]

I pushed my peeps to test more accurately how the 1.16.0.61 changes impact vertical despawning, and it looks like vertical actually is at 128 now for all simulation distances except sim 4. Unfortunately the documentation for the data-driven despawning options is not clear, and the people I talk to–some of the best minds in the community in mob farm design and code analysis–started out very confused about how the new system works.
It looks like we now have a dual instant despawn check: mobs instantly despawn
if they are in the outer chunks of the simulation area, OR
if they are > 128 radius blocks (r128) from the player.
The combination of these checks results in a perfect sphere on sim 12, and a jagged quasi-spheriod on sim 6-10. Vertical despawning is governed entirely by (2) since (1) only affects horizontal distance. Note that r128 in (2) is a default; this number is data-driven.
However, sim 4 is hard coded to skip (1) and use r44 for (2). Presumably sim 4 skips (1) because it would be too restrictive, resulting in too small of a viable area for mobs to exist. Then without (1), r44 overrides the data-driven value for (2) in order to prevent non-persistent mobs from being saved in non-simulated chunks.
I have a suggestion that would resolve the issue on this ticket as well as be much more intuitive, consistent across the simulation distances, and supportive of data-driven design:
Use the r44 only as horizontal (x, z) check that runs only as a sim 4-based exception to (1), and keep (2) data-driven with a default of 128.

Curiosity, on Sim distance 4 we have for years been able to use command blocks to teleport and kill mobs in "unloaded" chunks. This is not ideal anymore with mobs picking up player gear. Why are we limiting Realms and lower end devices to have such a small spawning sphere? If this is a hard coded value of r44, couldn't it be hard coded for r54? Maybe have there be a check for the persistence NBT tag, or as part of the chunk unloading process it prioritizes that before a chunk is unloaded it removes those mobs that are there without prior player interaction.

@@unknown while I don't have access to the code or Mojang's internal discussions, I think I can answer some of your questions based on knowledge gained from playing the game and testing these things.
Command block + ticking area despawn systems work because chunks that have been simulated since the last reload of a world remain in RAM even though they are not ticked. This allows the mobs in those chunks to be targeted by commands. These systems can't be 100% reliable because mobs in chunks that have not been simulated since the last reload of the world will not be found by commands. Hard-coded despawning needs to be 100% reliable.
The reason for r44 was confirmed with the resolution of MCPE-78840: it is the maximum horizontal radius that can guarantee non-persistent mobs will never escape despawning and end up saved in non-simulated chunks.
There is no active "chunk unloading process" in which the game can do anything. Mobs used to be "saved" in "unloaded" chunks as a passive consequence of simply being located in chunks that were no longer simulated. Intentional despawning, therefore, has to happen within simulation distance, in chunks that are being ticked, and as part of the ticking process.
What could be done to re-enable the r54 effective spawn area and give sim4 an r54 (or 55 or 56) viable mob area, would be to base the radius on the horizontal center of the chunk in which the player is located instead of the exact player position. That would mean the horizontal despawn radius from the player would vary between 44 and 64 on sim4, depending on the player's relative position in a chunk. I don't see any problem with that, especially since the simulation_edge despawning that has been applied to higher sim distances already causes greater horizontal variance (on sim6 the horizontal despawn distance varies between 45 and 95). Moreover, expanding sim4 effective spawning back to r54 in this way would do a lot to help with both the present bug and the monster spawning density issues raised in MCPE-65762.

Can players assume that this is a functioning as intended that mobs will despawn spherically as opposed to in a cylindrical fashion?
Thank you for your report!
However, this issue has been temporarily closed as Awaiting Response
Is this still an issue in the latest version? If so, please make sure the ticket description contains the following information:
Steps to Reproduce:
1.
2.
3.Observed Results:
(Briefly describe what happens)Expected Results:
(Briefly describe what should happen)
If your ticket does not look like the example given here, then it's likely to be closed as incomplete.
This ticket will automatically reopen when you reply.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki

Still an issue as of 1.17.41. This hit both my mob farm and skeleton farm hard and I get little to no drops.

Twice I've logged in to my Realm to find a nametagged zombie despawned. No other mobs have despawned. I have 36+ different nametagged mobs in the area, but only the zombies have despawned. They despawned one at a time, not both at the same time. The first one despawned a week ago, the second a few days ago. They are the only mobs to despawn, the villagers two blocks away from each did not despawn and are still there. They were nametagged and my world is on hard mode. The mobs are also contained in a single block location and unable to wander.
what you were doing leading up to the mobs disappearing: Logged in to my realm, had not checked them before logging out but was checking on my different farms (within 100 blocks)
single vs. multiplayer, local vs server/realm: Multiplayer realm, I'm the host
how far you traveled: within 100 blocks this session, through the nether previous session
how long the current or previous play session lasted: Current 1.5 hours (before I noticed), previous 3-5 hours. I don't check every mob regularly, just when I am in the area they are.
whether the despawns were near a player spawn point or if you had changed your player spawn point during the session: over 200 blocks from world spawn, change personal spawn with sleeping in the closest bed frequently
if you experienced lag or anything else abnormal: The area is laggy due to my farms and redstone, but there was no more lag than usual.