mirror of
https://github.com/PurpurMC/Purpur.git
synced 2026-02-17 08:27:43 +01:00
[ci-skip] Restore Tuinity patch headers
This commit is contained in:
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user