This is a bug that has been in every version since about 1.6.
The problem is that monsters don't despawn when out of rendering range. For example: I can go to an area at night and have monsters spawn around me, then I leave, while it's still dark. And by leave I mean go out of chunk range. Any number of Minecraft days later, I can visit that same area again, middle of the day, and all the monsters that spawned [x] days ago will still be there, and won't start burning up/despawning until I can see them.
The problem with this is that the spawning/despawning code is not working properly, and I think it might be causing unnecessary lag.
Linked issues
relates to 2
Attachments
Comments 20
Yeah that's the thing though; it's out in the open plains in daylight, no trees or anything. And it's all the mobs that spawned, not just a few of them. I might try increasing my render distance to see if that helps, as I have it consistently at 5 chunks. I don't know if that makes a difference or not.
Another way to explain the issue is by comparing it to the Enderdragon freezing when it gets too far from the player. This happens with monsters but they don't despawn at that point, they just freeze until I go within range again.
The main reason this seems to be a problem to me is because I never saw it happen until about version 1.6. Before that monsters would automatically despawn when the player went out a certain distance. According to the wiki that's what's supposed to happen as well, but I'm just not seeing it now. :/
Ok I've attached a screenshot of me duplicating the problem. I went 90 blocks (which is about 5 chunks) from my house at night, let mobs spawn, then went back to my house. Slept through the night and then waiting until "noon" to go back to that area. The mobs didn't start burning or despawning until I could see them.
This does seem to be related to render distance in the video settings but again, mobs are supposed to automatically despawn when out of chunk range, instead of just freezing.
Huh. It's set to 6. That's very strange. I think this is some kind of mcprohost default file. I'm going to investigate into how it got to be this way. I forget what the default is...
Actually, the default is 10. I have not confirmed yet that setting it to 10 has completely fixed this, but in general, mob spawn rates shot up when we made this change. What we did notice is that the server memory demands also shot up, even with only two players online, which seems odd. I wonder if mcprohosting has their JVM arguments optimized properly, i.e. using incremental GC and such.
Now, if changing the view distance to 6 messed up the usual expected behavior of despawning mobs 128 blocks from the player, then this may reveal something about this bug. I get the impression that the view distance setting is having expected behavior horizontally – chunks unload, and mobs there don't affect the mob cap. On the other hand, vertically > 128 blocks, the mobs are definitely still loaded and definitely affecting the mob cap and seemingly still active to some degree. But the view distance is making it so that they don't despawn. In other words, the code is perhaps inconsistent in how it handles view distance vertically with regard to mob activity, spawning, and despawning, sometimes being affected by the view distance and sometimes not.
So, view_distance is a radius, in chunks, from the player that the server uses to decide what chunks to keep loaded. If we set that to 10, then (among other things) mob activity is being managed within a 160 block radius. Since mobs are supposed to despawn > 128 blocks, then this gives us a buffer on the order of 32 blocks where the server can notice that a mob is > 128 blocks form the player and despawn them.
On the other hand, if the view distance is set to 6 (apparently a default used by mcprohosting), then the server is only going to process up to 96 blocks from any user. That gives us a buffer of 32 blocks (between 96 and 128 from the user) where mobs can exist and contribute to the mob cap but will NEVER get despawned.
A major inconsistency here is that vertically, coordinates more than 96 from the user are STILL LOADED and therefore contributing to the mob cap, but the code that would despawn mobs > 128 from the player isn't even bothering to check that far away, which causes some major problems.
I think the spherical distance from the player for mob (de)spawning should be kept, and it should also be honored. So I think the best fix is to allow the despawn code to check for and despawn mobs outside of the view distance, as long as they are in loaded chunks. Maybe they won't spawn outside of the view distance, but that's not a problem. All the problems we encountered were caused by mobs not DEspawning outside of that range.
Spawnchunks could cause this if the distance was perfect and the mobs were in shade.