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:
812f66aa SPIGOT-4684: Update persistence of converting zombie villagers
upstream was doing a containsKey/get pattern, and always doing it at that.
that scenario is only even valid if were in the middle of a block place.
Optimize to check if the captured list even has values in it, and also to
just do a get call since the value can never be null.
We bandaided this logic on a case by case basis before with Loot Tables and Chests,
but that is not the correct fix.
Ultimately we just needed to clear out the captured tile entity list so that the
update calls did not process the tile entity that is no longer even valid.
This solution will ensure ALL placed tile entities data is ignored and not just
the few cases we previously had filters for.
The cost of a call to sync() adds up quickly and especially for
HDDs. Playing around generating chunks for a while warranted a
3 min save time on a HDD. This is unacceptable default behaviour
and now the behaviour is hidden behind a flag for server owners
who are OK with taking a hit on saves (although SSDs will not have
this issue remotely as bad, since most of the time was spent seeking).
It is possible for a container to be brought into the world pre-filled
in place event (thanks NBT!). When the blockplacevent(s) are cancelled
their blockstate is updated in OBC. This triggers them to drop their
inventories.
Rather than screwing with the update method which is used elsewhere, we
can simply clear any inventories once we are told that a plugin intends
to cancel the interaction.
Fixes GH-1831
While it wasn't really "broken" before, if plugins use NMS
(which they really should't be) and mess with entity management
themselves, and get it wrong, they could ultimately corrupt our
state expectations.
I've been unable to reproduce any issues locally, but these changes
are the result of me analyzing the code pretty deeply and seeing
about how to make it more durable to abnormal usage.
Any servers seeing oddities, please run with -Ddebug.entities=true
and send me any logs triggered.
Why are plugins accessing this?! Whhhhy?!
For any plugin developers reading this, this are methods in World
specifically for adding entities to the world, aptly called spawnEntity
Previously we would write to header before writing our chunk data,
which opens a window for corruption (or we would overwrite entirely).
Now the saving process has been changed to follow this chain of events:
1. We always allocate a new space to write so we do not potentially
overwrite and corrupt the current data
2. Write the chunk data first (the order of the fields in
the chunk data isn't relevant though)
3. Flush to disk
4. Write to the region header last
5. Flush to disk
6. Then we free the previous space allocated
With this chain of events it is impossible for a chunk write to corrupt
a region file, unless the operating system has lied and we have NOT flushed
to disk.
However server administrators are still recommended to continue performing
regular backups.
Note that when Mojang finally decides to change their region format
to deal with oversized chunks this patch must be changed to deal with
whatever system they decide to impose.
We also make use of two flushes to disk per chunk save (to ensure
ordering and ensure data has gone to disk), so this will negatively
affect save performance.
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:
7634491f Added Entity#setRotation.
CraftBukkit Changes:
0e1cea5a Added Entity#setRotation.
Plugins that rely on the async login event to fire can miss the event
if a player tries to log in before the server has loaded.
The solution is to simply block the event threads from executing until
the server has loaded. This will not have an adverse affect on logins
since the event threads are cached and are only used for executing events
asynchronously.
We pretty much reverted most of Spigots changes here as ours is better.
I guess least Spigot is trying to get closer to us? but missed..
CraftBukkit Changes:
0bf75bbd SPIGOT-4686: Enchantment ordering nondeterministic
Spigot Changes:
f09662d0 Rebuild patches
this will help ensure that upstreams apply as cleanly as it does manually
the filtering makes the patches more fragile, but usually not an issue for small updates.
this will unfilter, apply the cleanest patches, then the next rebuild will
filter out unnecessary changes
This is caused due to the DimensionManager in CB worlds not being
registered by NMS, we fix this by copying CBs behavior of using the
world providers DimensionManager, vs using the actual dimension manager
of the world
Now decounts entities that got name tagged or persistent state changed.
Removes a bad CB check that ignored some persistent mobs persistence state.
Vanilla code explicitly only cares 'is this mob persistent?' and if
it is, it is not counted. CB should not of been checking its type state.
Fixes#1922
removes Mineshaft loading legacy as we had pre 1.13.2 to avoid managing
that very large data file from legacy systems.
Previous to 1.13.2 these data files were never loaded to begin with, so they
effectively do not contain valid/relevant data.
These files take a long time to convert on large worlds and crashes the server.
Additionally, cache the result of a file being missing so we don't keep spam checking it.
This code could get hit by many threads at once, causing multiple
chunk loads to convert legacy data, leading to all sorts of fun.
Additionally, go ahead and preload it async on world load.
Instead of allocating a buffer for every chunk compression, reuse
the same 64k sized buffer.
Also stopped doing dynamic compression levels. It wasn't helping enough.
This will improve memory usage and zlib performance of chunk compression.
Exposes a mutable array on items a player should keep on death.
This allows a cleaner method to implement "Keep certain items on death"
than how plugins currently do it in that it never removes them in first
place, so its safe if the player logs out/server is shutdown before respawn.
Example Usage: https://gist.github.com/aikar/5bb202de6057a051a950ce1f29feb0b4
getting lots of bug reports on light. just going to drop this even though
I really don't see how it could be the source due to my understanding of
the games light engine...
Fixes#1920
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:
4c8327f7 SPIGOT-4673: EntitySpawnEvent should not be called for players
Spigot Changes:
5629554b Rebuild patches
Use O(1) patterns for mapping conversions to improve plugin performance.
Optimize collections used by legacy plugin conversion
This should improve plugin performance across the board
on Paper for both Modern and Legacy Plugins.
Also log how long building those tables takes...
PlayerList#moveToWorld already untracks the player from the player list,
meaning that we do not need to worry about this untracking players
who've left the world, The server also untracks a player during
disconnect, handing yet another case.
If we don't need to untrack players who've left the world, it should be
reasonably save to do this, as we're not going to be performing any
server->client updates here, which is what this code is intended to do,
and all players should be untracked.
Some of these were wrong (scoreboard manager), others are counter to
everything everyone expects (Locations world being null, which wasnt ever safe EVER)
others are just too noisy.
Replace some with Contract to get rid of the nullability constraint and go back to
the old days of IDE not considering it strictly one way or the other.
Also, stop requiring annotations on package-private.
Introduces the next Developer Perk for Paper-API: Your plugin isn't yellow anymore.
Also fixed random dupe code in ensureServerConversions that got mistakenly set in the update.
use a better stack for managing timing tree relationships
remove unnecessary synchronization (i forgot HANDLERS is only touched on main)
this should hopefully resolve any data integrity concerns
