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:
0969eedc Clarify furnace burn time behaviour as per SPIGOT-844
16453bfd SPIGOT-4503: Add API to insert complete ItemStack into Jukebox
CraftBukkit Changes:
dff66dfc Reduce copying of positions from block states
91cae6ef SPIGOT-4387: Durability looping from cancelled BlockPlaceEvent
24c5e68c SPIGOT-4493: Allow burnt out furnaces to remain lit like Vanilla whilst retaining SPIGOT-844 API
bc943daf Fix Jukebox API not synchronizing playing data with state
fe89a8c1 SPIGOT-4503: Add API to insert complete ItemStack into Jukebox
fc102494 Make CraftBlockState use BlockPosition
89ab4887 SPIGOT-4543: Jukebox playing calls should not use legacy data
6ff5a64c SPIGOT-4541: Cancelled bucket events require inventory update
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:
78568d11 Tweak Block.getTemperature to return actual block temperature
9ad459ca SPIGOT-2151: Add support for getting simple bounding box of a block
ad28b19f Add BlockData#getAsString(boolean) to hide unspecified states
CraftBukkit Changes:
1b982fd6 Tweak Block.getTemperature to return actual block temperature
f55c8191 SPIGOT-2151: Add support for getting simple bounding box of a block
4b843638 Add BlockData#getAsString(boolean) to hide unspecified states
Spigot Changes:
573cdf2c BUILDTOOLS-425: Disable commit.gpgSign in applyPatches.sh
667bdd6b Deprecate Spigot version of Entity.isInvulnerable
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:
bb6f384a SPIGOT-4534: Only call event for new chunks
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.
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:
e693496c SPIGOT-4467: Improve ExpiringMap
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
Spigot Changes:
2474d93d SPIGOT-4462: Catch async chunk regenerate
Splits time updates into incremental updates as well as does
the updates per world, so that we can re-use the same packet
object for every player unless they have per-player time enabled.
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
Bukkit Changes:
9d0221aa API to get client side view distance.
9be7f0ea SPIGOT-4395: Additions to PlayerBedEnterEvent.
01e534c6 Minor cosmetic cleanups to imports etc
CraftBukkit Changes:
96c461b3 API to get client side view distance.
e2785f4e Remove note about development build
a8000588 SPIGOT-4395: Additions to PlayerBedEnterEvent.
Spigot Changes:
117d4f7e Rebuild patches
Optimizes small movements by entities by merging the movement
into the entities next larger movement, until enough movement
velocity has been hit.
This reduces collision detection and able to reduce movement
cpu cost by 5-7%.
The default option of 0.75 seems to provide all the gains without
any noticable behavior change to entity movement.
We have to exclude slimes due to weird jumping animation bugs.
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
These methods are used internally throughout the game for things like spawning mobs during day/night only or making them burn in daylight, etc. Now exposed for plugin usage.
If a chunk load comes in on a chunk load or gen thread,
execute it synchronously on that thread instead of enqueueing it.
It doesn't make sense to enqueue it as that thread is then
going to future.join() it and block until it's ready anyways.
This opens risk to a deadlock if every load or gen thread is
waiting on a recursive chunk but it will never finish because
all of the threads are waiting.
If we identify an invalid offset (negative, or the header sectors),
then back up the region file and erase that specific chunks offset
data.
This will avoid crashing the server with AIOBB errors and also avoids
server owners having to consider the entire region file 'lost'.
I'm not sure what leads to this state, I can only assume write cut
off mid bits.
In this scenario, there is absolutely no way to know where the chunk
actually is in the data file without loading every
single chunk in the file. And even to do that, would be quite extreme
due to the fact the file isn't in some orderly fashion.
Since the file is backed up, the user can use a region fixer tool
externally to try to restore that single chunk. We could even
add a command to restore a chunk from a backup file in a different
commit later on. But this at least prevents the server from crashing.
The server will just generate a new chunk and move on,
after printing an error to the console about it.
Also fixed the case reported in this issue about the server
hanging when a corrupt chunk is encountered, so this issue
is now fully closed.
Resolves#1541
Applied a "Only run this when the blocks are different" to
a place, that apparently must be called even with the same
block but different other data I guess.
This was causing oddness with light data.
Chunk Generation was occuring while inside of the progressCache lock
this caused the progressCache to stay blocked for a long period of time
which then blocked main when main needed to clean the expiring map.
We now maintain a separate map for pending scheduler entries, that
we can join on if a 2nd request comes in while one is starting.
This strategy keeps the lock only for a fraction of time but
maintains thread safety.
So now the chunk is generated without holding a lock and wont
block the main thread on the expiring map as we will insert it
once ready.
1) Removed "Regen" mode of Dupe UUID resolver, forced safe.
Some servers who updated before we had safe mode added still had this value.
There's really no reason to keep this mode, as we've seen that vanilla
triggers this often and 99.9999999% of cases will be an actual duplicate
that needs to be deleted.
2) Made Vanilla Debug messages about dupe UUIDs and dupe uuid resolve messages
only show up if the debug.entities flag is on. This will stop server owners
from panicing from seeing these logs, and stop opening bug reports on this,
only for us to tell you "don't worry about it".
3) Avoid adding entities to world that are already added to world.
This can be triggered by anything that causes an entity to be added
to the world during the chunk load process, such as chunk conversions.
Issue #1544 was a case of this.
4) Removed debug warning about ExpiringMap.
Nothing more I know to do about this anyways. We recover from it,
stop warning to reduce noise of issues to us.
Seems my original pull for this created an unseen bug where the target timer would never run out (the slime would not "forget" it's target over time). Went ahead and fixed that, and made the code more legible by adding the imports.
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:
ee12ca7b Add maximum repair cost API to AnvilInventory
CraftBukkit Changes:
1ceee633 Implement maximum repair cost API to AnvilInventory
This will improve queue times by canceling chunks when a player
leaves the radius of an async loading/generating chunk.
This matches behavior we had pre 1.13 for loading too.
Primarily to update plugins for our fastutil relocation. Can also be
used to do things like debug plugins accessing versioned NMS packages in
an IDE pre-relocate step.
Following this comment on PaperLib, https://github.com/PaperMC/PaperLib/pull/2#discussion_r222761017
I've made non-snapshot TE's not update when they receive the update call. They still do the rest of the update, just not the applying of the TE data. This is to still allow forced physics updates etc. Also in the case of Jukeboxes, updating the properties
improved the water code so that immunity wont trigger if the entity
has the water pathfinder system active, so this improves support
for all entities that know how to behave in water.
Merged 2 EAR patches together, and removed an MCUtil method that
doesnt have a purpose anymore
Anything that posts something to main thread was not
correctly reporting their errors to the logger, passing the
ExecutionExcetion instead of the cause. This resolves that,
as well as patches some simple cases of System.nanoTime where mojang
had used a LongSupplier to use a different method on client.
This update introduces Entity Activation Range for water mobs.
Activation Range has been one of my biggest performance improvements
I ever added to Minecraft, however "Entity is in Water" is an immunity
case that keeps an entity active.
This update ignores the water check for known water based mobs, allowing
them to actually go inactive.
In addition to that, a new config option was added to spigot.yml to go with
the rest of the entity-activation-range options to let you configure
aquatic mobs like fish, squid and dolphins separately.
This should overall fix all lag caused by water mobs.
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:
867794b2 Make setPersistent also control player saving
CraftBukkit Changes:
02518f92 Make setPersistent also control player saving
FileIOThread was using two volatile counters in order to track if
any pending work was in the queue, this causes potential concurrency
issues when this counter is updated from multiple threads, potentially
causing these counters to desync due to the unsafe volatile update
Shared Hosts have been concerned over the increased CPU usage that Async Chunks
has introduced. We understand that shared hosts can't allow 1 client
to abuse the systme resources depriving other servers of cpu time, so we've
added some configs to allow hosts to force some settings.
Hosts, you may set the following SYSTEM ENVIRONMENT VARIABLES (NOT JVM FLAGS)
to change some behavior:
PAPER_ASYNC_CHUNKS_SHARED_HOST_GEN=1 - Enable Single Threaded World Generation (capping CPU Usage
PAPER_ASYNC_CHUNKS_SHARED_HOST_GEN=2 - Disable Async Chunk Generation - Please do not do this!!!
- Minecraft is moving towards asynchronousm per-world chunk generation itself. You need to prepare
- for this, so please do not disable async chunk generation.
PAPER_ASYNC_CHUNKS_SHARED_HOST_LOAD=# - Where # is Maximum number of threads to use on Chunk Loading
- This is a max, so your end user can reduce it more too. I suggest no lower than 2. Minimum is 1.
- These are usually much faster request, so outside of loading entire worlds, They usually do not
- get as much load. Paperby default uses CPU Core count * 1.5, so this may default to a higher value
- on shared host and you should override it with this value to say 2-4.
These settings will override your clients paper.yml options. Set as a system wide environment
variable to ensure all Paper clients respect your resource usage desires.
Resolves#1520
This should greatly improve performance by using a No Op lock
while on the main thread.
Vanilla always had a write lock on write operations, but we added
a Read Lock during Async Chunks to make concurrent writes non fatal
for Async Chunks.
This means we added on a bunch of over head to all chunk read operations.
This corrects that, as well as disabling the write lock while on main thread.
It is a general rule that you do not touch a chunk async once it is loaded
into the world, as we never had locks on the chunk before 1.13 even.
So once we are on main, we don't expect concurrent access to begin with,
so we don't need the write locks either.
light calculations repeatedly looks up the same chunk while going
down on the Y access. Pass the chunk to it to skip many round trips
to the map lookup process.
while the gains arent as big since we have last access cache, it
should hopefully avoid many callstacks of depth and improve inlining,
as well as avoids entering a synchronized code block.
The avoiding of entering synchronized section is the main goal here.
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:
68588dac SPIGOT-4405: Chunk generation problem
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:
c71bb9ca Add PlayerRecipeDiscoverEvent and methods to (un/)discover recipes
CraftBukkit Changes:
7a2f4867 Implement PlayerRecipeDiscoverEvent and methods to (un/)discover recipes
During testing, I could not find any case of TabCompleteEvent firing,
however, upon reinspection of the code, and additional testing, this
appears to work fine without any changes on our part.
this has technically been a longer standing problem, but if an async
chunk loads after a chunk has been removed from the chunk map, it would
be treated as any other spare chunk and kept loaded until Chunk GC kicks in.
This fixes that, but also obsoletes ChunkGC in that anytime we load a spare
chunk (a chunk outside of any players view distance), we will immediately
mark it for unload.
This should reduce the amount of spare chunks loaded on a server.
GH-1507
The canWander property is initialized to true by default, however when
loaded from NBT, if the key doesn't exist the property will be set to
false. The correct solution is to ensure the key exists before setting
the property.
The patch was previously applied wrong, and still caused chunk loads.
Now, we will prevent it again, but also added a config option to
disable this optimization.
However, I also updated it so that doors are not removed if the chunk
the door is in is unloaded, so this should avoid breaking farms.
Fixes#1506
Vanilla has some screwy logic that doesn't send a chunk until
it has been post processed. This is an issue as post processing
doesn't occur until all neighbor chunks have been loaded.
This can reduce view distance while generating terrain, but also
cause bugs where chunks are never sent to the client.
This fix always sends chunks to the client, and simply updates
the client anytime post processing is triggered with the new chunk data.
The server does a "Did my update succeed" check after setting
a blocks data to a chunk.
However, writes can not fail outside of a hard error or a
a race condition from multiple threads writing, which is
not something that should ever occur on the server.
So this check is pointless, as if it did occur, the server would
be having data corruption issues anyways.
This provides a small boost to all setType calls.
Vanilla has risk of losing entities by causing them to be
removed from all chunks if they try to move into an unloaded chunk.
This pretty much means high chance this entity will be lost in this scenario.
There is another case that adding an entity to the world can fail if
the chunk isn't loaded.
Lots of the server is designed around addEntity never expecting to fail for these reasons,
nor is it really logical.
This change ensures the chunks are always loaded when entities are
added to the world, or a valid entity moves between chunks.
Hopefully will fix issues #1496 and #1434
The server triggers light recalculations even if the new block
is the same as the old block. At this time, BlockData Properties
do not impact light calculations.
So the only way light should change, is if the block itself
changes from 1 block to another.
Additionally, as of 1.13, water now only blocks 1 light level
instead of 3, meaning that light level decreasing is the same as air.
This means, transitions between water and air also do not need
to recalculate light, which saves a TON of updates caused by
fluids flowing.
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:
39ce5d3a SPIGOT-4399: ItemMeta.equals broken with AttributeModifiers
CraftBukkit Changes:
1cf8b5dc SPIGOT-4400: Populators running on existing chunks
116cb9a1 SPIGOT-4399: Add attribute modifier equality test
5ee1c18a SPIGOT-4398: Set ASM7_EXPERIMENTAL flag
Fix#1501
I just added a condition check to not start a new pathfinder goal if the turtle already has one set.
Needs more testing.
Minecraft is trying to set Dimension Objects based on a Dimension ID
Dimension ID's for custom worlds are dynamically allocate dand not guaranteed
consistent.
This removes checking the NBT data, as the Entity will always have its
DimensionManager set to the world it is being placed into.
This fixes corrupt entities breaking chunk saving in custom worlds.
Upstream has released updates that appears to apply and compile correctly.
This update has been tested to ensure that World Conversion still occurs correctly.
Bukkit Changes:
0812ce2c SPIGOT-4397: isChunkGenerated API
CraftBukkit Changes:
4824655c SPIGOT-4398: Upgrade to ASM 6.2.1 for better Java 11 support
eea43870 MC-134115: Fix issues converting tile entities
1a7f2d10 SPIGOT-4397: isChunkGenerated API
40aed54d SPIGOT-4396: Improve vehicle movement
Spigot Changes:
f6a273b1 Rebuild patches
This restores Asynchronous Chunk Loading to 1.13, as well as adds Asynchronous Chunk Generation..
This provides a massive boost to server performance and should bring 1.13 back closer to 1.12 performance levels for pre generated worlds.
World Generation will now be faster overall than 1.12 since 1.12 did not have async generation.
**DONATE:**
Lots of effort has went into making this happen. Want to say thanks and donate?
https://donate.emc.gs/AsyncChunks
light queue is actually buggy, so re-enabling the config.
however, if anyone is ok with the buggy behavior, made the max time lost due to
light queue configurable.
We want to get to making the ligth queue default if we can make it work perfectly.
also applying neighbor optimizations to use the faster method for light checks.
getDimensionId() returns the dimension id - 1. So without this patch
we would reuse an existing dimension id, if some other dimension was
unloaded before.
In Spigot this is nearly invisible because DimensionManager has no equals(),
so dimension id collisions just create 2 worlds with the same dimension.
The PaperWorldMap (Added in
https://github.com/PaperMC/Paper/blob/master/Spigot-Server-Patches/0376-Optimize-Server-World-Map.patch ) changes this - Now the dimension is overwritten if there is some collision,
what causes players to teleport to incorrect worlds, World checks will no longer work
and many more evil things.
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:
b9620fd9 API to generate filled explorer maps
CraftBukkit Changes:
c1ecaa2f API to generate filled explorer maps
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:
6f57bf95 SPIGOT-4391: Sign editable API
CraftBukkit Changes:
5cffeca2 SPIGOT-4391: Sign editable API
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:
dcb43ef8 MC-136886: locate command loads chunks without needing to.
Spigot Changes:
f823ac54 Rebuild patches
JEP 181 brings a new bytecode format for nest mates. ASM API 7 supports
this, but API 7 is still experimental. Attempting to load a Java 11
class that contains nest mates will cause an
UnsupportedOperationException, as API 6 can't handle them. This doesn't
really require any changes to the rest of the code, since this is just
related to ASM's visitor.
We want to use the stable API 6 for all other plugins, only using the
experimental API when required, so we check the class version first.
This should be removed as soon as ASM API 7 is stable.
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:
fc10dec5 Don't throw error on invalid data in CraftMetaItem.
Fixes GH-1471, GH-1474
As a result, data that no longer parses correctly will not crash the server
instead just logging the exception and continuing (and in most cases should
fix the data)
Player data is fixed pretty much immediately but some block data (like
Shulkers) may need to be modified in-game in order for it to re-save
properly
No more crashing though.
There is no reason for the light queue to even be an option. This
enables the light queue for everyone.
This also improves the "can we still tick" time logic to always
check before running a light operation.
previously, we always executed at least 10 on the first world
(but not other worlds...), but we are seeing light take up some
heavy time, so improving that for now.
I've now also improved recheck gaps logic to happen at the end of all single block updates
This also prevents multiple gap checks, as previously if a tick skipped
the gaps check, the next tick would end up re-adding the entry again,
resulting in multiple gap checks.
This now just sets a marker "We need to recheck gaps" and will only occur
once.
This also should reduce chunk loads, as previously, we checked if
the neighbor chunks were loaded for the gap check, however those
neighbor chunks might of unloaded before the light queue operation
actually ran. Now, the neighbor chunk is done when the gap check
is being done, so it should avoid loading chunks.
Fixes#1466Fixes#1431
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:
4db9e3dc Add API to locate structures
CraftBukkit Changes:
65bb2d0f Increase expiration time to 10 days
88a5346f Add API to locate structures.
Spigot Changes:
68acb93f Rebuild patches
Some chunks that need conversion may fail the loadChunks pass, and
end up entering the world gen code to finish processing.
We solved this on the API level before, but this needs to apply to
all chunk loads when gen=false
This adds a new Future based, Consumer<Chunk> based, and ability
to control whether or not to generate to the Async Chunk API.
Until Async Chunks merges, these API's are still synchronous, but
this commit will allow plugins to start using the API's in use
with the Async Chunks beta.
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:
cbb4fc16 SPIGOT-1916: Attribute modifiers for ItemStacks
CraftBukkit Changes:
8164f4b2 SPIGOT-1916: Attribute modifiers for ItemStacks
Spigot Changes:
38536abd Rebuild patches
A bug with double chest conversion would lead to data
loss from chunks if they crossed chunk boundries.
This fixes the issue.
It should now be safe to upgrade worlds to 1.13.1
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:
26c89277 SPIGOT-4385: Clearer error for invalid generator-settings
This event extends the PreCreatureSpawnEvent and includes the position
of the spawner that spawned the entitiy. (similarly to how the
SpawnerSpawnEvent contains the spawner's BlockState).
This one doesn't include the state though as getting the block and
generating that snapshot is a bit wasteful.
If you try to load a world inresponse to another world loading,
a concurrent modification exception will throw.
This avoids that by making a defensive copy of the list for the server init stage.
you might want to do this if you want to guarantee your world loads
immediately after the vanilla worlds before another plugin has a chance
to load worlds during POST_WORLD plugin stage.
Minecraft moved worlds to a hashmap in 1.13.1.
This creates inconsistent order for iteration of the map.
This patch restores World management to be back as an Array.
.values() will allow us to iterate as it was pre 1.13.1 by
ArrayList, giving consistent ordering and effecient iteration performance.
KeySet and EntrySet iteration is proxied to the List iterator,
and should retain manipulation behavior but nothing should be doing that.
Getting a World by dimension ID is now back a constant time operation.
Hopefully no other plugins try to mess with this map, as we are only handling
known NMS used methods, but we can add more if naughty plugins are found later.
Multiverse was tested with this and no breakage.
Allows you to add to paper.yml
seed-overrides:
world_name: some seed value
This will ignore every where a seed is set/created/loaded and force
a world to use the specified seed.
This seed will end up being saved to the world data file, so it is
a permanent change in that it won't go back if you remove it from paper.yml
It's always been commonly said to 'ignore' that TPS was '19.X', that
it was fine.
I suspect that the inaccuracy of floating point math resulted in us
losing precision over time, making it difficult to actually get back to 20,
as you know the fun 0.1 + 0.1 ... 9 more times != 1 problem.
BigDecimal supports working with doubles with higher precision.
This change makes it so our RollingAverage class maintains all of the data
using BigDecimal and using BigDecimal arithematic operations.
This ensures we have extremely high precision, enabling us to
actually be able print '20 TPS' when TPS is perfect.
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:
4b9a93ec Add BatToggleSleepEvent
CraftBukkit Changes:
a222e4a2 Implement BatToggleSleepEvent
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:
79ada744 SPIGOT-4382: Fix damage_absorbed statistic
computeIfAbsent would leak as the entry
was never registered into the ttl map
This fixes that ,as well as redesigns cleaning to
not run on every manipulation, and instead to run clean
once per tick per expiring map.
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:
94b8708a SPIGOT-4373: Item display colours are white by default
61668436 SPIGOT-4378: Fix mistakenly included code
When a mob was about to load a chunk to try to spawn in, we did not
increment the attempt counter, resulting in it being stuck in the mob
spawn loop for a long time and hanging servers.
Found some more unsafe operations in DataFixers.
Also replaced quite a few bad uses of Map.containsKey
containsKey is a common newbie mistake that "reads" cleaner, but
results in double the performance cost of all map operations as
containsKey in MOST cases where null values are not used is identical to get() == null
Considering how deep datafixers go in call stacks, with tons of map lookups,
this micro optimization could provide some gains.
Additionally, many of the containsKey/get/put style operations were
also a concurrency risk, resulting in multiple computation/insertions.
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:
47b9cf30 SPIGOT-4372: LightningStrikeEvent cause API
a9ceda75 Include the plugin channel name in the exception message
CraftBukkit Changes:
a4bdecff SPIGOT-4372: LightningStrikeEvent cause API
34caaf6d SPIGOT-4371: Trident damaged when event cancelled
97315374 SPIGOT-4369: Handle cancelled trident event
bf1c8273 SPIGOT-4370: Remove vehicle if its passenger spawn event was cancelled
Spigot Changes:
6b015b4b SPIGOT-4370: Remove vehicle if its passenger spawn event was cancelled
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:
7033f180 Hoist out synchronisation from ChunkRegionLoader
Spigot Changes:
500ff5d4 Rebuild patches
Additional Paper changes:
Fixed Versioned World Folders to not synchronize on ChunkRegionLoader
Optimized Save Queue even more to use a Long2ObjectOpenHashmap for save map
Add World#getXIfLoaded to IWorldReader to expose it to more places
Adds an API to allow plugins to instruct a Mob to Pathfind to a Location or Entity
This does not do anything to stop other AI rules from changing the location, so
it is still up to the plugin to control that or override after another goal changed
the location.
Fixes GH-1417, GH-1424 (probably).
There are other issues in this area, including just how much a mess it
is but we will get to those when we get to those.
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:
3e2858f6 SPIGOT-4352: MoistureChangeEvent
5466e281 Add BlockDispenseArmorEvent
CraftBukkit Changes:
3123a069 SPIGOT-4352: MoistureChangeEvent
226db0ea Add BlockDispenseArmorEvent
cd367fa4 Fix bad thread safety in ChunkRegionLoader
3f5ca5f2 SPIGOT-4355: Improve cancelling VehicleEnterEvent
Spigot Changes:
145a37ae Rebuild patches
3f2423cc Rebuild patches
Adds an API to allow plugins to instruct a Mob to Pathfind to a Location or Entity
This does not do anything to stop other AI rules from changing the location, so
it is still up to the plugin to control that or override after another goal changed
the location.
This restores vanilla behavior of allowing placed chests to retain any Block Entity Tag data.
Upstream added filtering to chests, breaking vanilla behavior, and preventing use of loot table chests as a reward mechanism.
Upon review, we can find no security risk in allowing players to place a chest with NBT data, as Spawn Eggs, Minecarts, command blocks etc all have their own checks.
Additionally, survival mode players, non op players can not create these items anyways. If a player has Creative or Op, they already have high levels of access.
Plus, Chests aren't the only inventory that could have free form items, so this filter was insufficient anyways.
The PluginManager incorrectly used synchronization on firing any event
that was marked as synchronous.
This synchronized did not even protect any concurrency risk as
handlers were already thread safe in terms of mutations during event
dispatch.
The way it was used, has commonly led to deadlocks on the server,
which results in a hard crash.
This change removes the synchronize and adds some protection around enable/disable
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:
310dc809 Add ServerLoadEvent
CraftBukkit Changes:
19d654bd Add ServerLoadEvent
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:
632449b6 SPIGOT-4349: End portal has wrong TeleportCause
3eb8af23 SPIGOT-4348: Use online player for setting skull owner if possible
We are seeing issues with DataFixers being not thread safe in async chunks
and even in some spigot packet sending code.
There are a few more global objects that are mutated that need to
be synchronized to be safe for use over multiple threads.
There may be more cases, but these are extremely obvious ones.
This method will return the Block a player is looking at while taking into consideration the AABB of each block in the path.
For example, you can look through the 1/4 space of air in a Stair block and get the block behind it instead of the Stair block you are looking past.
Some things break from this, while this was trying to fix other things
since the thing this patch tried to fix still had problems and required
yet another fix, just going to remove this patch.
Fixes issue #1177
`MapMaker#weakKeys()` makes the `Map` use identity comparison for the keys, while also enabling the automatical removal of dropped classes from the cache.
The changes are the same as in #1399, except now the original patch is modified instead of a new one being created.
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:
8ab814cd Add getFacing method to get the current cardinal direction an entity is facing.
CraftBukkit Changes:
ee5efeb0 Add getFacing method to get the current cardinal direction an entity is facing.
Spigot Changes:
0ede7d0e Rebuild patches
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:
3037eb3e BlockSpreadEvent for Kelp
6cf60193 SPIGOT-4340: Improve client bug workaround
Spigots implementation around the header/footer strips newlines from the
header/footer, this patch allows the tab list header/footer to retain newlines.
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:
dc69d2b3 Fix unbound shaped recipe ingredients
ForgeFlower is better than Spigots FernFlower at decompiling the source.
However, in order to maintain the CraftBukkit patches, we must keep
using spigots for the primary.
However, for any file that we import on top of Spigots imported files
there is nothing stopping us from using better decompiled files.
So these changes will use ForgeFlower to maintain a better set of
decomped files, so anything we add on top of Paper can start off
in a better spot.
Fixes GH-1389
Because we are no longer enabling creepers to rapidly change status
every tick, in order to prevent event spam, their datawatcher value
ends up negative.
This datawatcher value is used to increment the fuseTicks within the
creeper tick. Because the value is negative, it is constantly zero'd
and therefore never incremented, instead acting the same as creepers
that aren't ignited.
We can just as easily increment this ourselves when the creeper is
ignited, so that's what we'll do.
Uses optimized check to avoid major locks and large method.
Will improve inlining across many hot methods.
Improve getBrightness to not do double chunk map lookups.
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:
9ca2772d API to prevent PlayerBedLeaveEvent from changing a player's spawn location
CraftBukkit Changes:
1486c295 API to prevent PlayerBedLeaveEvent from changing a player's spawn location
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:
97368963 Update ChunkSnapshot docs about valid coordinates
CraftBukkit Changes:
3831ae62 SPIGOT-4325: Validate coordinate arguments in Chunk/ChunkSnapshot
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:
9636bb8d SPIGOT-4319: Conduit damage should be a block event
Also fixes some bugs in ours
Ultimately they both are near the same, but ours is behind the synchronized gate.
Mojangs is mixed behind 2 different synchronization contexts (chunks can lock 2 different objects)
Mojang also blindly unsets the ref on any chunk unload, not just if its the one being pointed to.
Updated Upstream (Bukkit/CraftBukkit/Spigot)
Bukkit Changes:
2dcc44dc SPIGOT-4307: Fix hacky API for banners on shields
e0fc6572 SPIGOT-4309: Add "forced" display of particles
efeeab2f Add index to README.md for easier navigation
f502bc6f Update to Minecraft 1.13.1
CraftBukkit Changes:
d0bb0a1d Fix some tests randomly failing
997d378d Fix client stall in specific teleportation scenarios
b3dc2366 SPIGOT-4307: Fix hacky API for banners on shields
2a271162 SPIGOT-4301: Fix more invalid enchants
5d0d83bb SPIGOT-4309: Add "forced" display of particles
a6772578 Add additional tests for CraftBlockData
ce1af0c3 Update to Minecraft 1.13.1
Spigot Changes:
2440e189 Rebuild patches
4ecffced Update to Minecraft 1.13.1
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:
162bda93 Add note about 1.13.1
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:
f41aae40 Remove reflection from CraftBlockData
Replaces PR #1161 for 1.13
Resolves#930
Adds new slime pathfinder related events. All events can be cancelled.
- `SlimePathfindEvent` is the base event of all added events. Cancelling this event will cancel all pathfinders.
- `SlimeWanderEvent` is called when slimes wander around by either swimming or moving/jumping forward. Cancelling this event will prevent slimes from moving around and jumping, but they will still look around and target players.
- `SlimeSwimEvent`is called when slimes are swimming in water/lava. Cancelling will prevent the slimes from moving/jumping in water/lava.
- `SlimeChangeDirectionEvent` is called when a slime changes directions. It contains the new `yaw` position the slime wants to change to, and it can be set to another value. Cancelling this event will prevent slimes from changing directions (except for when targeting players).
- `SlimeTargetLivingEntityEvent` is called when a slime targets a player. NMS uses EntityLiving here so it is named this. Contains the LivingEntity the slime has targeted. Cancelling this event will prevent the slime from targeting the entity and will make it lose current focus.
Adds `Slime#canWander()` and `Slime#setWander(boolean)` for a more persistent control (does not persist server restarts) over all 4 pathfinder types without the spammy event having to be cancelled a bajillion times a second.
Video demonstration: https://youtu.be/8hcLqazmO28
Test plugin: https://pastebin.com/cFgcgdWV
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:
82f4b3b1 SPIGOT-4292: Ignore itemstacks with invalid enchants
Mojang changed behavior of .cloneItemStack() so that if you clone while
count = 0, it clones as AIR instead of original Item type.
So we needed a flag to keep old behavior.
* master:
Fix bug in last patch
Ensure chunks are always loaded on hard position sets
Improve Watchdog Early Warning Feature - Closes#1319
Allow disabling armour stand ticking
Player Movement, Entity Creation and Teleportation move
entities with a very "You are here, no debate" change, making
the server register them as there, regardless if that chunk was
loaded or not.
It appears possible that with hack clients and lag, a player
may be able to move fast enough to move into an unloaded
chunk and get into a buggy state.
To prevent this, we will ensure a chunk is always loaded,
guaranteeing that the entity will be properly registered
into its new home comfortably.
Closes#1316
1) Don't kick in until server has started (the full crash will still kick in before full start)
2) Delay reporting until 10 seconds, then print every 5
3) Make the intervals configurable
4) Make it able to be disabled by setting every interval to <= 0
Banners only load color if the world is set. I don't know why...
For some reason, the world was not set on these, so it was changing behavior.
So if we want an accurate clone, world needs to be set.
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:
dde07e23 Update docs for Enderman carrying methods
CraftBukkit Changes:
452a1738 SPIGOT-4271: Fix API error when enderman are not carrying a block
Particle packets contain a boolean which marks the particle to either force or show normal to the receiver.
Spigot has been sending all particles with the force boolean which overrides client particle settings.
Related changes in this commit;
- Add a force option to the ParticleBuilder API, which defaults to true to keep spigot consistent with existing api.
- Add a new spawnParticle method to support this mode as a parameter. Of course kept existing api methods the same so as to not break them.
Let me know if changes are needed.
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:
4a241086 SPIGOT-4261: Missing turtle / phantom spawn egg meta
1) Don't kick in until server has started (the full crash will still kick in before full start)
2) Delay reporting until 10 seconds, then print every 5
3) Make the intervals configurable
4) Make it able to be disabled by setting every interval to <= 0
I have tested that the Replenishing Feature still works as expected.
Lootable API's that now have Bukkit equivalents are now deprecated.
Bukkit Changes:
f0f33981 SPIGOT-1936: LootTable API
CraftBukkit Changes:
c0df4b82 SPIGOT-1936: LootTable API
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:
c23d391f Update documentation of BlockPhysicsEvent
14fcd896 SPIGOT-4258: Add Player.updateCommands method
CraftBukkit Changes:
15da7067 SPIGOT-4258: Add Player.updateCommands method
Spigot Changes:
2b0e71c7 Rebuild patches
* [CI-SKIP] add .editorconfig for base code style settings
* * Created patch 0349 (fixes#471)
* * Made requested modifications
* * Made requested modifications (x2)
* * Made recommended changes (x3)
* * Moved ConcurrentMap return values to Map as no functions specific to ConcurrentMap were used (backing map is still ConcurrentMap)
* Removed ConcurrentMap import
If the file has partial data written but not the full 8192 bytes,
then the server will be unable to load that region file...
I don't know why mojang only checks for 4096, when anything less than 8192 is a crash.
But to be safe, it will attempt to back up the file.
Upstream has added the equivalent of our SentientNPC API, with exception to the EnderDragon.
We've added Mob to the EnderDragon, and our SentientNPC API should behave the same.
Vex#getOwner has been deprecated and a replacement Vex#getSummoner has been added using Mob.
However, since 1.13 is not production ready, SentientNPC API is subject for removal in 1.13.1 since
1.13 API is not compatible with 1.12.
Please move to the Mob interface ASAP.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
c5ab54d8 Expand GameRule API
ab9a606c Improve entity hierarchy by adding Mob interface.
CraftBukkit Changes:
29e75648 Expand GameRule API
50e6858b Improve entity hierarchy by adding Mob interface.
0e1d79b4 Correct error in previous patch
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:
53d3ac0a SPIGOT-4238: Sometimes buckets are leaky client side when empty event is cancelled
Upstream has released updates that appear to apply compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing.
Bukkit Changes:
d2834556 SPIGOT-4219: Event for PigZombies angering.
CraftBukkit Changes:
a9c796f1 SPIGOT-4184: Fix furnaces not matching Vanilla smelt or animations
195f071e SPIGOT-4219: Event for PigZombies angering.
5e3082c7 SPIGOT-4230: Improve legacy block types
See: https://github.com/PaperMC/Paper/issues/1304
Changes the UUID sent to client to be based on either
the texture payload, or random.
This allows the client to render multiple skull textures from the same user,
for when different skins were used when skull was made.
Closes#1304
I misinterpreted some code as a risk of entity loss, but now
after deeper study, I see how that code was used more and why
it was adding entities to chunks that they shouldn't have been
in during a world transfer process.
also ensure we never process already valid entities. this shouldnt be possible as of recent
commits as we made the entity slice array safer, but doesn't hurt for this logic to be safe too
incase that patch got dropped in a future version by accident/necessarily
1) Chunk Registration might kill an entity, don't add it to the world if it did!
2) By default, entities are added to the world per slice iteration.
This opens risk of the slices being manipulated during chunk add if an
EntityAddToWorldEvent spawns an entity into this chunk.
Fix this by differing entity add to world for all entities at the same time
3) If a duplicate entity is attempted to add to the world of an entity, and
the original entity is dead, overwrite it as the logic does for unloaod queued entities.
Should hopefully finish up issues with #1223
* master:
MC-135506: Experience should save as Integers
Fix EXP orb merging causing values to go negative - Closes#1169
Add "Safe Regen" Duplicate UUID resolver and make default
After witnessing behavior of the regeneration logs, its clear that Vanilla
has had bugs with saving duplicate entities for a while....
Some entities are saved in multiple chunks, and now we are bringing those duplicates
out that use to never surface.
This mode will analyze if the entity appears to be a duplicate (near the other dupe uuid)
and delete the entity instead.
This should reduce regenerations to entities that are nowhere near each other, and
therefore more likely to be subject to real UUID collisions due to our
previous bug, and therefor should survive the chunk load.
Fixes GH-1295
Non-standard sized portals exacerbate a flaw in the vanilla
portal teleportation adjustment logic.
As a result, an entity can end up slightly inside of the surrounding
portal blocks. In vanilla, this issue is minor and you are adjusted out
as if it never happened. In CraftBukkit and derivatives, the
anti-suffocation behavior activates and players end up teleported on top
of their portals.
This improves the offset so as to keep the issue from ever occurring in
the first place.
Special thanks to CarpetMod who appears to have had this fixed for some
time, and has licensed their code such that we can use it as needed.
Due to the changes in 1.13, clients will send a tab completion request
for all bukkit commands in order to factor in the lack of support for
brigadier and provide backwards support in the API.
Craftbukkit, however; has moved the chat spam limiter to also interact
with the tab completion request, which while good for avoiding abuse,
causes 1.13 clients to easilly be kicked from a server in bukkit due
to this. Removing the spam limit could cause issues for servers, however,
there is no way for servers to manipulate this without blindly cancelling
kick events, which only causes additional complications. This also causes
issues in that the tab spam limit and chat share the same field but different
limits, meaning that a player having typed a long command may be kicked from
the server.
Splitting the field up and making it configurable allows for server owners
to take the burden of this into their own hand without having to rely on
plugins doing unsafe things.
This patch has been applied to 1.12.2 in order to allow people using
plugins which allow clients of newer versions to connect, this is
not a common practice, however is being done as a level of nicety
given the current status of 1.13
We have a result boolean for this already, and this
method was meant to be "Try from cache, if that fails, look it up"
So NPE'ing there just wasn't correct.
In 1.13 the method previously used now returns translatable keys.
`block.minecraft.cobblestone` instead of `Cobblestone`
We just need to make sure we're translating those keys.
ideally this should of never mattered, as it will only
be hit if you teleport out of an unloaded chunk...
But apparently some people are triggering this.
See #1223
No entities were lost in this bug, just we were triggering the add entities
before they were loaded due to an inconsistent order of putting chunk into chunkmap.
Any entity that appeared to be gone on the last build will now be back.
This should not ever be used in production!!
This setting is intended for testing so you can try out converting your world
without actually modifying the world files.
This will add some additional overhead to your world, but you're
just testing anyways so that's not a big deal :)
Will store in a folder named after the current version.
PlayerData and Data folders are copied on server start, so there
may be some delay there, but region files are only copied on demand.
This is highly experiemental so backup your world before relying on this to not modify it
1.13 undesirably changed behavior here that chunk load event fired
before the entities were added to the world.
This means any plugin that spawns entities in chunk load event
causes the entities to be registered to the chunk, and then
added to the world twice.
Moves Entity Add to World to be done anytime a chunk is
registered to the Chunk Map, and ignore other calls.
Fixes#1288
* master:
Always process chunk registration after moving
Always move Entity to its new Chunk even if unloaded
If Entity is added to chunk, look up the chunk if current isnt set
Ignore Dead Entities in entityList iteration
Always process chunk removal in removeEntity
Spigot 1.13 checks if any field (which are manually copied from the ItemStack's "tag" NBT tag) on the ItemMeta class of an ItemStack is set.
We could just check if the "tag" NBT tag is empty, albeit that would break some plugins. The only general tag added on 1.13 is "Damage", and we can just check if the "tag" NBT tag contains any other tag that's not "Damage" (https://minecraft.gamepedia.com/Player.dat_format#Item_structure) making the `hasItemStack` method behave as before.
Check the `ItemMetaTest#testTaggedButNotMeta` method to see how this method behaves. (I also added some extra tests).
`hasItemMeta()` will return true if `ItemStack.getDamage() != 0` or it has the `Damage` tag or any other tag is set.
Closes#1222
This will help guarantee that entities are always in the
chunk that they are currently located at.
Should hopefully also fix Citizens triggering the "Saved to wrong chunk" message
Vanilla logic here would allow us to remvoe an entity from
its current chunk, and if it was going to move into an unloaded
chunk, that entity would not be added to the unloaded chunk.
This is bad because this will result in the entity being lost!
In almost all cases, the chunk will be loaded, but in the event
it wasn't, instead of losing the entity, load the chunk to add
the entity to it.
Hopefully will (f)ix #1280...
I'm suspicious that Citizens isn't calling things in the same order and causes the current
chunk to not be set, which then bugs removals. Though this doesn't make any sense to me,
so this likely won't fix it...
But if the isAddedToChunk is true, we really should be returning a chunk anyways if its loaded.
A spigot change delays removal of entities from the entity list.
This causes a change in behavior from Vanilla where getEntities type
methods will return dead entities that they shouldn't otherwise be doing.
This will ensure that dead entities are skipped from iteration since
they shouldn't of been in the list in the first place.
Spigot might skip chunk registration changes in removeEntity
which can keep them in the chunk when they shouldnt be if done
during entity ticking.
Should fix some cases where "Entity is still in another chunk section"
Related to #1223
Vanilla logic checks unload queue and overwrites if its in it.
we're triggering this if a chunk unloads, and reloads immediately in same tick.
Added check for unload queue to not treat as duplicate
Also fixed the config setting not even loading
Should fix#1280
Citizens hijacks entity map, and im guessing under the right conditions
the result might actually be null during entity creation
Pre the cache patch, the id is looked up on save, so it was fine.
Now, if its null and the save ID is requested, we will try to look
it up again and cache it if found.
While upstream has now made this event cancellable, their changes
result in the vechicle being removed before the event is called,
thus leading cancellation to not behave as expected.
See https://github.com/PaperMC/Paper/issues/1223
Should fix Vanilla bugs
Minecraft is saving invalid entities to the chunk files.
Avoid saving bad data, and also make improvements to handle
loading these chunks. Any invalid entity will be instant killed,
so lets avoid adding it to the world...
This lets us be safer about the dupe UUID resolver too, as now
we can ignore instant killed entities and avoid risk of duplicating
an invalid entity.
This should reduce log occurrences of dupe uuid messages.
Also reduce the logging spam overall.
Setting the flag updates the spawner's delay which stops the spawner from trying to find a new spawn position each tick efter the event was cancelled/aborted which makes it usable for mob stackers/mergers and other plugins that don't actually want any mob to spawn in the spawner cycle but keep the overall behaviour close to vanilla.
This might slightly effect existing plugins that use this event but I doubt anyone really relied on this behaviour, the only possible use case that I can think of is cancelling the event until you find a suitable position in your plugin... and this should be handled by the plugin itself by cancelling and spawning at the position manually.
CraftBukkit added synchronization to read and write methods. This adds
much more contention on this object for accessing region files, as
the entire read and write of NBT data is now a blocking operation.
This causes issues when something then simply needs to check if a chunk exists
on the main thread, causing a block...
However, this synchronization was unnecessary, because there is already
enough synchronization done to keep things safe
1) Obtaining a Region File: Those methods are still static synchronized.
Meaning we can safely obtain a Region File concurrently.
2) RegionFile data access: Methods reading and manipulating data from
a region file are also marked synchronized, ensuring that no 2 processes
are reading or writing data at the same time.
3) Checking a region file for chunkExists: getOffset is also synchronized
ensuring that even if a chunk is currently being written, it will be safe.
By removing these synchronizations, we reduce the locking to only
when data is being write or read.
GZIP compression and NBT Buffer creation will no longer be part of the
synchronized context, reducing lock times.
Ultimately: This brings us back to Vanilla, which has had no indication of region file loss.
Closes#1260
* master:
Add some debug for entity slices
Mark chunk dirty on entity changes
Reduce and improve dupe uuid resolve message
Add more entity debug info
Bring some 1.13 authors to master
Fixed more stuff
Remove unsed method
Extend player profile API to support skin changes
Extend player profile API to support skin changes
Cleaned up some implementation notes to use existing Vanilla method for some things.
merged into parent patch
7dd5837d Fixed more stuff (NickAcPT)
09f01353 Remove unsed method (NickAcPT)
e5ea4656 Extend player profile API to support skin changes (NickAcPT)
e67d55d0 Extend player profile API to support skin changes (NickAcPT)
* pull/1250/head:
Fixed more stuff
Remove unsed method
Extend player profile API to support skin changes
Extend player profile API to support skin changes
0069113b Put the decompile fixes into MC Dev Fixes patch (Andrew Steinborn)
608b5e52 Optimize RegistryID.c() (Andrew Steinborn)
* pull/1257/head:
Put the decompile fixes into MC Dev Fixes patch
Optimize RegistryID.c()
It's possible we won't hit this on the servers current state since nothing is async,
but we are working towards that.
I experienced a crash due to this code during my work.
Our changes for the spawn radius have the potential to throw an ArithmeticException
should the server be stopped before we've loaded worlds, we check if the server is
running earlier to check if we should even consider attempting to load chunks, which
would cause us to, 1) not load chunks anyways, as we're disabled; 2) throw an
ArithmeticException due to us expecting that we're going to be loading more than 0 chunks.
These chunks are unfinished, and waste cpu time saving these unfinished chunks.
the loadChunk method refuses to acknoledge they exists, and will restart
a new chunk generation process to begin with, so saving them serves no benefit.
* master:
Duplicate UUID Resolve Option
Add more information to Entity.toString
change LAST_EDIT to PAPER_LAST_EDIT for edit commands
Add more information to Entity.toString()
Add Debug Entities option to debug dupe uuid issues
Guard the Entity.SHARED_RANDOM from seed changes
Create a symlink on not-windows to current minecraft decompile dir
Due to a bug in 2e29af3df0
which was added all the way back in March of 2016, it was unknown (potentially not at the time)
that an entity might actually change the seed of the random object.
At some point, EntitySquid did start setting the seed. Due to this shared random, this caused
every entity to use a Random object with a predictable seed.
This has caused entities to potentially generate with the same UUID....
Over the years, servers have had entities disappear, but no sign of trouble
because CraftBukkit removed the log lines indicating that something was wrong.
We have fixed the root issue causing duplicate UUID's, however we now have chunk
files full of entities that have the same UUID as another entity!
When these chunks load, the 2nd entity will not be added to the world correctly.
If that chunk loads in a different order in the future, then it will reverse and the
missing one is now the one added to the world and not the other. This results in very
inconsistent entity behavior.
This change allows you to recover any duplicate entity by generating a new UUID for it.
This also lets you delete them instead if you don't want to risk having new entities added to
the world that you previously did not see.
But for those who are ok with leaving this inconsistent behavior, you may use WARN or NOTHING options.
It is recommended you regenerate the entities, as these were legit entities, and deserve your love.
Added code that refreshes the player's skin by sending packets with a special order, telling the client to respawn the player and re-apply the game profile
Added code that refreshes the player's skin by sending packets with a special order, telling the client to respawn the player and re-apply the game profile
The removal of `ServerConnection.this.h.add(networkmanager);` got
lost in the 1.13 update, causing network managers to be registered
twice.
Fixes "handleDisconnection() called twice" warning spam in console.
Some of the fields in the anonymous class are named the same as the
surrounding method's parameters, which caused the fields to be
initialized incorrectly.
That way it keeps returning the same block position, resulting
in an infinite loop during chunk generation.
* master:
Don't process despawn if entity is in a chunk scheduled for unload
Fix Squids corrupting the entire servers entity randomness....
Fix placement of chunk tracking - Fixes#1199
This won't happen anyways if the user has
"skip ticking for entities in chunks scheduled for unload" turned on,
but if they don't, protect from this instant killing the entity to
keep it vanilla in behavior
a player may teleport away, and trigger instant despawn
