- Re-removes Bukkit#getServerName - This was (hopefully?) only added back
for Timings v2. It should be kept in that scope.
- Intend to let PlayerViewDistance API slip. Given the scope of the
changes in this area it seems best to let this slip past initial
release. It can be re-added when there is additional time to focus on it
and the changed systems it relies on. If it is fixed prior to release
this is implemented as a single shim patch that can be dropped.
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:
da08d022 SPIGOT-4700: Add PlayerFishEvent.State.REEL_IN
0cef14e4 Remove draft API from selectEntities
CraftBukkit Changes:
a46fdbc6 Remove outdated build delay.
3697519b SPIGOT-4708: Fix ExactChoice recipes neglecting material
9ead7009 SPIGOT-4677: Add minecraft.admin.command_feedback permission
c3749a23 Remove the Damage tag from items when it is 0.
f74c7b95 SPIGOT-4706: Can't interact with active item
494eef45 Mention requirement of JIRA ticket for bug fixes
51d62dec SPIGOT-4702: Exception when middle clicking certain slots
be557e69 SPIGOT-4700: Add PlayerFishEvent.State.REEL_IN
CraftBukkit uses vanillas DimensionManager, but does not actually
register its own dimension types, etc, due to vanilla
This causes issues because anything, e.g. command feedback, trying
to print information about the world will often attempt to print out
the dimension name, which ends up throwing an NPE due to the lack of
a registered type, we work around this by just returning the world name,
this is not super elegant, but is the only route that promises not to
break stuff.
This fixes issues with upstreams changes to solve a private issue on
their side, as signs are placed, they may replace existing blocks, e.g.
grass, which breaks upstreams assumption that the sign is always placed
adjacent to a surface
Brought this patch back from the graveyard, 1.13.x changed how chunks
where loaded and the patch was dropped.
Prior to this change the server would crash when attempting to load a
chunk from a region with bad data.
After this change the server will defer back to vanilla behavior. At
this time, that means attempting to generate a chunk in its place
(and occasionally just not generating anything and leaving small
holes in the world (This might not be accurate as of 1.13.x)).
Should Mojang choose to alter this behavior in the future, this change
will simply defer to whatever that new behavior is.
Resolves#1672
This API is intended to expose useful heightmaps found in the server to API. This exposes all of the live world heightmaps currently in the server.
If a heightmap becomes impossible to implement, api spec allows the implementation to throw UnsupportedOperationException (far better than returning some weird unexpected value).
Tested via:
https://gist.github.com/Spottedleaf/5d47f67c55a9fb870251ff344bfeb6b3
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:
7c395d42 SPIGOT-4681: Note about additional world creation on STARTUP
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.
Spottedleaf
Zach Brown
William Blake Galbreath
Shane Freeder
Aikar