Use a proper teleport for teleporting to entities in different
worlds.
Implementation improvements authored by Spottedleaf <Spottedleaf@users.noreply.github.com>
Validate that the target entity is valid and deny spectate
requests from frozen players.
Also, make sure the entity is spawned to the client before
sending the camera packet. If the entity isn't spawned clientside
when it receives the camera packet, then the client will not
spectate the target entity.
Co-authored-by: Spottedleaf <Spottedleaf@users.noreply.github.com>
This adds the ability to cancel the death events and to modify the sound
an entity makes when dying. (In cases were no sound should it will be
called with shouldPlaySound set to false allowing unsilencing of silent
entities)
It makes handling of entity deaths a lot nicer as you no longer need
to listen on the damage event and calculate if the entity dies yourself
to cancel the death which has the benefit of also receiving the dropped
items and experience which is otherwise only properly possible by using
internal code.
== AT ==
public net.minecraft.world.entity.LivingEntity getDeathSound()Lnet/minecraft/sounds/SoundEvent;
public net.minecraft.world.entity.LivingEntity getSoundVolume()F
This is specifically aimed at fixing #471
Using a ConcurrentHashMap because thread safety
The performance benefit of Map over ConcurrentMap is negligabe at best in this scenaio, as most operations will be get and not add or remove
Even without considering the use-case the benefits are still negligable
Original ideas for the system included an expiration policy and/or handler
The simpler solution was to use a computeIfPresent in the get method
This will simultaneously have an O(1) lookup time and automatically expire any values
Since the get method (nor other similar methods) don't seem to have a critical need to flush the map to disk at any of these points further processing is simply wasteful
Meaning the original function expired values unrelated to the current value without actually having any explicit need to
The h method was heavily modified to be much more efficient in its processing
Also instead of being called on every get, it's now called just before a save
This will eliminate stale values being flushed to disk
Modified isEmpty to use the isEmpty() method instead of the slightly confusing size() < 1
The point of this is readability, but does have a side-benefit of a small microptimization
Detect when the server has been hung for a long duration, and start printing
thread dumps at an interval until the point of crash.
This will help diagnose what was going on in that time before the crash.
Due to the changes in 1.13, clients will send a tab completion request
for all bukkit commands in order to factor in the lack of support for
brigadier and provide backwards support in the API.
Craftbukkit, however; has moved the chat spam limiter to also interact
with the tab completion request, which while good for avoiding abuse,
causes 1.13 clients to easilly be kicked from a server in bukkit due
to this. Removing the spam limit could cause issues for servers, however,
there is no way for servers to manipulate this without blindly cancelling
kick events, which only causes additional complications. This also causes
issues in that the tab spam limit and chat share the same field but different
limits, meaning that a player having typed a long command may be kicked from
the server.
Splitting the field up and making it configurable allows for server owners
to take the burden of this into their own hand without having to rely on
plugins doing unsafe things.
Add Entity as a Source capability, and add more API choices, and on Location.
Co-authored-by: Esoteric Enderman <90862990+EsotericEnderman@users.noreply.github.com>
Co-authored-by: Bjarne Koll <git@lynxplay.dev>
Adds ability to control who receives it and who is the source/sender (vanish API)
the standard API is to send the packet to everyone in the world, which is ineffecient.
Adds an option to control the force mode of the particle.
This adds a new Builder API which is much friendlier to use.
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
GUIs are opened on the client, meaning that the server cannot block them from opening,
However, it is possible to close these GUIs from the server.
Flower pots are also not updated on the client when interaction is cancelled, this patch
also resolves this.
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
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
Co-authored-by: Aikar <aikar@aikar.co>
This patch intends to bump up the time that a client has to reply to the
server back to 30 seconds as per pre 1.12.2, which allowed clients
more than enough time to reply potentially allowing them to be less
tempermental due to lag spikes on the network thread, e.g. that caused
by plugins that are interacting with netty.
We also 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.
In 1.12.2, Mojang moved the processing of ServerboundKeepAlivePacket 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
off the main thread.
also adding some additional logging in order to help work out what is causing
random disconnections for clients.
Disable the 15 second sleep when the server jar hasn't been rebuilt within a period of time.
modified in order to prevent merge conflicts when Spigot changes/disables the warning,
and to provide some level of hint without being disruptive.
Establishes base extension of profile systems for future edits too
== AT ==
public org.bukkit.craftbukkit.profile.CraftProfileProperty
public org.bukkit.craftbukkit.profile.CraftPlayerTextures
public org.bukkit.craftbukkit.profile.CraftPlayerTextures copyFrom(Lorg/bukkit/profile/PlayerTextures;)V
public org.bukkit.craftbukkit.profile.CraftPlayerTextures rebuildPropertyIfDirty()V
public org.bukkit.craftbukkit.profile.CraftPlayerProfile toString(Lcom/mojang/authlib/properties/PropertyMap;)Ljava/lang/String;
public org.bukkit.craftbukkit.profile.CraftPlayerProfile getProperty(Ljava/lang/String;)Lcom/mojang/authlib/properties/Property;
public org.bukkit.craftbukkit.profile.CraftPlayerProfile setProperty(Ljava/lang/String;Lcom/mojang/authlib/properties/Property;)V
They block. On network I/O.
If enough tasks are submitted the server will eventually stall
out due to a sync load, as the worldgen threads will be
stalling on profile lookups.
Makes parrots not fall off whenever the player changes height, or touches water, or gets hit by a passing leaf.
Instead, switches the behavior so that players have to sneak to make the birds leave.
I suspect Mojang may switch to this behavior before full release.
To be converted into a Paper-API event at some point in the future?
== AT ==
public net.minecraft.world.entity.player.Player removeEntitiesOnShoulder()V
The watchdog thread calls the server restart function asynchronously. Prior to
this change, it attempted to do several non-safe operations from the watchdog
thread, rather than the main. Specifically, because of a separate upstream change,
it causes player entities to be ticked asynchronously, among other things.
This is dangerous.
This patch moves the old handling into a synchronous variant, for calls from the
restart command, and adds separate handling for async calls, such as those from
the watchdog thread.
When calling from the watchdog thread, we cannot assume the main thread is in a
tickable state; it may be completely deadlocked. In order to handle this, we mark
the server as stopping, in order to account for situations where the server should
complete a tick reasonbly soon, i.e. 99% of cases.
Should the server not enter a state where it is stopping within 10 seconds, We
will assume that the server has in fact deadlocked and will proceed to force
kill the server.
This modification does not force restart the server should we actually enter a
deadlocked state where the server is stopping, whereas this will in most cases
exit within a reasonable amount of time, to put a fixed limit on a process that
will have plugins and worlds saving to the disk has a high potential to result
in corruption/dataloss.
* Only send global sounds to same world if limiting radius
* respect global sound events gamerule
Co-authored-by: Evan McCarthy <evanmccarthy@outlook.com>
Co-authored-by: lexikiq <noellekiq@gmail.com>
Co-authored-by: Aikar <aikar@aikar.co>
For servers with multiple IP's, ability to bind to a specific interface.
== AT ==
public net.minecraft.server.dedicated.Settings getStringRaw(Ljava/lang/String;)Ljava/lang/String;