Using an unbound LinkedBlockingQueue means you *have* to set core and max core thread pool size the same, as they will never go above the minimum pool size by just passing them through. So this fixes the async command executor pool to actually use 2 threads, and also cleans up other usage to be explicitly "fixed" thread pool sizes, and splits off one more in Minecraft's Util class
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.
Spigot incorrectly returns false in Wolf#actuallyHurt if the armor
absorbed the damage causing the entity to not get damage invuln ticks.
Resolve this by correctly reverting to the "always true" return value as
the event is not cancelled.
* Configurable Entity Despawn Time
Co-authored-by: Kevin Raneri <kevin.raneri@gmail.com>
* Rebase
* Rebase
* rebase
* throw exceptions for this map
---------
Co-authored-by: Kevin Raneri <kevin.raneri@gmail.com>
Fixes incorrect spigot handling of the invulnerability damage
reduction applied when an already invulnerable entity is damaged with a
larger damage amount than the initial damage.
Vanilla still damages entities even if invulnerable if the damage to be
applied is larger than the previous damage taken. In that case, vanilla
applies the difference between the previous damage taken and the
proposed damage.
Spigot's damage modifier API takes over the computation of damage
reducing effects, however spigot invokes this handling with the initial
damage before computing the difference to the previous damage amount.
This leads to the reduction values to generally be larger than expected,
as they are computed on the not-yet-reduced value.
Spigot applies these reductions after calling the EntityDamageEvent and
*then* subtracts the previous damage point, leading to the final damage
amount being smaller than expected.
This patch cannot simply call the EntityDamageEvent with the reduced
damage, as that would lead to EntityDamageEvent#getDamage() returning
the already reduced damage, which breaks its method contract.
Instead, this patch makes use of the DamageModifier API, implementing
the last-damage-reduction as a DamageModifier.
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.
ffm requires 1) native access allowed (the jdk cracks down on undocumented native access in 22) and 2) reverting the default console back to java.base, so the internal jline doesnt take over
