geforkt von Mirrors/Paper
8c5b837e05
Firstly, the old methods all routed to the CompletableFuture method. However, the CF method could not guarantee that if the caller was off-main that the future would be "completed" on-main. Since the callback methods used the CF one, this meant that the callback methods did not guarantee that the callbacks were to be called on the main thread. Now, all methods route to getChunkAtAsync(x, z, gen, urgent, cb) so that the methods with the callback are guaranteed to invoke the callback on the main thread. The CF behavior remains unchanged; it may still appear to complete on main if invoked off-main. Secondly, remove the scheduleOnMain invocation in the async chunk completion. This unnecessarily delays the callback by 1 tick. Thirdly, add getChunksAtAsync(minX, minZ, maxX, maxZ, ...) which will load chunks within an area. This method is provided as a helper as keeping all chunks loaded within an area can be complicated to implement for plugins (due to the lacking ticket API), and is already implemented internally anyways. Fourthly, remove the ticket addition that occured with getChunkAt and getChunkAtAsync. The ticket addition may delay the unloading of the chunk unnecessarily. It also fixes a very rare timing bug where the future/callback would be completed after the chunk unloads.
36 Zeilen
2.0 KiB
Diff
36 Zeilen
2.0 KiB
Diff
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
|
|
From: Jason Penilla <11360596+jpenilla@users.noreply.github.com>
|
|
Date: Sat, 31 Oct 2020 11:49:01 -0700
|
|
Subject: [PATCH] Fix client lag on advancement loading
|
|
|
|
When new advancements are added via the UnsafeValues#loadAdvancement
|
|
API, it triggers a full datapack reload when this is not necessary. The
|
|
advancement is already loaded directly into the advancement registry,
|
|
and the point of saving the advancement to the Bukkit datapack seems to
|
|
be for persistence. By removing the call to reload datapacks when an
|
|
advancement is loaded, the client no longer completely freezes up when
|
|
adding a new advancement.
|
|
To ensure the client still receives the updated advancement data, we
|
|
manually reload the advancement data for all players, which
|
|
normally takes place as a part of the datapack reloading.
|
|
|
|
diff --git a/src/main/java/org/bukkit/craftbukkit/util/CraftMagicNumbers.java b/src/main/java/org/bukkit/craftbukkit/util/CraftMagicNumbers.java
|
|
index 09a6a0c06580aea9e7be8de2189673d1a476f411..e88b384e3d640dd77e419611f3c0e588fbf4f406 100644
|
|
--- a/src/main/java/org/bukkit/craftbukkit/util/CraftMagicNumbers.java
|
|
+++ b/src/main/java/org/bukkit/craftbukkit/util/CraftMagicNumbers.java
|
|
@@ -318,7 +318,13 @@ public final class CraftMagicNumbers implements UnsafeValues {
|
|
Bukkit.getLogger().log(Level.SEVERE, "Error saving advancement " + key, ex);
|
|
}
|
|
|
|
- MinecraftServer.getServer().getPlayerList().reloadResources();
|
|
+ // Paper start - Fix client lag on advancement loading
|
|
+ //MinecraftServer.getServer().getPlayerList().reload();
|
|
+ MinecraftServer.getServer().getPlayerList().getPlayers().forEach(player -> {
|
|
+ player.getAdvancements().reload(MinecraftServer.getServer().getAdvancements());
|
|
+ player.getAdvancements().flushDirty(player);
|
|
+ });
|
|
+ // Paper end - Fix client lag on advancement loading
|
|
|
|
return bukkit;
|
|
}
|