This is based on Moonrise's 1.21.2 branch, but this on
1.21.1 so some diffs cannot be applied (and this doesn't
compile).
See moonrise_update_1_21_2.txt for progress
When trying to fall back to offline player data in onlide mode,
we need to use the player file. This fixes a mistake during
update where 'file' was used, but the new code uses 'file1'
for the player file.
The function assumed that the current resize chain pointed to
the previous table, when in fact it pointed to the current table.
The function is supposed to restore the resize chain to the previous
table, previous increment, and previous index + new increment.
Mojang missed these in their mapping. Since the entity data
is used when spawning the bucketed mob, we need to have these
inside the id map to ensure that the entity data is converted
correctly if the entity id is missing.
We don't need to check for this with the chunk system, as
ticking chunks are actually guaranteed to ticking. Additionally,
ticking chunks may only become non-ticking during the chunk holder
manager tick - which will not happen during chunk ticking.
In Java 21, Thread#stop is no longer implemented and wiill throw
an exception when called. As a result, we simply cannot halt
the main thread during shutdown anymore.
1012-Use-distance-map-to-optimise-entity-tracker.patch:
1025-Collision-optimisations.patch:
1034-Actually-optimise-explosions.patch:
1039-Send-full-pos-packets-for-hard-colliding-entities.patch:
Implemented in Moonrise patch
1037-Distance-manager-tick-timings.patch:
Not needed
0668-Implement-regenerateChunk.patch:
API does not appear to be used, and it is a real pain to
implement this properly. The old patch did not handle
populators correctly, for example.
When teleporting, the spawn position packet will contain the
old position. Then the following tracking update will send a
teleport packet, but the client will lerp the position change
over 3 ticks. However, the client does not tick entities in
unloaded chunks - resulting in the lerp never occuring.
We fix this by sending the current position in the spawn packet.
Since the chunk may not even be at a loaded ticket level, the
getChunk call may invoke a sync load. To prevent this, we can
retrieve the full loaded chunk first which is guaranteed to be
non-null when unloading.
If the server tick length is high, then the amount of time
available to process chunk tasks inbetween ticks is low. As a
result, chunk loading and generation may appear to slow down.
To ensure that chunk tasks are always processed, we add logic to
execute chunk tasks during tile entity tick, entity tick, chunk
random ticking, and scheduled block/fluid ticking. The mid-tick task
execution is timed so that it is not prioritised over the server
tick.
While the null UUID is almost certainly an error, the old
implementation did not NPE as it used a plain HashMap for lookup
by UUID, whereas we use a ConcurrentHashMap which will NPE on
null keys.
The unload queue stored the chunks in the same section as
the chunk coordinate, when it needed to apply the unload shift.
Additionally, change the default region shift to the ticket
propagator shift as there is no benefit to using a low region
shift since no regionizing is occuring. This makes the unload
queue shift 6, which should reduce the number of sections to deal
with while processing unloads.
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.
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.
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.
Chunk system patch was refactored to take advantage of
newer ConcurrentUtil's concurrent long hash table (which
fixes hash collisions caused by chaining fastutil's long hash
and CHM's hash) plus some other minor improvements.
The chunk system was also merged with Starlight, which mostly
provides a small improvement to ThreadedLevelLightEngine#checkBlock
as the scheduling was rewritten.
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:
befcf86d SPIGOT-7740: Fix using new map cursor types
09229095 Add EntityDamageEvent.DamageCause#CAMPFIRE
CraftBukkit Changes:
a1d2cd152 SPIGOT-7747: Mob head is not dropped when mob was blown up by a charged creeper
8078294bc SPIGOT-7746: Server Crashing when Players Getting into End Portals
8d842e250 SPIGOT-7744: Fix exception for shooting projectiles with flame enchantment
64e0ad129 SPIGOT-7744: Fix crash when shooting arrows in creative mode
819f7a10a Fix player items not dropping on death
0a0229bb5 Implement DamageCause#CAMPFIRE and minor improvement in exception for Unhandled block damage
In order to check if a chunk exists, the RegionFile lock
(if the RegionFile is opened) will be acquired. However,
the RegionFile may be performing I/O operations, in which
case will stall the acquire operation.
To ensure that threads scheduling loads do not incur a stall,
we can avoid this check entirely - the RegionFile I/O
thread(s) will eventually perform the exist check itself.
The patch does not implement Vanilla forceUpgrade behavior.
Specifically, poi/entity conversion and regionfile recreation.
The Vanilla force upgrader is also no longer broken by CB, so the
bug fixes from this patch are not relevant anymore.
Instead of allowing chunks to fail to convert completely,
simply log the exception and the offending command. Command
conversion failure should never result in chunk data deletion,
as commands are not critical chunk data.
The old read() method should just redirect to the new
chunk system method, however due to an error in moving
the chunk system patch around the data version check was
left in the old (UNUSED) read() method.
The configuration should not allow the cache to break. Additionally,
invalidating the cache is cheap and as such there is no gain to avoid
invalidating it.
The delta position packet instructs the client to update
the entity position by a position difference. However, this position
difference is relative to the last position in the entity tracker
state, not the last position which has been sent to the player. As
a result, if the last position the player has recorded is different
than the one stored in the entity tracker (which occurs when a new
player is added to an existing entity tracker state) then the sent
position difference will cause a position desync for the client.
We can resolve this problem by either tracking the last position
sent per-player, or by simply resetting the last sent position
in the entity tracker state every time a new player is added.
Resetting the last sent position every time a new player is
added to the tracker is just easier to do, so that is what
this patch does.
This has been done to ensure that the shifts are not used
until the world object is being constructed, which is before
the global configuration is initialised. There also isn't any
reason for these shifts to be global anyways.
The epsilon used was in the opposite direction, which would cause
the getCollisions method to incorrectly return it for when players
were exactly on the border but not colliding. To bring it in-line
with the rest of the collision code, the collision must be into
the border by +EPSILON.
Fixes https://github.com/PaperMC/Paper/issues/9859
When ChunkAccess was converted to an abstract class some versions
ago, the code to initialise nibble arrays should have been moved.
However, the code was not moved and so now mods constructing their
own implementations of ChunkAccess would not have the nibble arrays
initialised.
This is ported to Paper from Starlight to keep the code base in sync,
not because it fixes anything known.
During feature generation, light data is not initialised and
will always return 15 in Starlight. Vanilla can possibly return
0 if partially initialised, which allows some mushroom blocks to
generate.
In general, the brightness value from the light engine should not
be used until the chunk is ready. To emulate Vanilla behavior better,
we return 0 as the brightness during world gen unless the target
chunk is finished lighting.
The regular light retrieval outside of WorldGenRegion remains
the same, as behaviorally chunks not lit should be at max
skylight and zero block light.
There is no point in initialising the sources in Starlight,
as we do not use them. Additionally, they are not saved to
disk so we do not need them.
Maintaining and initialising them is not a negligible cost,
which is why they are being removed.
On Folia, this map is modified by multiple threads and iterating
it may throw errors, for example using the /kill command or any
other command that uses an entity selector.
Since the method is overloaded, the call to super (which is changed
to call the overloaded method) without the additional parameters
will result in recursion.
The correct logic to implement NOT_SAME with Shapes#block()
is to test whether any shape data exists outside of [0.0, 1.0]
and to test whether the shape is completely filled from 0.0 to 1.0
on all axis. This can be implemented by checking whether the
bounds represent the full block and whether everything within
the bounds is filled.
Instead of searching/testing every player online on the server,
we can instead use the nearby player tracking system to reduce
the number of tests per search.
The CHUNKY_FIXERS field is modified during the constructors
of the BlockFixers, but the code that uses CHUNKY_FIXERS does
not properly ensure that BlockFixers has been initialised before
using it, leading to a possible race condition where instances of
BlockFixers are accessed before they have initialised correctly.
We can force the class to initialise fully before accessing the
field by calling any method on the class, and for convenience
we use values().
When per-player mob spawning is enabled we do not need to randomly
shuffle the chunk list. Additionally, we can use the NearbyPlayers
class to quickly retrieve nearby players instead of possible
searching all players on the server.
We can avoid multiple ticket additions for the same ChunkTasks
instance. This will help in situations where significant number of
block updates occur for the same chunk in the same tick, such as
water draining.
Spottedleaf