[ci-skip] Restore Tuinity patch headers

2026-02-19 09:27:43 +01:00 · 2021-07-16 14:37:37 -05:00
parent c64af8769b
commit 92f0df5d08
2 changed files with 22 additions and 511 deletions
--- a/patches/api/0001-Tuinity-API-Changes.patch
+++ b/patches/api/0001-Tuinity-API-Changes.patch
@@ -3,13 +3,18 @@ From: Spottedleaf <spottedleaf@spottedleaf.dev>
 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.
+You should have received a copy of the GNU General Public License
-
+along with this program.  If not, see <https://www.gnu.org/licenses/>.
 Also add send view distance to World.
 diff --git a/src/main/java/org/bukkit/Server.java b/src/main/java/org/bukkit/Server.java
 index f05edac8cdd33daaf1d15a526be4d2ac2b08846d..8776b8368d2046dee02e927de8249030bdddf2ee 100644
--- a/patches/server/0001-Tuinity-Server-Changes.patch
+++ b/patches/server/0001-Tuinity-Server-Changes.patch
@@ -3,512 +3,18 @@ From: Spottedleaf <Spottedleaf@users.noreply.github.com>
 Date: Sat, 12 Jun 2021 16:40:34 +0200
 Subject: [PATCH] Tuinity Server Changes
-Update version fetcher repo
+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
-Sets the target github repo to Tuinity in the version checker. Also disables the jenkins build lookups.
+the Free Software Foundation, either version 3 of the License, or
-
+(at your option) any later version.
-This patch is licensed under the MIT license. See /licenses/MIT.md.
+
-
+This program is distributed in the hope that it will be useful,
-MC-Dev fixes
+but WITHOUT ANY WARRANTY; without even the implied warranty of
-
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-Util patch
+GNU General Public License for more details.
-
+
-Tuinity Server Config
+You should have received a copy of the GNU General Public License
-
+along with this program.  If not, see <https://www.gnu.org/licenses/>.
 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
 diff --git a/build.gradle.kts b/build.gradle.kts
 index 682935762008602ca214f68147766792cbedeea9..8ccb5183af4a10a92d17570833e21dfffb5b03ea 100644