* Make the legacy ping handler more reliable
The Minecraft server often fails to respond to old ("legacy") pings
from old Minecraft versions using the protocol used before the switch
to Netty in Minecraft 1.7.
Due to packet fragmentation[1], we might not have all needed bytes
available when the LegacyPingHandler is called. In this case, it will
run into an error, remove the handler and continue using the modern
protocol.
This is unlikely to happen for the first two revisions of the legacy
ping protocol (used in Minecraft 1.5.x and older) since the request
consists of only one or two bytes, but happens frequently for the
last/third revision introduced in Minecraft 1.6.
It has much larger, variable packet sizes due to the inclusion of
the virtual host (the hostname/port used to connect to the server).
The solution[2] is simple: If we find more than two matching bytes,
we buffer the remaining bytes until we have enough to fully read and
respond to the request.
[1]: https://netty.io/wiki/user-guide-for-4.x.html#wiki-h3-11
[2]: https://netty.io/wiki/user-guide-for-4.x.html#wiki-h4-13
* Add legacy ping support to PaperServerListPingEvent
Add a new method to StatusClient check if the client is a legacy
client that does not support all of the features provided in the
event.
Don't want to risk mutating players properties in server list (unlikely, but lets be proper)
and Skull also has a setter API, so that should be used too.
* Drop original implementation for old player sample API
* Add extended PaperServerListPingEvent
Add a new event that extends the original ServerListPingEvent
and allows full control of the response sent to the client.
* Implement deprecated player sample API
I mistakenly thought .complete() also checked for textures, which was not the case
So the logic was not working as desired.
Also some undesired logic paths lead to textures of the logging in player being dropped, forcing
us to always load the textures immediately again on login, leading to rate limits.
Everythings now good
the .complete() api now will default specify to also complete textures, but you may
pass false to it to skip loading textures.
Gets the unique ID of the player currently known as the specified player name
In Offline Mode, will return an Offline UUID
This is a more performant way to obtain a UUID for a name than loading an OfflinePlayer
This ensures we look up the name for ID only Profiles
If the profile is in the UserCache, we can get those details quickly
This should avoid some unnecessary round trips.
Additionally, handle profiles for offline mode to use offline UUID's
Bukkit restricts command execution of signs to test if the sender
has permission to run the specified command. This breaks vanilla
maps that use signs to intentionally run as elevated permission.
Bukkit provides an unrestricted advancements setting, so this setting
compliments that one and allows for unrestricted signs.
We still filter sign update packets to strip out commands at edit phase,
however there is no sanity in ever expecting creative mode to not be
able to create signs with any command.
Creative servers should absolutely never enable this.
Non creative servers, enable at own risk!!!
The Craft Scheduler still uses the primary thread for task scheduling.
This results in the main thread still having to do work as part of the
dispatching of async tasks.
If plugins make use of lots of async tasks, such as particle emitters
that want to keep the logic off the main thread, the main thread still
receives quite a bit of load from processing all of these queued tasks.
Additionally, resizing and managing the pending entries for all of
these asynchronous tasks takes up time on the main thread too.
This commit replaces the implementation of the scheduler when working
with asynchronous tasks, by forwarding calls to the new scheduler.
The Async Scheduler uses a single thread executor for "management" tasks.
The Management Thread is responsible for all adding and dispatching of
scheduled tasks.
The mainThreadHeartbeat will send a heartbeat task to the management thread
with the currentTick value, so that it can find which tasks to execute.
Scheduling of an async tasks also dispatches a management task, ensuring
that any Queue resizing operation occurs off of the main thread.
The async queue uses a complete separate PriorityQueue, ensuring that resize
operations are decoupled from the sync tasks queue.
Additionally, an optimization was made that if a plugin schedules
a single, non repeating, no delay task, that we immediately dispatch it
to the executor pool instead of scheduling it. This avoids an unnecessary
round trip through the queue, as well as will reduce the size growth of the
queue if a plugin schedules lots of asynchronous tasks.
This seems completely pointless, as packet dispatch uses .writeAndFlush.
Things seem to work fine without implicit flushing, but incase issues arise,
provide a System property to re-enable it using improved logic of doing the
flushing on the netty event loop, so it won't do the flush on the main thread.
Renable flushing by passing -Dpaper.implicit-flush=true
This will force the saves to spread over multiple ticks even when many
players auto save interval is aligned, avoiding spikes on large servers.
Closes#1021
Plugins were abusing this to dispatch commands async anyways.
We will no longer check that flag, and force all commands to be ran sync.
Use a different boolean for allowing things go to through on shutdown/restart instead.
Resolves#1004Resolves#1005
- Lots of itemstack cloning removed. Only clone if the item is actually moved
- Return true when a plugin cancels inventory move item event instead of false, as false causes pulls to cycle through all items.
However, pushes do not exhibit the same behavior, so this is not something plugins could of been relying on.
- Add option (Default on) to cooldown hoppers when they fail to move an item due to full inventory
- Skip subsequent InventoryMoveItemEvents if a plugin does not use the item after first event fire for an iteration
This is adds basic item meta for armor stands. It does not add all
possible metadata however.
There are armor, hand, and equipment types, as well as position data
that can also be added here. This initial implementation should serve as
a starting point for future additions in this area.
Fixes GH-559
This is a source of MAJOR lag for hoppers, as well as a gameplay bug.
This removes the necessity to disable the cat on chest behavior to improve performance.
now performance will be improved even if you have cat chest detection on.
Allows plugins to populate profile properties from local sources to avoid calls out to Mojang API
to fill in textures for example.
If Mojang API does need to be hit, event fire so you can get the results.
This is useful for implementing a ProfileCache for Player Skulls
This simply provides the base API to create the objects. Further commits will come that adds
adds usage of this API to existing GameProfile based API's, as well as new API's.
This event can be used for when you want to exclude a certain player
from triggering monster spawns on a server.
Also a highly more effecient way to blanket block spawns in a world
Adds an event to fire before an Entity is created, so that plugins that need to cancel
CreatureSpawnEvent can do so from this event instead.
Cancelling CreatureSpawnEvent rapidly causes a lot of garbage collection and CPU waste
as it's done after the Entity object has been fully created.
Mob Limiting plugins and blanket "ban this type of monster" plugins should use this event
instead and save a lot of server resources.
See: https://github.com/PaperMC/Paper/issues/917
Limit the number of generations that can occur in a single tick, forcing them
to be spread out more.
Defaulting to 10 as an average generation is going to be 3-6ms, which means 10 will
likely cause the server to lose TPS, but constrain how much.
This should result in no noticeable speed reduction in generation for servers not
lagging, and let larger servers reduce this value according to their own desires.
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.
Instead of overriding add within the queue, never add runnables to the
queue if the light queue is disabled.
This change is made to make timings reports and stacktraces less
confusing for administrators, who prior to this change, would have seen
the lighting queue referenced in both, regardless of whether or not it
was enabled.
This change should not affect performance, nor is it made with the
intent to.
This allows plugins that give players the ability to apply the experience
points to the Item Mending formula, which will repair an item instead
of giving the player experience points.
Both an API To standalone mend, and apply mending logic to .giveExp has been added.
Fired when the server is about to merge 2 experience orbs
Plugins can cancel this if they want to ensure experience orbs do not lose important
metadata such as spawn reason, or conditionally move data from source to target.
This ensures that enchants are never added in inconsistent order.
The client shows the enchants in a sorted order already
This will auto fix previously created items too on load.
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.
Let plugins be able to control tab completion of commands and chat async.
This will be useful for frameworks like ACF so we can define async safe completion handlers,
and avoid going to main for tab completions.
Especially useful if you need to query a database in order to obtain the results for tab
completion, such as offline players.
Also adds isCommand and getLocation to the sync TabCompleteEvent
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.
