[ci-skip] Restore Tuinity patch headers

This commit is contained in:
William Blake Galbreath
2021-07-16 14:37:37 -05:00
parent c64af8769b
commit 92f0df5d08
2 changed files with 22 additions and 511 deletions

View File

@@ -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.
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 <https://www.gnu.org/licenses/>.
diff --git a/src/main/java/org/bukkit/Server.java b/src/main/java/org/bukkit/Server.java
index f05edac8cdd33daaf1d15a526be4d2ac2b08846d..8776b8368d2046dee02e927de8249030bdddf2ee 100644

View File

@@ -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
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 <https://www.gnu.org/licenses/>.
diff --git a/build.gradle.kts b/build.gradle.kts
index 682935762008602ca214f68147766792cbedeea9..8ccb5183af4a10a92d17570833e21dfffb5b03ea 100644