Developers!: You will need to clean up your work/Minecraft/1.13.2 folder for this
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:
b850a822 SPIGOT-4526: Add conversion time API for Zombie & subclasses
CraftBukkit Changes:
38cf676e SPIGOT-4534: CreatureSpawnEvent not being called for CHUNK_GEN
b446cb5d SPIGOT-4527: Fix sponges with waterlogged blocks
6ec8ea5c SPIGOT-4526: Add conversion time API for Zombie & subclasses
c64fe508 Mappings Update
a3c2ec03 Fix missing ServerListPingEvent call for legacy pings
Spigot Changes:
1dc156ce Rebuild patches
140f654d Mappings Update
Portion of diff was dropped in the mappings update commit.
Also remove the option to remove invalid statistics. The server will
automatically do this now as of... 1.13?, our option wasn't even doing anything.
* Add PlayerConnectionCloseEvent
This event is invoked when a player has disconnected. It is guaranteed that,
if the server is in online-mode, that the provided uuid and username have been
validated.
The event is invoked for players who have not yet logged into the world, whereas
PlayerQuitEvent is only invoked on players who have logged into the world.
The event is invoked for players who have already logged into the world,
although whether or not the player exists in the world at the time of
firing is undefined. (That is, whether the plugin can retrieve a Player object
using the event parameters is undefined). However, it is guaranteed that this
event is invoked AFTER PlayerQuitEvent, if the player has already logged into
the world.
This event is guaranteed to never fire unless AsyncPlayerPreLoginEvent has
been invoked beforehand, and this event may not be called in parallel with
AsyncPlayerPreLoginEvent for the same connection.
Cancelling the AsyncPlayerPreLoginEvent guarantees the corresponding
PlayerConnectionCloseEvent is never called.
The event may be invoked asynchronously or synchronously. As it stands,
it is never invoked asynchronously. However, plugins should check
Event#isAsynchronous to be future-proof.
On purpose, the deprecated PlayerPreLoginEvent event is left out of the
API spec for this event. Plugins should not be using that event, and
how PlayerPreLoginEvent interacts with PlayerConnectionCloseEvent
is undefined.
Replaces the "use-chunk-inhabited-timer" config option with the options
"use-fixed-chunk-inhabited-time" and "fixed-chunk-inhabited-time".
When using "use-fixed-chunk-inhabited-time=false" everything will be the
same like it was with "use-chunk-inhabited-timer=true".
When using "use-fixed-chunk-inhabited-time=true" and
"fixed-chunk-inhabited-time=0" everything will be the same like it was
with "use-chunk-inhabited-timer=false".
Instead of just using 0 when all chunks should be treated equally this
allows to fine-tune vanilla gameplay.
Allows access to some offline player properties even when there
are no worlds loaded. This is typically a rare occurrence but
probably one that should be covered as best we can.
Fixes GH-1701
Note to other developers: This commit may require you to wipe your
workspace as a result of the changes to BD.
--- work/BuildData
Submodule work/BuildData f527a8ff..d56672db:
> Mappings Update
--- work/Bukkit
Submodule work/Bukkit 0c1d258bb..db06c80d7:
> Add list of entities to EntityTransformEvent
> SPIGOT-4347: Add API to allow storing arbitrary values on ItemStacks
---work/CraftBukkit
Submodule work/CraftBukkit 6a398ac44..068dab5be:
> Enable optional source JAR shading via profile shadeSourcesJar
> Use ImmutableList rather than AbstractList for CraftMetaBook
> Fix setRecipes(List) not setting Knowledge Book recipes.
> Mappings Update
> Add list of entities to EntityTransformEvent & move die calls
> SPIGOT-4347: Add API to allow storing arbitrary values on ItemStacks
> Add Vanilla help to default permissions
--- work/Spigot
Submodule work/Spigot a1f2566f6..e769fe4d9:
> Mappings Update
> Rebuild patches
This patch aims to ensure that MCP World#getNearestAttackablePlayer
will not trigger chunk loads due to PathfinderGoalNearestAttackableTarget
performing a ray trace operation by pre-checking the maximum limit;
Given that the implementation shows that the limit should only ever
decrease when set, allowing us to skip further checks earlier on
when looking for an attackable entity
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:
9a793cce Remove no longer applicable caveats to setPlayerListName
7137829e SPIGOT-4496: Undeprecate MapView.getId and make int
de33ade0 Remove some draft API designations
a35fa838 SPIGOT-4472: Add Consumer scheduler methods
CraftBukkit Changes:
8cd538e6 SPIGOT-4498: Crash on startup
b4ee04ba SPIGOT-4496: Undeprecate MapView.getId and make int
ec937d0e SPIGOT-4472: Add Consumer scheduler methods
Spigot Changes:
a1f2566f Use monotonic time for watchdog
bc4adcbf SPIGOT-4498: Crash on startup
bb387e6c Rebuild patches
Now properly serializes and deserializes, is factored into hashcodes and
equality checks, etc
Deprecates the old Material based system and replaces it with a new one
based around NamespacedKeys and NamespacedTags. This allows the API to
extend beyond vanilla and Material enum based properties to datapack
based tags and elements.
Fixes GH-1635
Entities must be dismounted before teleportation in order to avoid
multiple issues in the server with regards to teleportation, shamefully,
too many plugins rely on the events firing, which means that not firing
these events caues more issues than it solves;
In order to counteract this, Entity dismount/exit vehicle events have
been modified to supress cancellation (and has a method to allow plugins
to check if this has been set), noting that cancellation will be silently
surpressed given that plugins are not expecting this event to not be cancellable.
This is a far from ideal scenario, however: given the current state of this
event and other alternatives causing issues elsewhere, I believe that
this is going to be the best soultion all around.
Improvements/suggestions welcome!
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:
e4183e70 SPIGOT-4491: Fix InventoryMoveItemEvent causing repeated events
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:
689f1565 SPIGOT-4487: Clarify PlayerInteractEvent docs
01ffd1c7 Add Player to BlockCanBuildEvent
CraftBukkit Changes:
1cac9d4f Add Player to BlockCanBuildEvent
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:
b1d149cf SPIGOT-4489: NOTE_BLOCK incorrectly has BlockStateMeta
Entities must be dismounted before teleportation in order to avoid
multiple issues in the server with regards to teleportation, while
we now lose the ability for plugins to monitor this specific case
of entity dismount, the alternative is that we allow a cancellable
event, but silently ignore the cancelled status, which might cause
further issues for plugins tracking state
Given that nobody can be relying on the Cancellable state of those
events during teleportation due to the issues that arise from this,
this is a small trade off
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:
17ff1e04 SPIGOT-4483: Missing EntityInteractEvent call for zombies on eggs
--- work/Bukkit
Submodule work/Bukkit 1627782b..67e91ef7:
> Fix some incorrectly handled JavaDoc
> SPIGOT-4478: Update PlayerLoginEvent docs
> Add API to manipulate boss bar of entities and those created by commands
--- work/CraftBukkit
Submodule work/CraftBukkit ca22de36..3a911828:
> SPIGOT-4477: Arrows only firing direction of boat
> SPIGOT-4478: NPE during PlayerLoginEvent recipe manipulation
> Add API to manipulate boss bar of entities and those created by commands
--- work/Spigot
Submodule work/Spigot 2474d93d..947a8e7f:
> Rebuild patches
This patch, while would have been nice, would just take too much
in order to re-implement it to retain and handle all of the state
changes possible, and complicates retaining state properly
Fix SpongeAbsortEvent handling
Only process drops when the block is actually going to be removed
Upon "real world testing", there was needed and unimplemented methods
on BlockStateListPopulator; This commit (which should fix#1663) aims
to improve the coverage of this class.
We should aim to look into expanding this class down the line, or aim to
improve the servers ability to capture these changes
This restores monster aggression range back to normal when
Activation Range is less than the monsters aggression range.
This allows an entity to try to acquire targets still during
inactive ticks, which will also then let it go into immunity stage.
extends BlockStateListPopulator to suppport checking block types in the
physical world it's representing, allowing for blocks making modifications
to the world to maintain proper state.
This change allows ArmorStands with ticking disabled to visually update
their equipment and pose properly.
Given the wide range of usage of ArmorStands, I have not changed
their tick loop when their tick is enabled as usual. Doing so may
likely gains in the future, though additional testing would be
needed to ensure nothing breaks.
Fixes GH-1593
Per MC-138093 comments, ForkJoinPool uses unlimited threads if
parallelism is ever 1. A 2 core machine will end up with 1
with the change I had previously made, so bumped the min
to 2 so we will never trigger the unlimited thread situation.
This aligns the min back with Spigot, but allows use of more
threads on systems with more cores.
Upstream removed the ability to consistently use a custom InventoryHolder,
However, the implementation does not use an InventoryHolder in any form
outside of custom inventories.
We can take that knowledge and apply some expected behavior, if we're given
an inventory holder, we should use it and return a custom inventory with the
holder, otherwise, create an inventory backed by the intended inventory, as
per upstream behavior.
This provides a "best of both worlds" scenario: plugins with InventoryHolder's
will always work as intended in the past, those without will create implementation
based inventories.
