Paper
Paper copied to clipboard
PaperMC
[DEV-BRANCH] Rewrite chunk system
In the future, I want to experiment with ticking separate independent regions of the world in parallel. However, the current chunk system is just not up to that task: The scheduling is tied to the main thread, the chunk holder state is tied to the main thread, and the chunk system cannot fully utilise the worker threads it is given.
The new chunk system can be scheduled by any thread and as a result, the only time the chunk generation logic needs to go to the main thread is when it needs to execute generation/load logic that can only be done by the main thread (i.e loading in entity/poi chunks). As a result, chunk generation should be far less affected by lower TPS.
The new chunk system is also capable of executing several chunk status generation tasks in parallel. In my testing, chunky was capable of pushing all 8 threads I gave it for generating a new world, unlike the current chunk system.
Current things left to do before this can be merged:
- [ ] Verify stability (i.e no save/unload/shutdown/crash issues)
- [ ] Plugin compatibility
- [ ] Figure out a merge strategy that will allow for this patch to be dropped for game updates, ensuring that it cannot stall any update
- [ ] Complete the todo list
Current todo list:
- [x] Make the WatchdogThread and the main thread instances of TickThread and rewrite all of the main thread checks to just check for instanceof. This will result in allowing the watchdog thread to perform chunk system operations without worrying about stalling forever, which is a very common issue that prevents the world from properly saving.
- [x] Do not use ConcurrentHashMap for chunk holders. Need a solution that does not use any locks. Currently, CHM is used so the testing can validate the chunk system without worrying about the internal chunk holder map being broken.
- [ ] Make player chunk scheduling asynchronous. Currently, the main thread has to aggressively add and propagate ticket levels and do the initial scheduling work, which isn't negligible and requires mostly good TPS. Once the chunk scheduling is moved to its own thread, chunk generation speed should be mostly independent of TPS and frees the main thread of the burden.
- [ ] ALL of the TODO comments...
There are currently many aspects of the chunk system that need to be tested:
- Chunk generation
- Chunk loading
- Chunk (poi/entity/block) saving
- Chunk (poi/entity/block) unloading, especially with players that are passengers of an entity or entities that are passengers or vehicles
- All of the above combined with the server shutting down (there is a new shutdown process)
- Plugin compatibility (custom world generators for example)
In order to assist with debugging, I've rewritten /paper debug chunks and added a new command /paper holderinfo. The new paper holderinfo command can be used to see how many read only chunks are in memory as well as protochunks.
At this point, the chunk system is very new (in alpha) and as such will likely have problems that can result in data loss or even possibly corruption. Do not use this branch for anything you aren't OK with losing.
Current build: https://cdn.discordapp.com/attachments/876902758366736457/1007778048231346196/paper-paperclip-1.19.2-R0.1-SNAPSHOT-reobf.jar
chunks-2022-07-23_23.13.42.txt Pre-genned world, originally in 1.17. About a 5x5 chunks area below and ahead of me refusing to load at all.
Second time this happened in about 90 minutes of testing with several different worlds. Didn't know about the debug command the first time it happened, so no report from that. Other than this it seems to work pretty well so far, and is a noticeable improvement over the normal Paper build. Haven't tested anything related to saving though.
Done a little bit of testing with FastAsyncWorldEdit, and a Movecraft-Like Plugin I maintain, blocks are being set correctly server side, but those changes are not being sent to the client and are not visible to the client until a relog.
I don't know how FAWE does it, but the plugin I maintain does this with LevelChunkSection#setBlockState and uses ClientboundLevelChunkWithLightPacket to send updates. Both names are Mojang Mappings.
I don't know if any of this is helpful, I can do more testing if you want, just wanted to try and be somewhat helpful.
Perhaps worth finally closing out https://github.com/PaperMC/Paper/issues/1001 and its other couple children?
chunks-2022-07-23_23.13.42.txt Pre-genned world, originally in 1.17. About a 5x5 chunks area below and ahead of me refusing to load at all.
Second time this happened in about 90 minutes of testing with several different worlds. Didn't know about the debug command the first time it happened, so no report from that. Other than this it seems to work pretty well so far, and is a noticeable improvement over the normal Paper build. Haven't tested anything related to saving though.
Fixed in commit 7dd4845, jar has been updated
Done a little bit of testing with FastAsyncWorldEdit, and a Movecraft-Like Plugin I maintain, blocks are being set correctly server side, but those changes are not being sent to the client and are not visible to the client until a relog.
I don't know how FAWE does it, but the plugin I maintain does this with
LevelChunkSection#setBlockStateand usesClientboundLevelChunkWithLightPacketto send updates. Both names are Mojang Mappings.I don't know if any of this is helpful, I can do more testing if you want, just wanted to try and be somewhat helpful.
You need to provide code or i can't even begin to guess about this
I was able to get over 300 cps with chunky generation 🚀 the rat is running overdrive!!
This is some really interesting stuff, did a couple quickie performance comparisons to really get an idea of how this new chunk system works.
Five in total, all using Aikar's flags with 8GB allocated and with level-seed=0, generating a 2000 block radius (63001 chunks) in all 3 vanilla dimensions. Worlds completely deleted between each run.
I posted logs for all of these tests here but I'm just going to summarize the results below.
Test 1: paper-77 (old chunk system) as a control
overworld: 63001 chunks in 1038966 ms ≈ 60.6 chunks per second average
nether: 63001 chunks in 839342 ms ≈ 75.1 chunks per second average
end: 63001 chunks in 182556 ms ≈ 345.1 chunks per second average
Test 2: paper-7dd4845
overworld: 63001 chunks in 1098012 ms ≈ 57.4 chunks per second average (≈94% of control)
nether: 63001 chunks in 504580 ms ≈ 124.9 chunks per second average (≈166% of control)
end: 63001 chunks in 163540 ms ≈ 385.2 chunks per second average (≈111% of control)
Test 3: paper-7dd4845 (with -DPaper.WorkerThreadCount=16 -Dchunky.maxWorkingCount=200 flags added)
overworld: 63001 chunks in 514717 ms ≈ 122.4 chunks per second average (≈201% of control)
nether: 63001 chunks in 281947 ms ≈ 223.4 chunks per second average (≈297% of control)
end: 63001 chunks in 114282 ms ≈ 551.3 chunks per second average (≈159% of control)
Test 4: paper-7dd4845 (with only -DPaper.WorkerThreadCount=16 flag added)
overworld: 63001 chunks in 527374 ms ≈ 119.5 chunks per second average (≈197% of control)
nether: 63001 chunks in 294822 ms ≈ 213.7 chunks per second average (≈284% of control)
end: 63001 chunks in 123304 ms ≈ 510.9 chunks per second average (≈148% of control)
Test 5: paper-7dd4845 (with only -Dchunky.maxWorkingCount=200 flag added)
overworld: 63001 chunks in 1094049 ms ≈ 57.6 chunks per second average (≈94% of control)
nether: 63001 chunks in 512030 ms ≈ 123.0 chunks per second average (≈163% of control)
end: 63001 chunks in 134355 ms ≈ 468.9 chunks per second average (≈135% of control)
With otherwise default configs, the new chunk system seems to be noticeably faster, especially with more worker threads in Paper. I also played around with max working count but it didn't seem to have a noticeable impact.
The new chunk system looks to be able to achieve generation speeds up to about 2-3 times faster than previously. Though I acknowledge I did not actually test the control with the WorkerThreadCount flag, as I recall at least, it did not have nearly as much of an impact as with the new chunk system due to the bottlenecks in the old chunk system. If someone wants to go and confirm that, be my guest, but I think I've done enough testing of this for tonight. 😅
The jar has been updated to fix some unloading chunks not saving during shutdown, and to stagger chunk unloading across multiple ticks.
Jar has been updated to fix incorrect initial priority for I/O load tasks
I took a video for those who want to visually see how fast this new chunk system is. I tested it on an i7-8700k.
https://user-images.githubusercontent.com/53502121/181168820-5c9d6d63-f1d9-4449-98d0-f84e9e4d5c7c.mp4
java.lang.reflect.InvocationTargetException: null
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
at eu.okaeri.commands.meta.InvocationMeta.call(InvocationMeta.java:43) ~[screalms.jar:?]
at eu.okaeri.commands.bukkit.CommandsBukkit.handleExecution(CommandsBukkit.java:271) ~[screalms.jar:?]
at eu.okaeri.commands.bukkit.CommandsBukkit.executeCommand(CommandsBukkit.java:232) ~[screalms.jar:?]
at eu.okaeri.commands.bukkit.CommandsBukkit.access$000(CommandsBukkit.java:47) ~[screalms.jar:?]
at eu.okaeri.commands.bukkit.CommandsBukkit$Wrapper.execute(CommandsBukkit.java:182) ~[screalms.jar:?]
at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:155) ~[paper-api-1.19-R0.1-SNAPSHOT.jar:?]
at org.bukkit.craftbukkit.v1_19_R1.CraftServer.dispatchCommand(CraftServer.java:909) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at net.minecraft.server.network.ServerGamePacketListenerImpl.handleCommand(ServerGamePacketListenerImpl.java:2382) ~[?:?]
at net.minecraft.server.network.ServerGamePacketListenerImpl.lambda$handleChatCommand$18(ServerGamePacketListenerImpl.java:2153) ~[?:?]
at net.minecraft.server.TickTask.run(TickTask.java:18) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at net.minecraft.util.thread.BlockableEventLoop.doRunTask(BlockableEventLoop.java:153) ~[?:?]
at net.minecraft.util.thread.ReentrantBlockableEventLoop.doRunTask(ReentrantBlockableEventLoop.java:24) ~[?:?]
at net.minecraft.server.MinecraftServer.doRunTask(MinecraftServer.java:1349) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at net.minecraft.server.MinecraftServer.wrapRunnable(MinecraftServer.java:183) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at net.minecraft.util.thread.BlockableEventLoop.pollTask(BlockableEventLoop.java:126) ~[?:?]
at net.minecraft.server.MinecraftServer.pollTaskInternal(MinecraftServer.java:1326) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at net.minecraft.server.MinecraftServer.pollTask(MinecraftServer.java:1319) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at net.minecraft.util.thread.BlockableEventLoop.managedBlock(BlockableEventLoop.java:136) ~[?:?]
at net.minecraft.server.MinecraftServer.waitUntilNextTick(MinecraftServer.java:1297) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1182) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:303) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at java.lang.Thread.run(Unknown Source) ~[?:?]
Caused by: java.lang.UnsupportedOperationException
at org.bukkit.craftbukkit.v1_19_R1.entity.CraftEntity.teleportAsync(CraftEntity.java:539) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at org.bukkit.craftbukkit.v1_19_R1.entity.CraftPlayer.teleportAsync(CraftPlayer.java:1141) ~[paper-1.19.jar:git-Paper-"4ec2e6e"]
at org.bukkit.entity.Entity.teleportAsync(Entity.java:241) ~[paper-api-1.19-R0.1-SNAPSHOT.jar:?]
at dev.cdfn.screalms.bukkit.core.command.RealmCommand.tp(RealmCommand.kt:82) ~[screalms.jar:?]
... 26 more
Code which triggers this:
@Executor
@Completion(arg = ["realmUUID"], value = ["@uuidWorlds"])
fun tp(@Sender player: Player, @Arg realmUUID: RealmUUID) {
val world = plugin.server.getWorld(realmUUID.toString()) ?: throw IllegalArgumentException("non-loaded/existing realm uuid")
player.teleportAsync(world.spawnLocation)
}
This error occurs while attempting to use Player#teleportAsync method to world with no loaded chunks. I'm not sure if that's known or not so I thought it's better to report.
The jar has been updated to 1.19.1 and has fixed chunks/entity spawning and re-added incremental chunk saving
The jar has been updated to re-add async teleport api implementation, supports reading chunk data with the old regionfile thread api (for dynmap), adding unload queue information to /paper holderinfo and the /paper debug chunks commands, and finally re-adding sync load info for watchdog dumps as well as performing a chunk debug if the server stalls out from a sync load.
New jar has been updated. The build now contains a proper backing hash table for the chunk holders. Fixes a notable performance regression that was introduced by using ConcurrentHashMap, but of course is a new hash table so there may be new bugs.
where can i download latest jar? on top comment?
Yes: https://github.com/PaperMC/Paper/pull/8177#issue-1315739094
Jar has been updated to 1.19.2 with a small behavior fix and (probably not noticable) performance improvement
[09:36:00 ERROR]: Error whilst processing packet net.minecraft.network.protocol.game.PacketPlayInClientCommand@75daae80 for SavUToxic[/127.0.0.1:51439] java.lang.NullPointerException: Cannot invoke "io.papermc.paper.chunk.system.scheduling.NewChunkHolder.getChunkStatus()" because "chunkHolder" is null at net.minecraft.server.level.ServerChunkCache.getChunkFutureMainThread(ServerChunkCache.java:480) ~[?:?] at net.minecraft.server.level.ServerChunkCache.getChunk(ServerChunkCache.java:401) ~[?:?] at net.minecraft.world.level.Level.getChunk(Level.java:503) ~[?:?] at net.minecraft.world.level.Level.getChunk(Level.java:443) ~[?:?] at net.minecraft.server.level.PlayerRespawnLogic.getOverworldRespawnPos(PlayerRespawnLogic.java:18) ~[?:?] at net.minecraft.server.level.ServerPlayer.getSpawnPoint(ServerPlayer.java:385) ~[?:?] at net.minecraft.server.players.PlayerList.respawn(PlayerList.java:913) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.players.PlayerList.respawn(PlayerList.java:822) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.players.PlayerList.respawn(PlayerList.java:817) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.network.ServerGamePacketListenerImpl.handleClientCommand(ServerGamePacketListenerImpl.java:3045) ~[?:?] at net.minecraft.network.protocol.game.ServerboundClientCommandPacket.handle(ServerboundClientCommandPacket.java:24) ~[?:?] at net.minecraft.network.protocol.game.ServerboundClientCommandPacket.a(ServerboundClientCommandPacket.java:10) ~[?:?] at net.minecraft.network.protocol.PacketUtils.lambda$ensureRunningOnSameThread$1(PacketUtils.java:51) ~[?:?] at net.minecraft.server.TickTask.run(TickTask.java:18) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.util.thread.BlockableEventLoop.doRunTask(BlockableEventLoop.java:153) ~[?:?] at net.minecraft.util.thread.ReentrantBlockableEventLoop.doRunTask(ReentrantBlockableEventLoop.java:24) ~[?:?] at net.minecraft.server.MinecraftServer.doRunTask(MinecraftServer.java:1349) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.wrapRunnable(MinecraftServer.java:185) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.util.thread.BlockableEventLoop.pollTask(BlockableEventLoop.java:126) ~[?:?] at net.minecraft.server.MinecraftServer.pollTaskInternal(MinecraftServer.java:1326) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.pollTask(MinecraftServer.java:1319) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.util.thread.BlockableEventLoop.managedBlock(BlockableEventLoop.java:136) ~[?:?] at net.minecraft.server.MinecraftServer.waitUntilNextTick(MinecraftServer.java:1297) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1185) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:305) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at java.lang.Thread.run(Thread.java:833) ~[?:?] [09:36:00 INFO]: SavUToxic lost connection: Packet processing error
when i tried to use latest 1.19.2 updated paperclip jar (i just rename the jar name)
I've done some extensive testing of this branch with WorldEdit on my benchmark world, and it seems to marginally increase performance of a large edit across many chunks.
0.98s per 10 million blocks, down from 1.29s per 10 million blocks, with a 1000x1000x10 area
The same block count of a smaller chunk-area (250x400x100) produces barely any difference (1.23s per 10 million blocks)
My assumption here is that it's loading the chunks faster, allowing WorldEdit to wait less when setting blocks.
[09:36:00 ERROR]: Error whilst processing packet net.minecraft.network.protocol.game.PacketPlayInClientCommand@75daae80 for SavUToxic[/127.0.0.1:51439] java.lang.NullPointerException: Cannot invoke "io.papermc.paper.chunk.system.scheduling.NewChunkHolder.getChunkStatus()" because "chunkHolder" is null at net.minecraft.server.level.ServerChunkCache.getChunkFutureMainThread(ServerChunkCache.java:480) ~[?:?] at net.minecraft.server.level.ServerChunkCache.getChunk(ServerChunkCache.java:401) ~[?:?] at net.minecraft.world.level.Level.getChunk(Level.java:503) ~[?:?] at net.minecraft.world.level.Level.getChunk(Level.java:443) ~[?:?] at net.minecraft.server.level.PlayerRespawnLogic.getOverworldRespawnPos(PlayerRespawnLogic.java:18) ~[?:?] at net.minecraft.server.level.ServerPlayer.getSpawnPoint(ServerPlayer.java:385) ~[?:?] at net.minecraft.server.players.PlayerList.respawn(PlayerList.java:913) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.players.PlayerList.respawn(PlayerList.java:822) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.players.PlayerList.respawn(PlayerList.java:817) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.network.ServerGamePacketListenerImpl.handleClientCommand(ServerGamePacketListenerImpl.java:3045) ~[?:?] at net.minecraft.network.protocol.game.ServerboundClientCommandPacket.handle(ServerboundClientCommandPacket.java:24) ~[?:?] at net.minecraft.network.protocol.game.ServerboundClientCommandPacket.a(ServerboundClientCommandPacket.java:10) ~[?:?] at net.minecraft.network.protocol.PacketUtils.lambda$ensureRunningOnSameThread$1(PacketUtils.java:51) ~[?:?] at net.minecraft.server.TickTask.run(TickTask.java:18) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.util.thread.BlockableEventLoop.doRunTask(BlockableEventLoop.java:153) ~[?:?] at net.minecraft.util.thread.ReentrantBlockableEventLoop.doRunTask(ReentrantBlockableEventLoop.java:24) ~[?:?] at net.minecraft.server.MinecraftServer.doRunTask(MinecraftServer.java:1349) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.wrapRunnable(MinecraftServer.java:185) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.util.thread.BlockableEventLoop.pollTask(BlockableEventLoop.java:126) ~[?:?] at net.minecraft.server.MinecraftServer.pollTaskInternal(MinecraftServer.java:1326) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.pollTask(MinecraftServer.java:1319) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.util.thread.BlockableEventLoop.managedBlock(BlockableEventLoop.java:136) ~[?:?] at net.minecraft.server.MinecraftServer.waitUntilNextTick(MinecraftServer.java:1297) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1185) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:305) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at java.lang.Thread.run(Thread.java:833) ~[?:?] [09:36:00 INFO]: SavUToxic lost connection: Packet processing error
when i tried to use latest 1.19.2 updated paperclip jar (i just rename the jar name)
Minimal reproduction of this is creating a new world, doesn't occur when loading an existing world
[09:36:00 ERROR]: Error whilst processing packet net.minecraft.network.protocol.game.PacketPlayInClientCommand@75daae80 for SavUToxic[/127.0.0.1:51439] java.lang.NullPointerException: Cannot invoke "io.papermc.paper.chunk.system.scheduling.NewChunkHolder.getChunkStatus()" because "chunkHolder" is null at net.minecraft.server.level.ServerChunkCache.getChunkFutureMainThread(ServerChunkCache.java:480) ~[?:?] at net.minecraft.server.level.ServerChunkCache.getChunk(ServerChunkCache.java:401) ~[?:?] at net.minecraft.world.level.Level.getChunk(Level.java:503) ~[?:?] at net.minecraft.world.level.Level.getChunk(Level.java:443) ~[?:?] at net.minecraft.server.level.PlayerRespawnLogic.getOverworldRespawnPos(PlayerRespawnLogic.java:18) ~[?:?] at net.minecraft.server.level.ServerPlayer.getSpawnPoint(ServerPlayer.java:385) ~[?:?] at net.minecraft.server.players.PlayerList.respawn(PlayerList.java:913) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.players.PlayerList.respawn(PlayerList.java:822) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.players.PlayerList.respawn(PlayerList.java:817) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.network.ServerGamePacketListenerImpl.handleClientCommand(ServerGamePacketListenerImpl.java:3045) ~[?:?] at net.minecraft.network.protocol.game.ServerboundClientCommandPacket.handle(ServerboundClientCommandPacket.java:24) ~[?:?] at net.minecraft.network.protocol.game.ServerboundClientCommandPacket.a(ServerboundClientCommandPacket.java:10) ~[?:?] at net.minecraft.network.protocol.PacketUtils.lambda$ensureRunningOnSameThread$1(PacketUtils.java:51) ~[?:?] at net.minecraft.server.TickTask.run(TickTask.java:18) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.util.thread.BlockableEventLoop.doRunTask(BlockableEventLoop.java:153) ~[?:?] at net.minecraft.util.thread.ReentrantBlockableEventLoop.doRunTask(ReentrantBlockableEventLoop.java:24) ~[?:?] at net.minecraft.server.MinecraftServer.doRunTask(MinecraftServer.java:1349) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.wrapRunnable(MinecraftServer.java:185) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.util.thread.BlockableEventLoop.pollTask(BlockableEventLoop.java:126) ~[?:?] at net.minecraft.server.MinecraftServer.pollTaskInternal(MinecraftServer.java:1326) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.pollTask(MinecraftServer.java:1319) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.util.thread.BlockableEventLoop.managedBlock(BlockableEventLoop.java:136) ~[?:?] at net.minecraft.server.MinecraftServer.waitUntilNextTick(MinecraftServer.java:1297) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1185) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:305) ~[paper-1.19.2.jar:git-Paper-"5747a7b"] at java.lang.Thread.run(Thread.java:833) ~[?:?] [09:36:00 INFO]: SavUToxic lost connection: Packet processing error
when i tried to use latest 1.19.2 updated paperclip jar (i just rename the jar name)
Updated jar to fix this
Jar has been updated to latest paper, and now the new chunk system supports the duplicate entity config (which is broken in current paper master)
I have tested this on my resource server and it appears that the raid does not occur.
The only procedure to reproduce it is to run /effect give @s minecraft:bad_omen in the village.
So far, we have not encountered any plugin compatibility issues.
I understand this will not increase the speed of generating chunks?
I don't believe that is an inherent goal of the system but in tests me and others have been doing, there is oftentimes a good amount of performance to be found which seems to scale much better with a higher total threadcount on the server.
Yeah the performance increase in chunk generation is just a side bonus of what leaf is trying to achieve ultimately. 😎
I have tested this on my resource server and it appears that the raid does not occur. The only procedure to reproduce it is to run
/effect give @s minecraft:bad_omenin the village. So far, we have not encountered any plugin compatibility issues.
Updated jar to fix this
I found a bug that allay summoned by /summon allay dances, but allay spawned by outpost etc. does not dance when listening to music on the jukebox. replacing the jar with paper-1.19.2-125 fixes this bug.
I found a bug that allay summoned by
/summon allaydances, but allay spawned by outpost etc. does not dance when listening to music on the jukebox. replacing the jar with paper-1.19.2-125 fixes this bug.
Updated jar to fix this, this should also fix some other entity AI problems with game event listeners