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
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.