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.
Prior to this change, if a player was ever set to have a negative view
distance, an attempt to set them back to the default would fail, leading
to them appearing to be stuck in that state.
Now we just interpret that negative value as a "reset" to default.
Thankfully I randomly think about code and randomly wondered if I used <= or < here, and caught this!
This would of missed some chunks for the structure at the highest X/Z
Improves performance by keying every chunk thats part of a structure to a hashmap
instead of only the first one.
This allows us to avoid iterating the entire structures value set to see
if a block position is inside of a structure.
This should have pretty decent performance improvement to any standard world
that has been around for a whilewith lots of structures due to ineffeciencies
in how MC stores structures (even unloaded chunks has structured data loaded)
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.
HashSet sometimes uses compareTo() instead of equals() and this breaks the comparison of net.minecraft.server.NextTickListEntry (the only place where HashTreeSet is used).
In this cases duplicate entries could be added to the HashSet of HashTreeSet, because NextTickListEntry.compareTo() does not return 0, even if NextTickListEntry.equals() returns true.
ObjectOpenHashSet never uses compareTo(), so the inconsistencies of NextTickListEntry cause no problems.
Fixes https://github.com/PaperMC/Paper/issues/588
Port of 303a775fc3
Will display a list of all entities in a world, as well as which chunks
they are in. Hopefully, this will make tracking down chunks with lots of
entities easier.
Only real change from the forge version is that instead of dimension
IDs, we accept world names in the form of a string.
/paper entity list - Lists all entities in the player's current world
/paper entity list minecraft:zombie - Lists all zombies in the player's
current world
/paper entity list * world_nether - Lists all entities in the nether
/paper entity list minecraft:ghast world_nether - Lists all ghasts in
the nether
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
Some plugins bypass the plugin logger and add the plugin prefix
manually to the log message. Since they use other logger names
(e.g. qualified class names) these would now also appear in the
log. Disable the logger prefix for these plugins so the messages
show up correctly.
SLF4J is a commonly used abstraction for various logging frameworks
such as java.util.logging (JUL) or Log4j. Currently, plugins are
required to do all their logging using the provided JUL logger.
This is annoying for plugins that target multiple platforms or when
using libraries that log messages using SLF4J.
Expose SLF4J as optional logging API for plugins, so they can use
it without having to shade it in the plugin and going through
several layers of logging abstraction.
Log4j2 provides an optimized implementation of PrintStream that
redirects its output to a logger. Use it instead of a custom
implementation for minor performance improvements and some fixes.
With the old implementation, each call to System.print()
results in a separate line, even though it should not result in
a line break. Log4j's implementation handles it correctly.
