diff --git a/patches/api/0001-Tuinity-API-Changes.patch b/patches/api/0001-Tuinity-API-Changes.patch index cbefa4842..69991cdcf 100644 --- a/patches/api/0001-Tuinity-API-Changes.patch +++ b/patches/api/0001-Tuinity-API-Changes.patch @@ -3,13 +3,18 @@ From: Spottedleaf Date: Sat, 21 Mar 2020 20:12:48 -0700 Subject: [PATCH] Tuinity API Changes -API to retrieve raw YamlConfiguration + timing exports +This program is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 3 of the License, or +(at your option) any later version. -Per player viewdistances +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. -Add per player no-tick, tick, and send view distances. - -Also add send view distance to World. +You should have received a copy of the GNU General Public License +along with this program. If not, see . diff --git a/src/main/java/org/bukkit/Server.java b/src/main/java/org/bukkit/Server.java index f05edac8cdd33daaf1d15a526be4d2ac2b08846d..8776b8368d2046dee02e927de8249030bdddf2ee 100644 diff --git a/patches/server/0001-Tuinity-Server-Changes.patch b/patches/server/0001-Tuinity-Server-Changes.patch index f200a103d..a06b030bd 100644 --- a/patches/server/0001-Tuinity-Server-Changes.patch +++ b/patches/server/0001-Tuinity-Server-Changes.patch @@ -3,512 +3,18 @@ From: Spottedleaf Date: Sat, 12 Jun 2021 16:40:34 +0200 Subject: [PATCH] Tuinity Server Changes -Update version fetcher repo - -Sets the target github repo to Tuinity in the version checker. Also disables the jenkins build lookups. - -This patch is licensed under the MIT license. See /licenses/MIT.md. - -MC-Dev fixes - -Util patch - -Tuinity Server Config - -Fix incorrect isRealPlayer init - -Some plugins, namely ProtocolSupport, don't route to where -paper placed their logic. So it wont correctly set in this case. - -Fix by moving it to a different place. - -Optimise general POI access - -There are a couple of problems with mojang's POI code. -Firstly, it's all streams. Unsurprisingly, stacking -streams on top of each other is horrible for performance -and ultimately took up half of a villager's tick! - -Secondly, sometime's the search radius is large and there are -a significant number of poi entries per chunk section. Even -removing streams at this point doesn't help much. The only solution -is to start at the search point and iterate outwards. This -type of approach shows massive gains for portals, simply because -we can avoid sync loading a large area of chunks. I also tested -a massive farm I found in JellySquid's discord, which showed -to benefit significantly simply because the farm had so many -portal blocks that searching through them all was very slow. - -Great care has been taken so that behavior remains identical to -vanilla, however I cannot account for oddball Stream API -implementations, if they even exist (streams can technically -be loose with iteration order in a sorted stream given its -source stream is not tagged with ordered, and mojang does not -tag the source stream as ordered). However in my testing on openjdk -there showed no difference, as expected. - -This patch also specifically optimises other areas of code to -use PoiAccess. For example, some villager AI and portaling code -had to be specifically modified. - -Allow controlled flushing for network manager - -Only make one flush call when emptying the packet queue too - -This patch will be used to optimise out flush calls in later -patches. - -Not implemeneted - -Currently a placeholder patch. - -Add more async catchers - -Rewrite the light engine - -The standard vanilla light engine is plagued by -awful performance. Paper's changes to the light engine -help a bit, however they appear to cause some lighting -errors - most easily noticed in coral generation. - -The vanilla light engine's is too abstract to be modified - -so an entirely new implementation is required to fix the -performance and lighting errors. - -The new implementation is designed primarily to optimise -light level propagations (increase and decrease). Unlike -the vanilla light engine, this implementation tracks more -information per queued value when performing a -breadth first search. Vanilla just tracks coordinate, which -means every time they handle a queued value, they must -also determine the coordinate's target light level -from its neighbours - very wasteful, especially considering -these checks read neighbour block data. -The new light engine tracks both position and target level, -as well as whether the target block needs to be read at all -(for checking sided propagation). So, the work done per coordinate -is significantly reduced because no work is done for calculating -the target level. -In my testing, the block get calls were reduced by approximately -an order of magnitude. However, the light read checks were only -reduced by approximately 2x - but this is fine, light read checks -are extremely cheap compared to block gets. - -Generation testing showed that the new light engine improved -total generation (not lighting itself, but the whole generation process) -by 2x. According to cpu time, the light engine itself spent 10x less time -lighting chunks for generation. - -Rewrite entity bounding box lookup calls - -For whatever reason, Mojang thought it was OK to make this system -scale logn relative to the number of entity sections loaded. -On top of that, they do a hashtable lookup per section - before -this was just a basic array access. - -This patch brings back entity slices for lookup only. - -Highly optimise single and multi-AABB VoxelShapes and collisions - -Optimise chunk tick iteration - -Use a dedicated list of entity ticking chunks to reduce the cost - -Execute chunk tasks mid-tick - -This will help the server load chunks if tick times are high. - -Change writes to use NORMAL priority rather than LOW - -Should limit build up of I/O tasks, or at least properly -indicate to server owners that I/O is falling behind - -Per World Spawn Limits - -This patch is licensed under the MIT license. See /licenses/MIT.md. - -Make CallbackExecutor strict again - -The correct fix for double scheduling is to avoid it. The reason -this class is used is because double scheduling causes issues -elsewhere, and it acts as an explicit detector of what double -schedules. Effectively, use the callback executor as a tool of -finding issues rather than hiding these issues. - -This patch also reverts incorrect use(s) of the class by paper. - -- getChunkFutureAsynchronously - There is no risk at all of recursion. The future is executed on - the chunk provider's thread queue, the same place general plugin - load callbacks are executed on. Forcing the task execution into - the callback executor also prevents the future from catching - any exception thrown from it. - -Improve async tp to not load chunks when crossing worlds - -Fixes an issue where a getCubes call would load neighbouring chunks. -Loads less chunks than paper's implementation - -Revert getChunkAt(Async) retaining chunks for long periods of time - -Rework PlayerChunk main thread checks - -These need to fail instead of continuing, as hiding these errors -the way paper has is just going to allow unexpected reordering -of callbacks. - -For example, thanks to this patch incorrect future -completion (completion of the world gen future, -PlayerChunkMap#b(PlayerChunk, ChunkStatus)) was detected and fixed. - -Prevent unload() calls removing tickets for sync loads - -Do not allow ticket level changes while unloading playerchunks - -Sync loading the chunk at this stage would cause it to load -older data, as well as screwing our region state. - -Revert MC-4 fix - -When messing around with collisions, I ran into problems where -entity position was off by ULP and that caused clipping problems. -Now, the collision epsilon is 1.0e-7 to account for those errors. - -But this patch is going to cause problems on the order of 1.0e-4. - -I do not want to deal with clipping problems. The very fact it works -shows it's causing the clipping to occur serverside. - -Don't allow StructureLocateEvent to change worlds - -Callers and even the function itself aren't expecting -this to happen - -Do not allow the server to unload chunks at request of plugins - -In general the chunk system is not well suited for this behavior, -especially if it is called during a chunk load. The chunks pushed -to be unloaded will simply be unloaded next tick, rather than -immediately. - -Do not run close logic for inventories on chunk unload - -Still call the event and change the active container though. We -want to avoid close logic because it's possible to load the -chunk through it. This should also be OK from a leak prevention/ -state desync POV because the TE is getting unloaded anyways. - -Correctly handle recursion for chunkholder updates - -If a chunk ticket level is brought up while unloading it would -cause a recursive call which would handle the increase but then -the caller would think the chunk would be unloaded. - -Don't read neighbour chunk data off disk when converting chunks - -Lighting is purged on update anyways, so let's not add more -into the conversion process - -Do not copy visible chunks - -For servers with a lot of chunk holders, copying for each -tickDistanceManager call can take up quite a bit in -the function. I saw approximately 1/3rd of the function -on the copy. - -Replace player chunk loader system - -The old one has undebuggable problems. Rewriting seems -the most sensible option. - -This new player chunk manager will also strictly rate limit -chunk sends so that netty threads do not get overloaded, whether -it be from the anti-xray logic or the compression itself. - -Chunk loading is also rate limited in the same manner, so this -will result in a maximum responsiveness for change. - -Config: -``` -player-chunks: - autoconfig-send-distance: true - min-load-radius: 3 - max-concurrent-sends: 12.0 - max-concurrent-loads: 5.0 -``` - -autoconfig-send-distance - Whether to try to use the client's -view distance for the send view distance in the server. In the -case that no plugin has explicitly set the send distance and -the client view distance is less-than the server's send distance, -the client's view distance will be used. This will not affect -tick view distance or no-tick view distance. - -min-load-radius - The radius of chunks around a player that -are not throttled for loading. The number of chunks -affected is actually the configured value plus one as this -config controls the chunks the client will be able to render. - -max-concurrent-sends - The maximum number of chunks that -can be queued to send at any given time. Low values -are generally going to solve server-sided networking -bottlenecks like anti-xray and chunk compression. Client -side networking is unlikely to be helped (i.e this wont help -people running off McDonald's wifi). Setting this -value to negative will make the server dynamically scale it -with players. i.e -5 will use 5 * online players for the max sends. - -max-concurrent-loads - The maxmium number of chunks -that can be queued to be loaded at any given time. Lower -values help the responsitivity to player movement and -higher values help loading when the server is at a low TPS. - -Replace ticket level propagator - -Mojang's propagator is slow, and this isn't surprising -given it's built on the same utilities the vanilla light engine -is built on. The simple propagator I wrote is approximately 4x -faster when simulating player movement. For a long time timing -reports have shown this function take up significant tick, ( -approx 10% or more), and async sampling data shows the level -propagation alone takes up a significant amount. So this -should help with that. A big side effect is that mid-tick -will be more effective, since more time will be allocated -to actually processing chunk tasks vs the ticket level updates. - -Attempt to recalculate regionfile header if it is corrupt - -Instead of trying to relocate the chunk, which is seems to never -be the correct choice, so we end up duplicating or swapping chunks, -we instead drop the current regionfile header and recalculate - -hoping that at least then we don't swap chunks, and maybe recover -them all. - -Custom table implementation for blockstate state lookups - -Testing some redstone intensive machines showed to bring about a 10% -improvement. - -Detail more information in watchdog dumps - -- Dump position, world, velocity, and uuid for currently ticking entities -- Dump player name, player uuid, position, and world for packet handling - -Optimise collision checking in player move packet handling - -Move collision logic to just the hasNewCollision call instead of getCubes + hasNewCollision - -Manually inline methods in BlockPosition - -Separate lookup locking from state access in UserCache - -Prevent lookups from stalling simple state access/write calls - -Distance manager tick timings - -Recently this has been taking up more time, so add a timings to -really figure out how much. - -Name craft scheduler threads according to the plugin using them - -Provides quick access to culprits running far more threads than -they should be - -Make sure inlined getChunkAt has inlined logic for loaded chunks - -Tux did some profiling some time ago and showed that the -previous getChunkAt method which had inlined logic for loaded -chunks did get inlined, but the standard CPS.getChunkAt -method was not inlined. - -Paper recently reverted this optimisation, so it's been reintroduced -here. - -Add packet limiter config - -Example config: -packet-limiter: - kick-message: '&cSent too many packets' - limits: - all: - interval: 7.0 - max-packet-rate: 500.0 - PacketPlayInAutoRecipe: - interval: 4.0 - max-packet-rate: 5.0 - action: DROP - -all section refers to all incoming packets, the action for all is -hard coded to KICK. - -For specific limits, the section name is the class's name, -and an action can be defined: DROP or KICK - -If interval or rate are less-than 0, the limit is ignored - -Lag compensate block breaking - -Use time instead of ticks if ticks fall behind - -Fix chunks refusing to unload at low TPS - -The full chunk future is appended to the chunk save future, but -when moving to unloaded ticket level it is not being completed with -the empty chunk access, so the chunk save must wait for the full -chunk future to complete. We can simply schedule to the immediate -executor to get this effect, rather than the main mailbox. - -Use hash table for maintaing changed block set - -When a lot of block changes occur the iteration for checking can -add up a bit and cause a small performance impact. - -Consolidate flush calls for entity tracker packets - -Most server packets seem to be sent from here, so try to avoid -expensive flush calls from them. - -This change was motivated due to local testing: - -- My server spawn has 130 cows in it (for testing a prev. patch) -- Try to let 200 players join spawn - -Without this change, I could only get 20 players on before they -all started timing out due to the load put on the Netty I/O threads. - -With this change I could get all 200 on at 0ms ping. - -(one of the primary issues is that my CPU is kinda trash, and having -4 extra threads at 100% is just too much for it). - -So in general this patch should reduce Netty I/O thread load. - -Don't lookup fluid state when raytracing - -Just use the iblockdata already retrieved, removes a getType call. - -Time scoreboard search - -Plugins leaking scoreboards will make this very expensive, -let server owners debug it easily - -Send full pos packets for hard colliding entities - -Prevent collision problems due to desync (i.e boats) - -Configurable under -`send-full-pos-for-hard-colliding-entities` - -Do not run raytrace logic for AIR - -Saves approx. 5% for the raytrace call, as most (expensive) -raytracing tends to go through air and returning early is an -easy win. The remaining problems with this function -are mostly with the block getting itself. - -Make entity tracker use highest range of passengers - -This should prevent people from having to up their animal range -just so players riding horses or whatever can be seen at the -configured player range. - -Oprimise map impl for tracked players - -Reference2BooleanOpenHashMap is going to have -better lookups than HashMap. - -Stop large move vectors in player packet handling from killing the server - -Looks like we need to check three vectors, not two. fun. - -Optimise BlockSoil nearby water lookup - -Apparently the abstract block iteration was taking about -75% of the method call. - -Allow removal/addition of entities to entity ticklist during tick - -It really doesn't make any sense that we would iterate over removed -entities during tick. Sure - tick entity checks removed, but -does it check if the entity is in an entity ticking chunk? -No it doesn't. So, allowing removal while iteration -ENSURES only entities MARKED TO TICK are ticked. - -Do not allow ticket level changes when updating chunk ticking state - -This WILL cause state corruption if it happens. So, don't -allow it. - -Optimise CraftChunk#getEntities - -Why the fuck was it iterating over every single entity -in the world - -Optimise random block ticking - -Massive performance improvement for random block ticking. -The performance increase comes from the fact that the vast -majority of attempted block ticks (~95% in my testing) fail -because the randomly selected block is not tickable. - -Now only tickable blocks are targeted, however this means that -the maximum number of block ticks occurs per chunk. However, -not all chunks are going to be targeted. The percent chance -of a chunk being targeted is based on how many tickable blocks -are in the chunk. -This means that while block ticks are spread out less, the -total number of blocks ticked per world tick remains the same. -Therefore, the chance of a random tickable block being ticked -remains the same. - -Optimise non-flush packet sending - -Places like entity tracking make heavy use of packet sending, -and internally netty will use some very expensive thread wakeup -calls when scheduling. - -Thanks to various hacks in ProtocolLib as well as other -plugins, we cannot simply use a queue of packets to group -send on execute. We have to call execute for each packet. - -Tux's suggestion here is exactly what was needed - tag -the Runnable indicating it should not make a wakeup call. - -Big thanks to Tux for making this possible as I had given -up on this optimisation before he came along. - -Locally this patch drops the entity tracker tick by a full 1.5x. - -Optimise nearby player lookups - -Use a distance map to map out close players. -Note that it's important that we cache the distance map value per chunk -since the penalty of a map lookup could outweigh the benefits of -searching less players (as it basically did in the outside range patch). - -Fix Codec log spam - -Mojang did NOT add dataconverters for world gen configurations -that they CHANGED. So, the codec fails to parse old data. - -This fixes two instances: -- IntProvider is new and Mojang did not account for old data. - Thankfully, only ColumnPlace needed to be special cased. -- TreeConfiguration had changes. Thankfully, they were - only renames for one value and thankfully defaults could - be provided for two new values (WITHOUT changing behavior). - -Apply paper's reobf mappings patch - -Workaround until paperweight implements reobf mappings patch support for forks - -Optimise WorldServer#notify - -Iterating over all of the navigators in the world is pretty expensive. -Instead, only iterate over navigators in the current region that are -eligible for repathing. - -Remove streams for villager AI +This program is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 3 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program. If not, see . diff --git a/build.gradle.kts b/build.gradle.kts index 682935762008602ca214f68147766792cbedeea9..8ccb5183af4a10a92d17570833e21dfffb5b03ea 100644