2015-05-25 12:37:24 +02:00
|
|
|
--- a/net/minecraft/server/ChunkRegionLoader.java
|
|
|
|
+++ b/net/minecraft/server/ChunkRegionLoader.java
|
2018-07-15 02:00:00 +02:00
|
|
|
@@ -34,7 +34,7 @@
|
|
|
|
private final File c;
|
|
|
|
private final DataFixer d;
|
|
|
|
private PersistentStructureLegacy e;
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
- private boolean f;
|
2018-07-15 02:00:00 +02:00
|
|
|
+ // private boolean f; // CraftBukkit
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
public ChunkRegionLoader(File file, DataFixer datafixer) {
|
|
|
|
this.c = file;
|
|
|
|
@@ -50,12 +50,13 @@
|
|
|
|
|
|
|
|
@Nullable
|
|
|
|
private NBTTagCompound b(GeneratorAccess generatoraccess, int i, int j) throws IOException {
|
|
|
|
- DataInputStream datainputstream = RegionFileCache.d(this.c, i, j);
|
|
|
|
+ // CraftBukkit start
|
|
|
|
+ NBTTagCompound nbttagcompound = RegionFileCache.d(this.c, i, j);
|
|
|
|
|
|
|
|
- if (datainputstream == null) {
|
|
|
|
+ if (nbttagcompound == null) {
|
|
|
|
return null;
|
|
|
|
} else {
|
|
|
|
- NBTTagCompound nbttagcompound = NBTCompressedStreamTools.a(datainputstream);
|
|
|
|
+ // CraftBukkit end
|
|
|
|
int k = nbttagcompound.hasKeyOfType("DataVersion", 99) ? nbttagcompound.getInt("DataVersion") : -1;
|
|
|
|
|
|
|
|
if (k < 1493) {
|
|
|
|
@@ -78,13 +79,29 @@
|
|
|
|
}
|
2014-11-25 22:32:16 +01:00
|
|
|
}
|
2015-02-26 23:41:06 +01:00
|
|
|
|
2014-11-25 22:32:16 +01:00
|
|
|
+ // CraftBukkit start - Add async variant, provide compatibility
|
2016-05-10 13:47:39 +02:00
|
|
|
@Nullable
|
2018-07-15 02:00:00 +02:00
|
|
|
public synchronized Chunk a(GeneratorAccess generatoraccess, int i, int j, Consumer<Chunk> consumer) throws IOException {
|
|
|
|
+ Object[] data = loadChunk(generatoraccess, i, j, consumer);
|
2014-11-25 22:32:16 +01:00
|
|
|
+ if (data != null) {
|
|
|
|
+ Chunk chunk = (Chunk) data[0];
|
|
|
|
+ NBTTagCompound nbttagcompound = (NBTTagCompound) data[1];
|
2018-07-15 02:00:00 +02:00
|
|
|
+ consumer.accept(chunk);
|
|
|
|
+ this.loadEntities(nbttagcompound.getCompound("Level"), chunk);
|
2014-11-25 22:32:16 +01:00
|
|
|
+ return chunk;
|
|
|
|
+ }
|
2015-02-26 23:41:06 +01:00
|
|
|
+
|
2014-11-25 22:32:16 +01:00
|
|
|
+ return null;
|
|
|
|
+ }
|
2015-02-26 23:41:06 +01:00
|
|
|
+
|
2018-07-15 02:00:00 +02:00
|
|
|
+ public synchronized Object[] loadChunk(GeneratorAccess generatoraccess, int i, int j, Consumer<Chunk> consumer) throws IOException {
|
2014-11-25 22:32:16 +01:00
|
|
|
+ // CraftBukkit end
|
2018-07-15 02:00:00 +02:00
|
|
|
NBTTagCompound nbttagcompound = this.a(generatoraccess, i, j);
|
2015-05-05 22:43:47 +02:00
|
|
|
|
2016-06-12 11:28:27 +02:00
|
|
|
if (nbttagcompound == null) {
|
2018-07-15 02:00:00 +02:00
|
|
|
return null;
|
|
|
|
} else {
|
|
|
|
+ /*
|
|
|
|
Chunk chunk = this.a(generatoraccess, i, j, nbttagcompound);
|
2016-06-12 11:28:27 +02:00
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
if (chunk != null) {
|
|
|
|
@@ -93,6 +110,9 @@
|
2016-06-12 11:28:27 +02:00
|
|
|
}
|
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
return chunk;
|
|
|
|
+ */
|
|
|
|
+
|
|
|
|
+ return this.a(generatoraccess, i, j, nbttagcompound);
|
2016-06-12 11:28:27 +02:00
|
|
|
}
|
2018-07-15 02:00:00 +02:00
|
|
|
}
|
2016-06-12 11:28:27 +02:00
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
@@ -121,7 +141,7 @@
|
2014-11-25 22:32:16 +01:00
|
|
|
}
|
|
|
|
|
2016-11-17 02:41:03 +01:00
|
|
|
@Nullable
|
2018-07-15 02:00:00 +02:00
|
|
|
- protected Chunk a(GeneratorAccess generatoraccess, int i, int j, NBTTagCompound nbttagcompound) {
|
|
|
|
+ protected Object[] a(GeneratorAccess generatoraccess, int i, int j, NBTTagCompound nbttagcompound) { // CraftBukkit - return Chunk -> Object[]
|
|
|
|
if (nbttagcompound.hasKeyOfType("Level", 10) && nbttagcompound.getCompound("Level").hasKeyOfType("Status", 8)) {
|
|
|
|
ChunkStatus.Type chunkstatus_type = this.a(nbttagcompound);
|
|
|
|
|
|
|
|
@@ -140,10 +160,28 @@
|
|
|
|
ChunkRegionLoader.a.error("Chunk file at {},{} is in the wrong location; relocating. (Expected {}, {}, got {}, {})", Integer.valueOf(i), Integer.valueOf(j), Integer.valueOf(i), Integer.valueOf(j), Integer.valueOf(chunk.locX), Integer.valueOf(chunk.locZ));
|
|
|
|
nbttagcompound1.setInt("xPos", i);
|
|
|
|
nbttagcompound1.setInt("zPos", j);
|
2015-02-26 23:41:06 +01:00
|
|
|
+
|
2018-07-15 02:00:00 +02:00
|
|
|
+ // CraftBukkit start - Have to move tile entities since we don't load them at this stage
|
|
|
|
+ NBTTagList tileEntities = nbttagcompound.getCompound("Level").getList("TileEntities", 10);
|
|
|
|
+ if (tileEntities != null) {
|
|
|
|
+ for (int te = 0; te < tileEntities.size(); te++) {
|
|
|
|
+ NBTTagCompound tileEntity = (NBTTagCompound) tileEntities.get(te);
|
|
|
|
+ int x = tileEntity.getInt("x") - chunk.locX * 16;
|
|
|
|
+ int z = tileEntity.getInt("z") - chunk.locZ * 16;
|
|
|
|
+ tileEntity.setInt("x", i * 16 + x);
|
|
|
|
+ tileEntity.setInt("z", j * 16 + z);
|
|
|
|
+ }
|
2015-02-26 23:41:06 +01:00
|
|
|
+ }
|
2018-07-15 02:00:00 +02:00
|
|
|
+ // CraftBukkit end
|
|
|
|
chunk = this.a(generatoraccess, nbttagcompound1);
|
|
|
|
}
|
|
|
|
|
|
|
|
- return chunk;
|
|
|
|
+ // CraftBukkit start
|
|
|
|
+ Object[] data = new Object[2];
|
|
|
|
+ data[0] = chunk;
|
|
|
|
+ data[1] = nbttagcompound;
|
|
|
|
+ return data;
|
2015-02-26 23:41:06 +01:00
|
|
|
+ // CraftBukkit end
|
|
|
|
}
|
2014-11-25 22:32:16 +01:00
|
|
|
}
|
2018-07-15 02:00:00 +02:00
|
|
|
} else {
|
|
|
|
@@ -158,7 +196,7 @@
|
|
|
|
ChunkStatus.Type chunkstatus_type = this.a(nbttagcompound);
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
if (chunkstatus_type == ChunkStatus.Type.LEVELCHUNK) {
|
|
|
|
- return new ProtoChunkExtension(this.a(generatoraccess, i, j, nbttagcompound));
|
|
|
|
+ return new ProtoChunkExtension((IChunkAccess) this.a(generatoraccess, i, j, nbttagcompound)[0]); // CraftBukkit - fix up access
|
|
|
|
} else {
|
|
|
|
NBTTagCompound nbttagcompound1 = nbttagcompound.getCompound("Level");
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
@@ -204,19 +242,30 @@
|
2016-08-27 07:51:54 +02:00
|
|
|
}
|
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
public synchronized boolean a() {
|
2016-08-27 07:51:54 +02:00
|
|
|
- if (this.b.isEmpty()) {
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
- if (this.f) {
|
2016-08-27 07:51:54 +02:00
|
|
|
+ // CraftBukkit start
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
+ return this.processSaveQueueEntry(false);
|
|
|
|
+ }
|
|
|
|
+
|
|
|
|
+ private synchronized boolean processSaveQueueEntry(boolean logCompletion) {
|
2016-08-27 07:51:54 +02:00
|
|
|
+ Iterator<Map.Entry<ChunkCoordIntPair, NBTTagCompound>> iter = this.b.entrySet().iterator();
|
|
|
|
+ if (!iter.hasNext()) {
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
+ if (logCompletion) {
|
|
|
|
+ // CraftBukkit end
|
2018-07-15 02:00:00 +02:00
|
|
|
ChunkRegionLoader.a.info("ThreadedAnvilChunkStorage ({}): All chunks are saved", this.c.getName());
|
2016-08-27 07:51:54 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
} else {
|
|
|
|
- ChunkCoordIntPair chunkcoordintpair = (ChunkCoordIntPair) this.b.keySet().iterator().next();
|
|
|
|
+ // CraftBukkit start
|
|
|
|
+ Map.Entry<ChunkCoordIntPair, NBTTagCompound> entry = iter.next();
|
|
|
|
+ ChunkCoordIntPair chunkcoordintpair = entry.getKey();
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
+ NBTTagCompound nbttagcompound = entry.getValue();
|
2016-08-27 07:51:54 +02:00
|
|
|
+ // CraftBukkit end
|
|
|
|
|
|
|
|
boolean flag;
|
|
|
|
|
|
|
|
try {
|
2018-07-15 02:00:00 +02:00
|
|
|
- NBTTagCompound nbttagcompound = (NBTTagCompound) this.b.get(chunkcoordintpair);
|
|
|
|
+ // NBTTagCompound nbttagcompound = (NBTTagCompound) this.b.get(chunkcoordintpair); // CraftBukkit
|
2016-08-27 07:51:54 +02:00
|
|
|
|
|
|
|
if (nbttagcompound != null) {
|
|
|
|
try {
|
2018-07-15 02:00:00 +02:00
|
|
|
@@ -228,7 +277,7 @@
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
|
|
|
|
flag = true;
|
|
|
|
} finally {
|
2018-07-15 02:00:00 +02:00
|
|
|
- this.b.remove(chunkcoordintpair);
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
+ this.b.remove(chunkcoordintpair, nbttagcompound); // CraftBukkit
|
|
|
|
}
|
|
|
|
|
|
|
|
return flag;
|
2018-07-15 02:00:00 +02:00
|
|
|
@@ -248,10 +297,14 @@
|
2016-06-12 11:28:27 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
private void b(ChunkCoordIntPair chunkcoordintpair, NBTTagCompound nbttagcompound) throws IOException {
|
2018-07-15 02:00:00 +02:00
|
|
|
- DataOutputStream dataoutputstream = RegionFileCache.e(this.c, chunkcoordintpair.x, chunkcoordintpair.z);
|
2016-06-12 11:28:27 +02:00
|
|
|
+ // CraftBukkit start
|
2018-07-15 02:00:00 +02:00
|
|
|
+ RegionFileCache.e(this.c, chunkcoordintpair.x, chunkcoordintpair.z, nbttagcompound);
|
2016-06-12 11:28:27 +02:00
|
|
|
|
|
|
|
+ /*
|
|
|
|
NBTCompressedStreamTools.a(nbttagcompound, (DataOutput) dataoutputstream);
|
|
|
|
dataoutputstream.close();
|
|
|
|
+ */
|
|
|
|
+ // CraftBukkit end
|
2018-07-15 02:00:00 +02:00
|
|
|
if (this.e != null) {
|
|
|
|
this.e.a(chunkcoordintpair.a());
|
|
|
|
}
|
|
|
|
@@ -264,15 +317,16 @@
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
|
|
|
|
public void c() {
|
|
|
|
try {
|
|
|
|
- this.f = true;
|
|
|
|
+ // this.f = true; // CraftBukkit
|
|
|
|
|
|
|
|
while (true) {
|
|
|
|
- if (this.a()) {
|
|
|
|
+ if (this.processSaveQueueEntry(true)) { // CraftBukkit
|
2016-06-18 13:25:50 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
+ break; // CraftBukkit - Fix infinite loop when saving chunks
|
|
|
|
}
|
|
|
|
} finally {
|
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
2017-08-11 09:27:33 +02:00
|
|
|
- this.f = false;
|
|
|
|
+ // this.f = false; // CraftBukkit
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
2018-07-15 02:00:00 +02:00
|
|
|
@@ -301,7 +355,7 @@
|
|
|
|
|
|
|
|
if (abiomebase != null) {
|
|
|
|
for (int k = 0; k < abiomebase.length; ++k) {
|
|
|
|
- aint[k] = BiomeBase.REGISTRY_ID.a((Object) abiomebase[k]);
|
|
|
|
+ aint[k] = BiomeBase.REGISTRY_ID.a(abiomebase[k]); // CraftBukkit - decompile error
|
|
|
|
}
|
2014-11-25 22:32:16 +01:00
|
|
|
}
|
2015-02-26 23:41:06 +01:00
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
@@ -383,7 +437,7 @@
|
|
|
|
int[] aint = new int[abiomebase.length];
|
2014-11-25 22:32:16 +01:00
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
for (int i = 0; i < abiomebase.length; ++i) {
|
|
|
|
- aint[i] = BiomeBase.REGISTRY_ID.a((Object) abiomebase[i]);
|
|
|
|
+ aint[i] = BiomeBase.REGISTRY_ID.a(abiomebase[i]); // CraftBukkit - decompile error
|
2014-11-25 22:32:16 +01:00
|
|
|
}
|
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
nbttagcompound.setIntArray("Biomes", aint);
|
|
|
|
@@ -485,7 +539,7 @@
|
|
|
|
}
|
2016-02-29 22:32:46 +01:00
|
|
|
|
2018-07-15 02:00:00 +02:00
|
|
|
ChunkConverter chunkconverter = nbttagcompound.hasKeyOfType("UpgradeData", 10) ? new ChunkConverter(nbttagcompound.getCompound("UpgradeData")) : ChunkConverter.a;
|
|
|
|
- Predicate predicate = (block) -> {
|
|
|
|
+ Predicate<Block> predicate = (block) -> { // CraftBukkit - decompile error
|
|
|
|
return block.getBlockData().isAir();
|
|
|
|
};
|
|
|
|
RegistryBlocks registryblocks = Block.REGISTRY;
|
|
|
|
@@ -497,7 +551,7 @@
|
|
|
|
Block.REGISTRY.getClass();
|
|
|
|
ProtoChunkTickList protochunkticklist = new ProtoChunkTickList(predicate, function, registryblocks1::get, new ChunkCoordIntPair(i, j));
|
|
|
|
|
|
|
|
- predicate = (fluidtype) -> {
|
|
|
|
+ Predicate<FluidType> predicate1 = (fluidtype) -> { // CraftBukkit - decompile error
|
|
|
|
return fluidtype == FluidTypes.a;
|
|
|
|
};
|
|
|
|
registryblocks = FluidType.c;
|
|
|
|
@@ -505,7 +559,7 @@
|
|
|
|
function = registryblocks::b;
|
|
|
|
registryblocks1 = FluidType.c;
|
|
|
|
FluidType.c.getClass();
|
|
|
|
- ProtoChunkTickList protochunkticklist1 = new ProtoChunkTickList(predicate, function, registryblocks1::get, new ChunkCoordIntPair(i, j));
|
|
|
|
+ ProtoChunkTickList protochunkticklist1 = new ProtoChunkTickList(predicate1, function, registryblocks1::get, new ChunkCoordIntPair(i, j)); // CraftBukkit - decompile error
|
|
|
|
long i1 = nbttagcompound.getLong("InhabitedTime");
|
|
|
|
Chunk chunk = new Chunk(generatoraccess.getMinecraftWorld(), i, j, abiomebase, chunkconverter, protochunkticklist, protochunkticklist1, i1);
|
|
|
|
|
|
|
|
@@ -852,17 +906,29 @@
|
2016-06-09 03:43:49 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
@Nullable
|
|
|
|
+ // CraftBukkit start
|
|
|
|
public static Entity a(NBTTagCompound nbttagcompound, World world, double d0, double d1, double d2, boolean flag) {
|
|
|
|
+ return spawnEntity(nbttagcompound, world, d0, d1, d2, flag, org.bukkit.event.entity.CreatureSpawnEvent.SpawnReason.DEFAULT);
|
|
|
|
+ }
|
|
|
|
+
|
|
|
|
+ public static Entity spawnEntity(NBTTagCompound nbttagcompound, World world, double d0, double d1, double d2, boolean flag, org.bukkit.event.entity.CreatureSpawnEvent.SpawnReason spawnReason) {
|
|
|
|
+ // CraftBukkit end
|
2018-07-15 02:00:00 +02:00
|
|
|
return a(nbttagcompound, world, (entity) -> {
|
2016-06-09 03:43:49 +02:00
|
|
|
entity.setPositionRotation(d0, d1, d2, entity.yaw, entity.pitch);
|
2018-07-15 02:00:00 +02:00
|
|
|
- return flag && !world.addEntity(entity) ? null : entity;
|
|
|
|
+ return flag && !world.addEntity(entity, spawnReason) ? null : entity;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
@Nullable
|
|
|
|
+ // CraftBukkit start
|
|
|
|
public static Entity a(NBTTagCompound nbttagcompound, World world, boolean flag) {
|
|
|
|
+ return spawnEntity(nbttagcompound, world, flag, org.bukkit.event.entity.CreatureSpawnEvent.SpawnReason.DEFAULT);
|
|
|
|
+ }
|
|
|
|
+
|
|
|
|
+ public static Entity spawnEntity(NBTTagCompound nbttagcompound, World world, boolean flag, org.bukkit.event.entity.CreatureSpawnEvent.SpawnReason spawnReason) {
|
|
|
|
+ // CraftBukkit end
|
|
|
|
return a(nbttagcompound, world, (entity) -> {
|
|
|
|
- return flag && !world.addEntity(entity) ? null : entity;
|
|
|
|
+ return flag && !world.addEntity(entity, spawnReason) ? null : entity; // CraftBukkit
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
@@ -876,8 +942,14 @@
|
2016-02-29 22:32:46 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
+ // CraftBukkit start
|
2018-07-15 02:00:00 +02:00
|
|
|
public static void a(Entity entity, GeneratorAccess generatoraccess) {
|
|
|
|
- if (generatoraccess.addEntity(entity) && entity.isVehicle()) {
|
|
|
|
+ a(entity, generatoraccess, org.bukkit.event.entity.CreatureSpawnEvent.SpawnReason.DEFAULT);
|
2016-02-29 22:32:46 +01:00
|
|
|
+ }
|
|
|
|
+
|
2018-07-15 02:00:00 +02:00
|
|
|
+ public static void a(Entity entity, GeneratorAccess generatoraccess, org.bukkit.event.entity.CreatureSpawnEvent.SpawnReason reason) {
|
|
|
|
+ if (generatoraccess.addEntity(entity, reason) && entity.isVehicle()) {
|
2016-02-29 22:32:46 +01:00
|
|
|
+ // CraftBukkit end
|
2018-07-15 02:00:00 +02:00
|
|
|
Iterator iterator = entity.bP().iterator();
|
2016-02-29 22:32:46 +01:00
|
|
|
|
|
|
|
while (iterator.hasNext()) {
|