The result object of overhanging items is based upon a derived view
of the provided crafting slots, meaning that we need to consider this
when handing back the resultant slots.
As noted on the issue, the method here can blow up in
certain cases, the GUI logic already handles "the mouse is missing",
and so, we'll just catch this and move on.
Misc fix - There is probably an issue report for this somewhere,
but, the details section utilised the bukkit singleton to try to get
the TPS from the server. We already have the MinecraftServer instance
passed into us, and so we'll just get the information directly from there instead.
Fixes: #11494
The mojang client will not remove patterns from a Banner when none
are sent inside of an update packet, given that this is not an expected
flow for them, this is not all too surprising. So, we shall resort to always
sending the patterns over the network for update packets.
Fixes: #11487
* Only mark decorations dirty if a removal actually occurs
Vanilla calls this method blindly inside of a loop which erroniously marks
map data files as being dirty even if nothing has actually changed.
* Merge into existing patch
---------
Co-authored-by: Bjarne Koll <git@lynxplay.dev>
primarily, this allows us to ensure that appenders are flushed, console, log files
before the JVM exits to avoid issues such as error messages disappearing
Long ago we discovered that the default thread pools would not increase
the number of threads running the pool until queue addition failed.
Bumping the core size mitigates an issue with spark-paper, and in general,
keeping async threads around generally beats having to spin new ones
everytime we want to execute a periodic async task.
There is no need to rewrap vanilla goals when they're being reregistered,
this breaks some expectations around behavior outside of general
wasting of resources.
Resolves: #10743
paper previously migrated away from using executeIfPossible as this throws a
RejectedExecutionException when the server is shutting down, which is then picked
up by the Connection handler object and causes the player to be kicked without
the intended disconnection message that comes from commands such as /stop, /restart
This was fine, because previously changes made in spigot would just prevent these
packets from being executed anyways. Instead, we'll just use a marker exception
to try to detect this specific state.
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
58ce1b0f Improve compatibility of new DamageSource API
I cannot test this due to lack of hardware (took 30 minutes getting paper
updated and loaded into IJ on this machine...), however, this is the easiest
patch for now. Ideally, some form of distance check would probably be added to
improve invalidation of this cache.
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
465c4964 PR-843: Add damage methods to FallingBlock
46ba7c9f SPIGOT-7335: Fix typo in TextDisplay#TextAlignment enum name
CraftBukkit Changes:
818582f40 PR-1169: Add damage methods to FallingBlock
15a3eac66 SPIGOT-7335: Fix typo in TextDisplay#TextAlignment enum name
f01fb4979 SPIGOT-7336: Fix typo in internal method name
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
de5ba402 PR-848: Mark get/setCatType methods deprecated in addition to the enum
CraftBukkit Changes:
50ee87fbc SPIGOT-7333: Correctly handle null in ColorableArmorMeta#setColor()
790be710b SPIGOT-7332: Persistent Data Container of Chunk not saving on stop or restart.
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
aeb62aa3 Remove obsolete documentation from ArmorMeta#setTrim
CraftBukkit Changes:
cb6f3c028 PR-1173: Change CraftMinecartTNT to public for consistency
This patch will prevent sending expired keys to players when logging into a server, while the client does have some grace period to prevent issues, if a key has expired beyond the grace period, connecting clients will be disconnected from the server upon join. The client should update keys before this key even expires, and a new key will be broadcasted out if we somehow actually get one.
The paper config has taken precidence over this for a long time
with 0 complaints, and now it's tripping the deprecation warning,
even if timings is disabled in the paper config.
Upstream improperly used the enum name for looking up the vanilla entity
type to get the translation key; temp patch this until upstream fixes this,
also add some quick validation
adding the getHandle method causes some issues with things like ProtocolLib
due to the expectation that all classes which provide a getHandle method
are public.
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
c7c11188 SPIGOT-2620: Add Player#sendBlockChanges()
f63d2b44 Improve annotation test on parameters
3372e7b4 SPIGOT-1244, SPIGOT-6860, SPIGOT-6874: Various Javadoc and formatting fixes
a1e8a9ab PR-793: Ignore .checkstyle file generated by Eclipse IDE
CraftBukkit Changes:
c2c39089e SPIGOT-2620: Add Player#sendBlockChanges()
8209158db PR-1113: Ignore .checkstyle file generated by Eclipse IDE
Spigot Changes:
4aa5ead2 Rebuild patches
* Make WorldCreator#keepSpawnLoaded return the WorldCreator (Fixes#8321)
Thought that I fixed this before push/merge, apparently not, hence, fix
the return type and add mitigation for this.
* Fix patch/build
* Rebuild patches
Vanilla uses a Random instance which is not thread safe inside of the
constructor for ServerLoginPacketListenerImpl, this is an issue because
instances of that class are created on the network worker threads, which
means that there is a potential (which we have reports confirming) that
multiple users logging on could trip this
in 1.19, mojang made it so that teleporations validate that an awaiting pos was
set in the server when teleporting, thus we need to ensure that this is set when
sending the player pos, otherwise the player will be kicked when the client sends
back the aknowledgement
I do wanna add some leeway to the kick, if message was sent within 30-60
seconds of the last message, assume clock drift and just ignore the kick
(send a message? just silently ignore?), but, I'm not 100% on this one
Shane Freeder