This change by spigot ensures that many interactins with chunks,
e.g. getting a list of TEs will cause the chunk to be marked for not
unloading and will block their unload. This is especially true for
servers using Timings (it needs to access the TE list of chunks), or
any plugins which need to access entity/TE lists periodically.
In some enviroments, the channel limit set by spigot can cause issues,
e.g. servers which allow and support the usage of mod packs.
provide an optional flag to disable this check, at your own risk.
add a system property to allow people to tweak how long the server
will wait for a reply. There is a compromise here between lower and higher
values, lower values will mean that dead connections can be closed sooner,
whereas higher values will make this less sensitive to issues such as spikes
from networking or during connections flood of chunk packets on slower clients,
at the cost of dead connections being kept open for longer.
Spigot, by default, disables several mechanisms around how chunks are
lit, if ever, which has forced them to always send chunks before vanilla
would consider them ready to send, causing for lots of issues around
lighting glitches.
Shamefully, the amount of work to relight chunks can be detremental
to some servers, meaning that forcibily disabling light updates can
cause major performance issues.
as such, we make a compromise; if this "feature" is disabled, we will
only send chunks which are actually ready to be sent, otherwise, we
will always send chunks.
In 1.12, Spigot improved their blockstate implementation to take a full
copy of the TE, this allows for a much better snapshot in that it will
actually retain all of the TE's state, it is a much more expensive
implementation. This is also implicated with their backwards compat
for inventories meaning that accessing of a snapshots inventory of a
placed block will actually access the inventory of the live TE, making
creation of a snapshot redundant if the only intent is to interact with
the TEs inventory.
Hoppers are a horrible hit, every attempt to transfer an ItemStack will
result in two TileEntity snapshots, with two hoppers and a double chest
ontop, I managed to log 380 cases per second where a snapshot would have been
taken in cases where the snapshot is redundant.
In some environments, the 2.20.1 version of the maven surefire plugin
can cause builds to fail due to changes in surefire in how it detects
that the forked JVM used for testing is still alive or not.
Entity AI tasks are initialized earlier in recent versions
of MC, this means that the fromMobSpawner has not been set
at the point where AI tasks are initilazed and so the goalFloat
will never be populated.
To rectify this, we can rely on the entity tick checking if
the mob is from a spawner each tick, and just initialize the
field should the paper option be enabled. This saves us from
having to modify the call chain in order to pass the fact that
it was created by a mobSpawner earlier.
This commit removes two patches from spigot:
please review the patch messages for more information, however;
"Allow Disabling of Random Lighting Updates" potentially leaves chunk light maps in an invalid state, with
how often the server looks at these anyways, this patch really serves a questionable nature, the work is
going to be done, only it's being delayed and allowing the light map to be left in a potentially outdated
state.
"Fix some chunks not being sent to the client" sends chunks before their lighting has been calculated, this
means that the client will recieve chunks before they lighting has been calculated which can cause rendering
artifacts. The original issue around this patch appears to have already been fixed years ago.
In 1.12.2, Mojang moved the processing of PacketPlayInKeepAlive off the main
thread, while entirely correct for the server, this causes issues with
plugins which are expecting the PlayerQuitEvent on the main thread.
In order to counteract some bad behavior, we will post handling of the
disconnection to the main thread, but leave the actual processing of the packet
on the main thread.
http://openjdk.java.net/jeps/223
Java decided to change their versioning scheme and in doing so modified the
java.version system property to return $major[.$minor][.$secuity][-ea], as
opposed to 1.$major.0_$identifier we can handle pre-9 by checking if the "major"
is equal to "1", otherwise, 9+
of course, it really wouldn't be all that simple if they didn't add a quirk, now would it.
valid strings for the major may potentially include values such as -ea to deannotate a pre release
Refactored 0229-Fix-this-stupid-bullshit in order to prevent merge conflicts
when spigot decides to update the timer and to provide some form of hint in the
console/log on startup.
the first 'major' change in this PR is to cache the generated event
executrs from the ASM class, by doing this we only generate a single
class for every method that we need an executor for, thus reducing the
number of classes that are needed, especially in cases where plugins
re/unregister events all the time.
The second change is to modify the generated classloader map, generated
classloaders are not held against the plugin itself but the classloader
that the event is declared in, the implication here is that we cannot
drop generated classloaders when a plugin disable, and so we use a guava
weak-key'd hashmap, downfall here is that classes won't be GC'd until
guava drops the generated classloader, however the first change should
deal with most of the grunt.
Spigot has patched this issue inside MapIcon, meaning that we no longer need to maintain this patch; Spigots patch also fixes#668 in that it will verify the length of the array, as well as protect against a negative type value being fetched from the array. Only real change is that Spigots patch returns a MapIcon.Type.PLAYER, instead of the RED_MARKER as originally PR'd by Aikar.
Currently, when a player dies they are not automatically ejected from the entity they are riding, which allows
for the ridden entity to affect the players location on respawn (we're still riding it for a part of a tick), as well as allows a dupe to occur with the ridden entity teleporting to the new world with the player