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.
As seen in https://github.com/PaperMC/Paper/issues/12645, the BlockStateListPopulator always destroy
block entity data when the block state change. However this is something that should be supported
so plugin can retrieve block entity data of captured blocks.
Additionally only create snapshots at the end of the capture so we don't need to refresh block entity
data for decorator like the beehive, this is possible since multiple capture
at the same position is not supported and will overwrite the previous data anyway.
The underlying components seem to still be appended in a different order compared to vanilla but that is fine as the order does not really matter in an ItemStack's component map.
However, 'hidden_components' seem to have defined order that must be respected. We use a hashset and keep the fixing order that is on the vanilla datafixer.
EAR yields immunity to entities that are not on the ground and are not
"flying entities". What this "flying entity" filter actually entails
however is undocumented. The previous implementation checked for
FlyingMob, which only covered ghasts and phantoms, leaving entities like
the blaze and wither untouched for *some* reason.
To be improved by consulting the elders (cat).
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.
Mojangs EQUIPMENT_SLOT_MAPPING uses an Int2ObjectArrayMap and hence
technically does provide iteration stability, however it is filled from
a MapN, which destroys the well order of the entries.
To iterate from smallest to largest inventory index correctly, this
commit introduces a sorted array based on the EQUIPMENT_SLOT_MAPPING.
Player info packets carry chat state to other clients since the
introduction of chat signatures. Queuing these packets while force
pushing chat packets allows for potentially inverted packet order, which
may cause chain corruption on clients.
If the player is not affected by movement through blocks, then
storing the movement would eventually invoke logic to apply effects
caused by moving through such blocks. For example, moving through
a portal in spectator mode and then later switching to creative mode
would portal the player.
This method was used pre 1.17 era where an Entity was explicitly
tied to a (then called) Chunk's entity slices. If an entity
was not inside a Chunk, then it was considered invalid as
it was not possible to save the entity.
In 1.17+, entities are now tied to a separately tracked entity
section management system. This system is far more reliable now
as it no longer requires a full chunk load to properly track
entities for saving. As a result, an Entity if inside the world
is always attached to some entity chunk section (except in rare
cases in Vanilla which are fixed in Moonrise).
As a result, whether the chunk the entity is in is loaded is no
longer an indication of whether they are tracked in the world
and we can reliably infer that the entity is correctly in the
world through the valid field alone.
Additionally drop the isInWorld() check, as valid=true implies
isInWorld=true. More importantly, the isInWorld() check invokes
getHandle which may trip a thread check on Folia. This will fix
World#getEntities() and friends exploding on Folia.
However, World#getEntities() on Folia still cannot reliably return
all entities in the world as actions such as cross-region
(not cross-world) teleporting will remove entities from the world.
The windows file system does not write metadata unless
the FileChannel is explicitly flushed with metaData=true.
Note: Setting SYNC (not DSYNC) on the FileChannel does not appear
to write the metadata.
Specifically, we are interested in writing the last modified
timestamp so that fs watchers can detect when RegionFiles are
modified.
