MCPE-79359Mobs can despawn immediately after spawning
The 1.16.0.61 beta introduced scaled instant despawn distances based on a world's simulation distance setting. For simulation distance 4 the instant despawn radius was reduced from 54 blocks (the previous radius since 1.16.0.51 beta) to 44 blocks, presumably in order to ensure that non-persistent mobs are never saved in unloaded chunks (since MCPE-78840 is WAI). However, the spawning area still extends to 54 blocks from the player. This results in spawns between r44 and r54 being immediately despawned. This wastes processing power in an endless loop of pointless activity, and it is also visually unpleasant.
Steps to reproduce
- Set simulation distance to 4 and turn on mob spawning.
- Stand in a flat area.
- Look toward the distance.
Expected result
You see mobs spawn and wander around, only disappearing when they wander away from you. Beyond the line where wandering mobs disappear, you see no mobs at all.
Actual result
Beyond the line where wandering mobs disappear, you regularly see new mobs appear then immediately disappear.
Linked Issues
Attachments9
![[Mod] GoldenHelmet](../../../data/avatars/users/18951.svg){kind=small}
Created Issue:
Mobs can despawn immediately after spawning
The 1.16.0.61 beta introduced scaled instant despawn distances based on a world's simulation distance setting. For simulation distance 4 the despawn radius was reduced from 54 blocks (the previous radius since 1.16.0.51 beta) to 44 blocks, presumably in order to ensure that non-persistent mobs are never saved in unloaded chunks. However, the spawning area still extends to 54 blocks from the player. This results in spawns between r44 and r54 being immediately despawned. This wastes processing power in an endless loop of pointless activity, and it is also visually unpleasant.
Steps to reproduce
- Set simulation distance to 4 and turn on mob spawning.
- Stand in a flat area.
- Look toward the distance.
Expected result
You see mobs spawn and wander around, only disappearing when they wander away from you. Beyond the line where wandering mobs disappear, you see no mobs at all.
Actual result
Beyond the line where wandering mobs disappear, you regularly see new mobs appear then immediately disappear.
The 1.16.0.61 beta introduced scaled instant despawn distances based on a world's simulation distance setting. For simulation distance 4 the despawn radius was reduced from 54 blocks (the previous radius since 1.16.0.51 beta) to 44 blocks, presumably in order to ensure that non-persistent mobs are never saved in unloaded chunks
. However, the spawning area still extends to 54 blocks from the player. This results in spawns between r44 and r54 being immediately despawned. This wastes processing power in an endless loop of pointless activity, and it is also visually unpleasant.Steps to reproduce
- Set simulation distance to 4 and turn on mob spawning.
- Stand in a flat area.
- Look toward the distance.
Expected result
You see mobs spawn and wander around, only disappearing when they wander away from you. Beyond the line where wandering mobs disappear, you see no mobs at all.
Actual result
Beyond the line where wandering mobs disappear, you regularly see new mobs appear then immediately disappear.
The 1.16.0.61 beta introduced scaled instant despawn distances based on a world's simulation distance setting. For simulation distance 4 the despawn radius was reduced from 54 blocks (the previous radius since 1.16.0.51 beta) to 44 blocks, presumably in order to ensure that non-persistent mobs are never saved in unloaded chunks (since
MCPE-78840is WAI). However, the spawning area still extends to 54 blocks from the player. This results in spawns between r44 and r54 being immediately despawned. This wastes processing power in an endless loop of pointless activity, and it is also visually unpleasant.Steps to reproduce
- Set simulation distance to 4 and turn on mob spawning.
- Stand in a flat area.
- Look toward the distance.
Expected result
You see mobs spawn and wander around, only disappearing when they wander away from you. Beyond the line where wandering mobs disappear, you see no mobs at all.
Actual result
Beyond the line where wandering mobs disappear, you regularly see new mobs appear then immediately disappear.
![[Mod] OcelotOnesie](../../../data/avatars/users/43220.png){kind=small}
The 1.16.0.61 beta introduced scaled instant despawn distances based on a world's simulation distance setting. For simulation distance 4 the instant despawn radius was reduced from 54 blocks (the previous radius since 1.16.0.51 beta) to 44 blocks, presumably in order to ensure that non-persistent mobs are never saved in unloaded chunks (since
MCPE-78840is WAI). However, the spawning area still extends to 54 blocks from the player. This results in spawns between r44 and r54 being immediately despawned. This wastes processing power in an endless loop of pointless activity, and it is also visually unpleasant.Steps to reproduce
- Set simulation distance to 4 and turn on mob spawning.
- Stand in a flat area.
- Look toward the distance.
Expected result
You see mobs spawn and wander around, only disappearing when they wander away from you. Beyond the line where wandering mobs disappear, you see no mobs at all.
Actual result
Beyond the line where wandering mobs disappear, you regularly see new mobs appear then immediately disappear.
relates to
![[Mojang] Mega_Spud (Jay Wells)](../../../data/avatars/users/92696.png){kind=small}
relates to
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
Screenshot from 2020-06-25 16-57-07.png
![[Mod] LateLag](../../../data/avatars/users/92884.png){kind=small}
relates to
relates to
![[MCPE Mod] Celesian](../../../data/avatars/users/81635.png){kind=small}
relates to
relates to
relates to
Keep in mind the Works As Intended resolution addresses the primary subject of this ticket, that the instant despawn at sim4 was reduced to r44. It does not address every possible unforeseen ramification of that change. MCPE-79359 focuses on one consequence that seems to call for further tweaking, which is beyond the scope of the original intention behind r44. You may wish to follow up with that ticket if you have information to add, and vote there to show your interest.
Thank you for your report!
We're actually already tracking this issue at MCPE-79359, so I will resolve and link this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
I believe that this is partially intended. In previous versions of Minecraft, it was common for the cave monster cap to be filled almost all the time (MCPE-21856). In the overworld monsters would be hidden in small, inaccessible caves. In the nether zombie pigmen on remote or inaccessible platforms would fill the cap. The chance of this happening would increase as you spent time in an area. With the new despawning system in 1.16, the hidden and inaccessible monsters are now able to despawn regularly, so new ones can spawn in other places. You are supposed to encounter monsters regularly unless you have worked to spawn-proof an area.
What I think is not intended are the following ramifications of the extremely small 44-block despawn radius on simulation distance 4:
- Mobs effectively respawn an average of 12.8% (5 blocks) closer to the player.
- The volume of the viable spawning region (where mobs won't instantly despawn) is more than 50% smaller than it was in 1.14 and earlier, so mobs end up packed together that much more densely.
Now unfortunately, in the 1.16.20.50 beta, this 50% reduction to the viable mob zone, which was implemented in sim4 via depsawning in 1.16.0, is applied to every simulation distance via reduction of the spawning radius. Numerous other problems with this scheme have been raised, and possible solutions suggested, already in MCPE-65570, MCPE-78840, MCPE-79359.
The fix to MCPE-79359 makes no mobs spawn beyond a radius of 44 blocks. According to the 1.16.20 changelog and tweets from Mojang representatives this is not supposed to happen when the simulation distance is set at 6 or greater. R44 is intended behavior only on sim 4 but it occurs at all simulation distances.
To test:
- Create a flat world with sim 6 or greater
- Repeat command block with: execute @e[type=creeper] ~~~ setblock ~ ~-1 ~ concrete 0
- From the above block -> chain command block with: kill @e[type=creeper]
- Repeat command block: kill @e[type=!creeper]
- Afk and check that nothing spawns beyond r44
This issue has a severe impact on mob farms: the area of a circle with r54 is 9161 and with 44 is 6082, minus the area of a circle with 24 = 1809, that's a loss of 42%
The preferred solution to this bug for many players would not be to reduce spawning in sim4 to only 44 blocks from the player. Only having mobs spawn 24-44 blocks from the player limits mob farms quite a lot, because the area of the donut plain 24-44 blocks around the player is more than 40% smaller than the area of the donut plain 24-54 blocks around the player that we had previously. It also limits the number of mobs players encounter travelling across the world surface, because the distance ahead of the player that mobs can spawn is almost 20% shorter with r44 than with r54.
A better solution might be to implement some form of "lazy chunks" that are ticked partially and/or infrequently around the outside of simulation distance. These could be used to despawn mobs that happen to escape simulated chunks in sim4, in conjunction with an instant despawn radius somewhere between 54 and 63. (I've also suggested a form of lazy chunks to deal with some other bugs related to sim distance borders, MCPE-47212 and
MCPE-75966.)Exactly my thought on wasting cpu/ram usage. Also, if I may add, if 1 in number chance of mob despawning at certain range is used in 4 chunk should be disabled. Since 4 chunk is small enough for them to instant despawned in seconds to a few minutes when walking away from the player. So, having 2 similar operations running simultaneously unnecessary.
Beside that, I agreed the r44 is too small. It should have been r54 or higher.
I have a possible solution to this problem that works with the existing (1.14) Bedrock internal architecture. It is a way to implement lazy chunks at sim4 without introducing extra complexity or lag on realms.
It is my understanding that instant despawning at r44 was introduced on sim4 because despawn_at_simulation_edge takes up too much space with a sim4 simulation distance. My proposed solution on sim4 is to add an additional ring of chunks to the simulation ticking area. The ticking area is stored as a vector of offsets relative to the chunk a player is in. This would mean that sim4 would hold the same offsets as sim5. However, the difference between sim4 and sim5 is that on sim4, the outer ring of chunks only process the despawn_at_simulation_edge algorithm.
There are lots of different ways to implement this outer ring of lazy chunks, but the easiest way would be to check if the center of a chunk is more than 66 blocks away from the center of the chunk that the nearest player is in. If a chunk is more than 66 blocks away, the LevelChunk::tick() algorithm should skip most of its work and only process the despawn_at_simulation_edge algorithm.
The game already checks if a chunk is more than 96 blocks away from the nearest player in order to decide whether to run the spawning algorithm or not. The change would slightly tweak the distance calculation (using the center of the player's chunk instead of the player's position) and what the games does when the check fails (run the despawn algorithm). I don't know how despawn_at_simulation_edge is implemented in 1.16 beta, and there might be an easier way to implement this.
With despawn_at_simulation_edge implemented on sim4, the instant despawn at r44 can be removed, resolving this bug report. Also removing the hard-coded r44 will make behavior packs that change despawning mechanics work as expected on realms (data-driven game design), and also make the despawning mechanics match up with Java, within reason (parity).
This is a figure describing my proposal:
Steve is at 0,0. Blue are the sim4 simulated chunks. Green are the sim4 instant despawning chunk. The white donut is the spawning r24-r54 spawning range around the player, and the black circle is the r66 circle centered on the center of the center chunk (x=7,z=7).
The core issues here is Spawn > desapwn> no spawn. The proper arrangement is Despawn>= Spawn>=nospawn.
The quoted reason why the R44 is required for despawn is reliability of despawning. That reliability is jeopardized by allowing a mob to spawn at 54 then travel into unloaded chunks. I cannot think of a benefit of the mob spawning in the despawn zone. Forgetting about the numbers i think it is a must that Despawn>= Spawn>=nospawn.
I will say, from a game play perspective Despawn radius being as large as practical is ideal, but this bug is about the relative sizes.
I've attached a test world that contains an approximation of an early-game slime farm. Steve has built his work area at y=64 in a slime chunk and has built a slime spawning space at y=16. His goal is to passively collect slimeballs while he is farming, smelting, brewing, etc. (Imagine that Steve has a killing and collection area at y=16 as well.)
In 1.14.60, the farm works as expected. Slimes spawn at y=16 while Steve is at y=64.
In 1.16.0.61, the slime farm does not work as expected. All slimes instantly despawn at y=16, and the farm stops working. All the time that Steve has invested in building his slime farm has gone to waste. In fact, Steve probably will not know why his slime farm has stopped working. This has the same effect as the slime chunk issue that had to be reverted several versions ago.
SlimeChunkTest.mcworld
We can also infer that if Steve made a max slime farm, using all possible spawning spaces between y=0 and y=40, that his rates will be reduced in 1.16. I leave that exercise up to the reader.
I will note that if distance to nearest player is calculated not from the player's position, but to the center of the chunk the player is in (keeping y-level the same) then the instant despawn radius could be 56 on sim4 worlds. If spawning spheres were calculated similarly, then you would have a two-block distance between spawning and despawning.
It wouldn't promote parity like lazy chunks would, but would allow mob farms to use all of their spawning spaces again.
The idea of adding a new state to the state machine for chunks (lazy state) scares me this late in the update. Honestly this is an unpopular statements, but everything should probably be 44 for this update, and users are able to set their ticking area higher for now.
The game already has implemented a new type of chunk: simulation-edge chunks. They have been disabled in sim4 because they take up too much space (relatively). As I have proposed, they can be implemented efficiently on sim4 by adding an additional ring of chunks and disabling everything but simulation-edge despawning in that ring of chunks.
Given that Realms and sim4 simulation distance is one of Minecraft's primary sources of continued revenue, I don't think that shipping hard-coded r44 instant despawning in 1.16 is a good idea. Additionally it goes against parity and data-driven mechanics.
Forgetting about the wish for R=54
Despawing at 44 while spawning at 54 means that 42% of all mob spawns are just dead clock cycles.
It is really bad for the game. look at it this way, vaild spawning area =pi*(spawning radius)^2 - pi*(25)^2, area where mobs are not instantly despawned =pi*(despawn radius)^2 - pi*(25)^2
as an approximation you get 7197m2 spawn spawnable, and 4118 m2 as non-despawn
I am going to say again what is unpopular. in the current set of Minecraft spawn despawn conditions, For simulation distance 4, the spawn radius should be 44. The only reason it is not 44 is to falsely claim the update didn't change the spawn radius in a negative way. It is harmful to play on low end devices to keep it this way. It needs to change. there is 0 reason for the current situation.
The fix is extraordinarily simple. SpawnRadius=DespawnRadius. In the future lazy chunks or whatever else can be considered. but i would like to not simply burn double or more the CPU cycles as part of mob spawning.
Thanks to GoldenHelmet, I was able to test vertical despawning on 1.16.0.66. The results are consistent with my expectations:
sim4: instant despawing at r44.
sim6: instant despawning at r128
sim8: instant despawning at r128.
For java parity and consistency across simulation distances, the hardcoded r44 instant despawning needs to be removed from sim4/realms, and despawn at simulation edge implemented instead. Here is what it would look like:
The squares are the chunks in a ticking area on sim4. In green chunks, mobs instantly despawn. The white disc is the current spawning sphere, and the black circle is the r44 instant despawning sphere. Removing the r44 instant despawning and using green chunk instant despawning would restore the majority of the spawning volume while still preventing mobs from moving into unloaded chunks. This would also restore vertical drop mob farms and passive slime farms because r128 would be the vertical mob spawning distance.
This would also be a change to promote parity and data-driven game design.
Les villageois aussi disparaissent au bout d un certain temps
This is my proposition for this
Having the simulation areas and the despawn radius
If a mob leaves the simulation area or the 128 radius circle will despawn. The blue-tinted zone shows where mobs should instantly despawn.
I think this way is the most appropriate approach to this problem, as users do not need to know in which simulation distance they are, as it will be always the same behavior and radius for everyone when it comes to vertical behavior, and on sideways one, does not differ that much.
128 block radius sphere
4 Simulation distance 3D representation of the despawning area
For this to be achieved a lazy chunk system as @Reed Cartwright said would be a good way to go with.
In this way, players won't need to know what despawn radius sphere is needed for their simulation distance, and farms and other behaviors would be more universal.
Also connected to this:
https://bugs.mojang.com/browse/MCPE-65570?focusedCommentId=728136&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-728136
I've now gotten a chance to reverse engineer how the new despawning system works in 1.16, and have a proposal to bring proper despawn_from_simulation_edge to sim4.
Mobs are able to be simulation-edge despawned if they have been ticked and are in a chunk that neighbors an unticked chunk. At simulation distance of 4, the result looks like this:
The green chunks are the simulation edge chunks, and they clearly take up a lot of space on sim4. This is why r44 is a viable alternative on sim4.
However, if on sim4, simulation-edge is defined as chunks with two neighbors that are unticked, you get something that looks like this:
This produces a despawning area that on the diagonal is the same as r44, but opens up more area for spawning. This would also allow r128 despawning to function vertically, promoting parity and making sim4 work like sim6.
How to Implement
Update `BlockSource::hasUntickedNeighborChunk` to take a new parameter that represents how many unticked chunks are allowed. Passing `2` would indicate that game is looking for two or more chunks. This would be the default on sim4. On Sim6 and above, the game would pass a `1`. The modification is trivial to implement and can be made to quit as soon as the the 1st or 2nd unticked chunk is found.
I'd like to request this ticket to be re-opened because the release 1.16.20.03 that dropped today have r44 on all simulation distance, when the patch notes indicates its for sim. 4
To test what im saying:
@Pedro – that's a different bug. The original problem reported here is that the despawn radius of 44 at sim=4 was less than the spawn radius of 54, leading to needless spawn-despawn cycles. Apparently that was resolved. What you observe is a new issue, so you should open a new ticket.
Thanks you. I created a new ticket for this
MCPE-95568