Correctly return the resource pack status from Player#getResourcePackStatus()
when the resource pack was send and accepted during the configuration stage.
Add a non-Vanilla converter which removes ENTITY fall_distance
entries if they are equal to 0.0. This fixes incorrectly
converted data before b6675e47ca
DataConverter incorrectly placed a fall_distance value with 0.0
if the entity did not have a FallDistance entry. This results in the
entity spawn data having 2 entries, which prevents finalisation
logic from running.
We can fix this by removing the fall_distance entry if it is 0.0.
In 1.21.8 there will be a proper fix for this and the patch can be
dropped.
It looks like BaseSpawner will not run natural spawn finalization
unless the entire data tag only contains the ID.
This only fixes converting old data, we need a fix for already
converted data.
This implements a solution that preemptively exits the tick loop if we have already marked the connection as disconnecting. This avoids changing the result of Connection#isConnected in order to avoid other possibly unintentional changes. Fundamentally it should be investigated if closing the connection async is really still needed.
This also additionally removes the login disconnecting logic for server stopping, as this was also a possible issue in the config stage but also shouldn't be an issue as connections are closed on server stop very early.
Additionally, do not check for isConnecting() on VERIFYING, as that seemed to be an old diff originally trying to resolve this code, however isConnected is not updated at this point so it pretty much was useless.
We are already using the dropped stack to determine the type, we
might as well also use it for the count, given that plugins can already
mutate the type, might as well let them mess with the amount.
When converting entity/poi data (SimpleRegionStorage),
we need to insert the new data version so that force upgrading
will write the data back with the correct version.
The vast majority of the time, there are no tasks scheduled to
the EntityScheduler. We can avoid iterating the entire entity list
by tracking which schedulers have any tasks scheduled.
If the player dies, then they are removed from the world and
as a result are not present in the world entity map.
To guarantee that the player entity scheduler is ticked, we can
tick all schedulers for players in the server player list, and
then skip all players we find in the world entity map.
This problem is not present on Folia since Folia must guarantee
that the player remains in the world.
The ServerLevel#getAllEntities function only returns entities which
are accessible. FeatureHooks#getAllEntities will return all
entities, whether or not they are accessible.
Use the new hook in the EntityCommand, which allows server admins
to inspect entities in unloaded chunks.
Use the hook as well for ticking the EntityScheduler. This fixes
an issue whether unloaded entities did not have their scheduler ticked.
Send more keepalives, record all transactions within the last minute.
We send more keepalives so that the latency calculation is more
accurate. Since we send more keepalives, we track all pending
keepalives in case multiple end up in flight.
Additionally, replace the latency calculation with a true
average over the last 5 seconds of keepalive transactions.
Note: This cannot happen on the Fabric/NeoForge versions since
async ticket level processing is not allowed, but can happen on
Paper. This change is made here so that Paper can
remain in sync.
Ticket level decreases may be handled asynchronously when the
off-thread invokes processTicketUpdates() when the main thread
is running ChunkHolderManager#tick(). This is because the ticket
update is queued during tick(), but not executed (invoking
processTicketUpdates) until after releasing the ticket lock.
This creates a small window for an off-thread to invoke
processTicketUpdates() and steal the update.
When the update is stolen, the full chunk status update (if any)
will be eventually queued to execute via the chunk task queue.
If the chunk queue is processed during the server tick at any
point other than the ChunkHolderManager tick, then any ticket
level decrease will violate an important invariant in the
Moonrise chunk system: ticket level decreases only occur during
ChunkHolderManager tick. This invariant exists to make interfacing
with the chunk system easier, especially working with off-thread
contexts.
This change is specifically made to work towards fixing
https://github.com/PaperMC/Folia/issues/363
Vanilla does not increment ticket timeouts if the chunk is
progressing in generation. They made this change in 1.21.6
so that the ender pearl ticket does not expire if the chunk
fails to generate before the timeout expires. Rather than
blindly adjusting the entire system behavior to fix this
small issue, we instead add non-expirable tickets to keep
ender pearls ticking.
This option should probably be removed as its a descendant of an option that allows "old tnt cannon" behavior before ~1.9 But this improves the fix so properly update the velocity/position rather than the questionable way it was doing it before.
It's important to convert the ItemStack present inside
the text component. The ItemStack nests TEXT_COMPONENT (written
book pages, custom name, ...) which would otherwise not be walked
since we have set a breakpoint at the version and moved the walker
to the next version step.
This fixes item names for hover events inside written book pages
failing to convert to NBT. This issue is also present on DFU.
Notably, this does not bump the world data version. This will be left for when the actual Vanilla base is updated, just in case. This early bump will likely be the exception for more ironed out update previews in the future.
If an exception is thrown during decompress then the read process
would be started again, which of course would eventually throw in
the decompress process.
Previously we added a parameter allowing for level data to be saved asynchronously which was then overriden by a vanilla parameter which does the opposite.
This reverts back to the previous behavior that we were doing before.
Co-authored-by: Warrior <50800980+Warriorrrr@users.noreply.github.com>
Replaced the Boolean-based visual fire system with TriState for improved clarity and flexibility, enabling three distinct states: TRUE, FALSE, and NOT_SET. Deprecated older methods in favor of new ones and updated internal handling to reflect these changes. Adjusted serialization and deserialization logic to accommodate the new TriState implementation.
Previously the server attempted to compute the block placed by using the
BlockPlaceContext. This approach however fails on replacable blocks, as
the BlockPlaceContext computes this during its construction, which
happened after the actual world modification.
The commit reworks this approach and now stores metadata in the
InteractionResult which can later be read.
The diff is structured to allow for easy future expansion of the tracked
metadata.
