When an itemstack runs out of durability, the amount is reduced to
0 which then marks the item as invalid. This causes the last unit
of durability to not apply enchantments as the enchantment level
check sees the item as a dud.
keep the clone of the item used to a non empty value so it represents
the item used.
Fixes some bugs with urgent priority, improves priority all
around to optimize blocking chunk requests as much as possible.
fixes casing on the -Dpaper.maxchunkthreads to now be -Dpaper.maxChunkThreads
adds -Dpaper.genThreadPriority=3 -Dpaper.loadThreadPriority=4
lowering thread priorities will help ensure main has more
priority over chunk threads
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
CraftBukkit Changes:
aed3aecb Make natural item dropping mimic Vanilla
Upstream has released updates that appears 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:
98d3f031 SPIGOT-4376: Add draft BlockDropItemEvent
CraftBukkit Changes:
1057710a SPIGOT-4376: Add draft BlockDropItemEvent
Removes the paperclip Java 9+ warning and replaces it with general
JVM and Host OS information that will be more useful in finding issues
for end users and ourselves.
Also removes the "for development only" 1.13 warning that everyone has
been ignoring completely anyway.
A chunk load on the main thread will be added to the high priority queue, however, due to existing work on this queue, there was no guarantee that the load would occur within a reasonable amount of time, potentially causing a server to crash while waiting for a chunk in the queue
In order to counteract this, a new urgent priority has been added, allowing us to prioritize these tasks over standard chunk gen/loading
(#1625#1615#1575#1558 (and probably more))
Changes upstream moved this to a profile a while back, however,
when updating (for some unknown reason) I kept it enabled by default,
however, leaving this enabled breaks building the server in newer
versions of java, which while this wasn't a concern before, is now
an issue for users.
Spigot capped it to 2 threads. This bumps it back up to do
maxcores -2 with a max cap of 6.
A typical 4C8T system can use 6 threads and be done in 6 seconds.
Server owners can use system property to override, but this
improves the default.
this should provide a pretty good across-the-board performance
improvement for the entire server, as it's very common for code
to check if (isLoaded(x, z)) { then do something on that chunk }
Previously, containsKey would not read or set the last access cache
By making it do get() != null, we gain the benefits of last access
and also improves thread safey for async isLoaded checks
This exact usage scenario is used in Entity movement, so that alone
saves us up to 5%~ of CPU time for Entity movement.
it used public method instead of private, and moved to world config
also improved the implementation to not use obfuscated stuff
Also removed the Fix Double chest conversion patch since its
fixed in other ways in vanilla
It is not immediately clear how these characters ended up on signs in
previous versions. It is clear, however, that they now render as empty
unicode boxes in 1.13, whereas previously they rendered as invisible
characters.
When these signs are loaded in versions after this commit, these
characters from the private use area of the Unicode block will be
stripped. The sign will then be marked to ensure this conversion only
runs once.
There is a flag -DPaper.keepInvalidUnicode=true that can be used if you
do not want us to strip these characters from your signs, though I can
think of no reason to use it.
Fixes GH-1571
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
CraftBukkit Changes:
a639ae44 Remove outdated build delay.
The item tag is stored before executing the interaction and restored before handling the
resulting events. If the event was not canceled and the ItemStack is not modified in the
event, the new tag is set back to the new one afterwards. This is similar to the handling
of the item amount.
This fixes a bug where tools lose durability when the interaction is canceled and another bug
where tools become completely repaired when they should break but the interaction was canceled.
This will provide quite a major performance boost by avoiding
synchronizing on EVERY chunk lookup.
Synchronize, even without contention, incurs processor cache flushes.
Considering this is the 2nd hottest method in the code base, lets
avoid doing that...
Additionally, chunk conversion operations were occuring while
under synchronization which lead to deadlocks.
Now the conversion will occur outside of the lock, and fix
that issue, resolving #1586
Note, that the chunk map is still thread safe for get operations!
The chunk map was never intended to be modified async with our
changes, as we post to main to modify the map, however
we do still synchronize for write operations (put, remove)
We also synchronize for async get operations, ensuring that
async gets are safe.
We do not need to synchronize main thread gets as the processor
cache will be insync since the map is only updated on the main thread.
However, if someone does try to delete or put concurrently, we
will force their operation back to the main thread.
While Velocity supports BungeeCord-style IP forwarding, it is not secure. Users
have a lot of problems setting up firewalls or setting up plugins like IPWhitelist.
Further, the BungeeCord IP forwarding protocol still retains essentially its original
form, when there is brand new support for custom login plugin messages in 1.13.
Velocity's modern IP forwarding uses an HMAC-SHA256 code to ensure authenticity
of messages, is packed into a binary format that is smaller than BungeeCord's
forwarding, and is integrated into the Minecraft login process by using the 1.13
login plugin message packet.
Mojang was not checking that the chunk did not overwrite, or
was successfully removed.
We're seeing odd reports in #1561 that indicates issues around
this are having problems.
Say a player shoots an arrow through a nether portal, the game
would lose the shooter for determining things such as Player Kills,
because the entity is in another world.
If the projectile fails to find the shooter in the current world, check
other worlds.
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
CraftBukkit Changes:
e7ced970 Catch plugins setting null Material or BlockData to blocks
fixes an issue in which thread requests are only processed
for the current provider which can cause a deadlock should
multiple requests exist across providers
