Age | Commit message (Collapse) | Author |
|
|
|
Re-adds the 'chunkinfo', 'holderinfo' and 'debug chunks' commands.
Additionally, this re-adds chunk debug dumping during watchdog
long timeouts.
|
|
Somehow, a chunkholder is present in the unload queue after
it has been unloaded. It is likely that this is a result of
adding the chunk holder to the unload queue while it is
unloading. However, that should not be possible.
To find out where it is being added to the unload queue, track
the last stacktrace which adds to the unload queue and check
on chunk holder remove if the holder is present in the unload queue
and log the stacktrace.
|
|
In the new chunk system, the chunk is only at FULL when either
the FULL callbacks have been invoked or during the FULL callbacks.
|
|
Remove utilities that are unused, as well as replacing
the full chunk map with a concurrentutil implementation.
Additionally, fix the addition/removal of chunks to/from the
full chunk map so that getChunkIfLoaded correctly returns a
non-null chunk when calling the load or unload events.
|
|
Fixes:
- EntitiesLoadEvent/EntitiesUnloadEvent not firing
- Chunks not saving properly in a lot of cases
|
|
|
|
|
|
this shouldn't be needed as we are requesting EMPTY status, however there is a deeper issue that we will just work around for now
fixes #10916
|
|
fixes #10915
|
|
It always returns null now. So it could NPE and is not useful.
|
|
The upstream implementation is returning true for non-full chunks.
This fix is not ideal since the new chunk system doesn't have a region file/chunk status patch. May want to be revisited before a non-experimental release.
|
|
|
|
Brackets got lost during the update, leading to an incorrect
precondition call.
|
|
Fallback to the global registry if no level exists
Fixes #10899
|
|
The javadoc for EnchantmentRegistryEntry.Builder accidentally refers to
GameEventRegistryEntry, which is a different buildable registry entry.
|
|
|
|
(#10896)
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Bjarne Koll <[email protected]>
|
|
|
|
|
|
Implementations for ChunkStatuses below FULL are supposed to always
return ProtoChunk instances. However, since we used the last completed
status, it could return LevelChunk.
To resolve this, follow Vanilla behavior of tracking chunk
completions by status and replace old ProtoChunk statuses with
ImposterProtoChunk when the chunk generates to FULL.
Additionally, implement an optimisation for retrieving full chunks
by storing a map of pos -> LevelChunk. This requires only a simple
map lookup to occur for full chunks which are loaded.
|
|
* Registry Modification API
* some fixes
* even more fixes
|
|
|
|
|
|
|
|
Upstream has released updates that appear 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:
2b4b6d14 PR-1023: Convert InventoryView to interface
CraftBukkit Changes:
68603b1c1 Use expanded interaction ranges for traced interact events
eae9f760c PR-1414: Convert InventoryView to interface
ee9eafe67 Fix Implementation for DamageSource#isIndirect for internal custom causing entity
|
|
|
|
|
|
|
|
The new behavior of disconnect to block the current thread until the disconnect succeeded is better than throwing it off to happen at some point
|
|
|
|
|
|
|
|
The armor items may not exist, so we need to null check it.
|
|
|
|
|
|
|
|
|
|
The method sadly is not usable in 1.21 without a player as all of an
enchantments attribtue modifiers rely on a base value supplied by a
player. The method could only offer a rough estimate based on some
default values, however a better method for this should be added down
the line rather than trying to force such logic into the existing one.
|
|
Correctly use the DispenseEvent's #getItem ItemStack when placing the
saddle on entities during a dispense behaviour instead of the original
stack.
|
|
A long standing bug in spigot and its derivatives was the fact that
players taking damage while blocking with a shield would not receive
invulnerability, while they do in vanilla.
This enabled the pvp technique of disabling a shield and immediately
attacking again to knock a player into the air.
While upstream fixed this and properly aligned itself with vanilla
damage logic (in this specific case) changing such long standing
behaviour has some downsides.
To allow players used to this specific bug to still use it, this patch
introduces a configuration option to re-introduce said bug.
As there is no easy way to *only* re-add this bug, the option is found
in the unsupported section as it may introduce other damage related
disparity from vanilla.
|
|
|
|
|
|
|