Mob spawning issues - 'fix'. See below for ideal reasoning from MikePrimm, however until ideal reasoning we must live with the CraftBukkit / Vanilla behaviour since this causes far too many issues.
IIRC, the main item I was driving towards was a consequence of persistent passive mobs - specifically, the fact that allowing a population limit of N (independent of view distance, which is what vanilla does) when your view distance limits actual loaded chunks to a much smaller area than default (say a view of 4, which would be 9 x 9 chunks loaded per player - and spawnable - versus default, which is 8 radius spawn, or 17 x 17 chunks) tends to result in more mobs per chunk. For persistent mobs, this is bad - since they count for server load and for population just by being loaded, versus being despawned beyond 128 blocks (8 chunk radius - unconditional of view distance, as well) - so they can cause the population limit to be reached more easily, cutting off spawning nearer to players. The goal was to make it so that the mobs-per-loaded-chunk was about the same for all view distances, versus having low view distances cause higher mob concentrations.
Now, all of this assumes that loaded chunks beyond those around players are modest (since they could contain passive mobs that would count towards the limits) - which they should be, except that recent CBs leak chunks like mad, from what I can see (chunk-gc has become more required than optional), and I think there may be some issues with even hostile mobs "lurking" around - possibly even after their chunks are unloaded. Anything that causes more mobs to be in places players don't see them is going to drive population limit issues, and resulting low spawn behaviors. The trick for us, trying to make big servers as practical as possible, is to shift the math the other way - given low view distances, how to best make sure that folks get reasonable spawn behavior while minimizing the time/resources spent on the server on mobs that don't help that. Realistically, I think we need to analyse the mob demographics better - especially as it relates to lower view distances (our changes have no net impact on view distances above 7) - particularly to understand how the proportion of "useful" mobs is working out (ones close enough to players to be considered contributing to game play). One thought is to manage the population limit based on mobs that are 'tickable' - if they aren't close enough to be ticking, they aren't interesting. This is likely a big issue for view distance 5 folks, since mobs cannot spawn closer than 24 (approx 1 chunk radius, given that middle chunk is 0), and don't tick when any of the chunks within a 2 chunk radius aren't loaded) - so, effectively, they "live" within a zone of 7 x 7 with the middle 3 x 3 removed (so, about 40 chunks) out of a total load zone of 11 x 11 (121) - so about 2/3 of the area containing mobs has idle mobs. Normal view distance would result in mobs ticking as far out as they can spawn (radius 8 versus a load radius of 11), so 100% of the mobs that spawn are ticking when they spawn, and all hostile mobs that are loaded are ticking (since they always despawn beyond 128 blocks / 8 chunks from a player). One interesting thought would be to limit the chunks we spawn mobs in to those where they would be ticking initially (that is, view-distance minus 2 or 3).
2013-01-29 06:54:36 +01:00
From 2c5bbb8b0dca630b5035d88335f810d39d065eb6 Mon Sep 17 00:00:00 2001
2013-01-18 12:27:42 +01:00
From: Ammar Askar <ammar@ammaraskar.com>
Date: Fri, 18 Jan 2013 16:20:01 +0500
2013-01-19 09:22:25 +01:00
Subject: [PATCH] Optimize packet used to unload chunks for the client
2013-01-18 12:27:42 +01:00
At the moment telling a client to unload a chunk involves calling the entire chunk from memory, deflating it and then sending it through the pipes even though the client ignores it and based on the bitmap simply unloads the chunk, and to add the cherry on top, this is done on the main server thread.
---
src/main/java/net/minecraft/server/Packet51MapChunk.java | 13 +++++++++++++
src/main/java/net/minecraft/server/PlayerChunk.java | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/main/java/net/minecraft/server/Packet51MapChunk.java b/src/main/java/net/minecraft/server/Packet51MapChunk.java
index ee179be..b51d90c 100644
--- a/src/main/java/net/minecraft/server/Packet51MapChunk.java
+++ b/src/main/java/net/minecraft/server/Packet51MapChunk.java
@@ -18,11 +18,24 @@ public class Packet51MapChunk extends Packet {
public boolean e;
private int size;
private static byte[] buildBuffer = new byte[196864];
+ private static final byte[] unloadSequence = new byte[]{0x78, (byte) 0x9C, 0x63, 0x64, 0x1C, (byte) 0xD9, 0x00, 0x00, (byte) 0x81, (byte) 0x80, 0x01, 0x01}; // Spigot
public Packet51MapChunk() {
this.lowPriority = true;
}
+ // Spigot start - add constructor for chunk removals for the client
+ public Packet51MapChunk(int x, int z) {
+ this.a = x;
+ this.b = z;
+ this.e = true;
+ this.c = 0;
+ this.d = 0;
+ this.size = unloadSequence.length;
+ this.buffer = unloadSequence;
+ }
+ // Spigot end
+
public Packet51MapChunk(Chunk chunk, boolean flag, int i) {
this.lowPriority = true;
this.a = chunk.x;
diff --git a/src/main/java/net/minecraft/server/PlayerChunk.java b/src/main/java/net/minecraft/server/PlayerChunk.java
index 5350644..185a609 100644
--- a/src/main/java/net/minecraft/server/PlayerChunk.java
+++ b/src/main/java/net/minecraft/server/PlayerChunk.java
@@ -51,7 +51,7 @@ class PlayerChunk {
public void b(EntityPlayer entityplayer) {
if (this.b.contains(entityplayer)) {
- entityplayer.playerConnection.sendPacket(new Packet51MapChunk(PlayerChunkMap.a(this.playerChunkMap).getChunkAt(this.location.x, this.location.z), true, 0));
+ entityplayer.playerConnection.sendPacket(new Packet51MapChunk(this.location.x, this.location.z)); // Spigot - remove chunk load call just to unload in favour of specialized constructor
this.b.remove(entityplayer);
entityplayer.chunkCoordIntPairQueue.remove(this.location);
if (this.b.isEmpty()) {
--
1.8.1-rc2
