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.
This diff was accidentally dropped when updating to hard fork.
This diff importantly:
- Does not return true if the async catcher is disabled
- Does not return true during shutdown
- Returns true for any instance of TickThread (enables
watchdog and Folia threads to be considered main)
ForkJoin thread pools are specially handled with CompletableFuture.
Specifically, join()/get() calls will allow work stealing from other
fork join threads.
This fixes a deadlock where the worldgen worker is waiting on the
I/O worker.
VoxelShape coordiantes generally are an integer + a sum of powers of
two between [-1, -3]. Most offsets are generally an integer. As
a result, applying an offset to the coordinates generally results
in an error of 0. However, coordinate inputs do not follow such
trends. Thus, when applying an offset to the coordinate input,
there may be some floating point error.
By applying the offset to the VoxelShape coordinates, we can
eliminate additional floating point error.
This change also fixes the inconsistency when using
the single AABB, as input coordinates were not offset
when using the single AABB as the single AABB is already
offset.
Fixes https://github.com/Tuinity/Moonrise/issues/81
This specific issue is caused by floating point error resulting
in the falling anvil's y position becoming around -8E-17 when it
should be 0.
While this is still very comfortably in the collision
epsilon (1.0E-7), this results in the falling anvil's y block
position to become -1 (as the block position is simply
the floor of the coordinate).
1. For NearbyPlayers, we need to be using the view distance, and
not the load distance (which is +1 of the view distance).
2. Correctly clamp tick distance to view distance. Since
load distance is +1 of view distance, we need to subtract
one from the load distance when clamping.
Additionally, add checks inside ViewDistances to ensure that
the inputs are in range to catch future errors.
Also, clamp simulation distance, as values < 0 or above
MAX_VIEW_DISTANCE do not make sense to configure.
Force LazyEntityCollisionContext#getEntity() to delegate
- By delegating when the entity is retrieved, we can correctly catch
cases where the collision method is inspecting some entity state.
Adjust constant collision shape determination
- Our previous hack did not actually catch every case. For now,
it will only assume a constant collision shape of EMPTY for
air blocks.
Fixes https://github.com/PaperMC/Paper/issues/11697
This patch does not appear to be doing anything useful, and may
hide errors.
Currently, the save logic does not run through this path either
so it did not do anything.
Additionally, properly implement support for handling
RegionFileSizeException in Moonrise.
ThreadUnsafeRandom is a random implementation that is
identical to LegacyRandomSource behaviourally, but
without the thread checks.
SimpleThreadUnsafeRandom is ThreadUnsafeRandom except with
its nextInt(int) function replaced with a faster
but more biased implementation when bound is very large.
Additionally, replace Level/Entity randoms with ThreadUnsafeRandom.
This avoids the expensive CAS logic at the expense of losing the
thread check.
This method should be present in Paper, not just in Folia, given
that the GlobalRegionScheduler is present.
Additonally, add Server#isOwnedByCurrentRegion(World, int, int, int, int)
for checking of a rectangle of chunks is owned by the current region.
Firstly, the old methods all routed to the CompletableFuture method.
However, the CF method could not guarantee that if the caller
was off-main that the future would be "completed" on-main. Since
the callback methods used the CF one, this meant that the callback
methods did not guarantee that the callbacks were to be called on
the main thread.
Now, all methods route to getChunkAtAsync(x, z, gen, urgent, cb)
so that the methods with the callback are guaranteed to invoke
the callback on the main thread. The CF behavior remains unchanged;
it may still appear to complete on main if invoked off-main.
Secondly, remove the scheduleOnMain invocation in the async
chunk completion. This unnecessarily delays the callback
by 1 tick.
Thirdly, add getChunksAtAsync(minX, minZ, maxX, maxZ, ...) which
will load chunks within an area. This method is provided as a helper
as keeping all chunks loaded within an area can be complicated to
implement for plugins (due to the lacking ticket API), and is
already implemented internally anyways.
Fourthly, remove the ticket addition that occured with getChunkAt
and getChunkAtAsync. The ticket addition may delay the unloading
of the chunk unnecessarily. It also fixes a very rare timing bug
where the future/callback would be completed after the chunk
unloads.
First, if the light data is not marked as correct, we should not be
parsing it in the first place. This will eliminate errors from
parsing possibly different versioned light data.
Secondly, if parsing the light data throws an exception (from
the SWMRNibbleArray constructor), then we can simply mark
the returned chunk as having incorrect light data - rather than
propagating the exception and causing the chunk to be re-generated.
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.
Spottedleaf