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.
