As part of Folia's place logic, the player's health is sent
after the respawn packet.
Since the health is <= 0.0, this would cause the client to
die again. This would cause the respawn screen to appear again,
and would additionally cause other players to see the player as
dead as well.
There is a small window where this would not have occurred, and
that is where the server would send the correct health before
the client ticks again. This is why the issue was not reproducable
locally, as there was is almost zero delay between those events
on an idle server and on perfect 0ms ping.
Fixes https://github.com/PaperMC/Folia/issues/112
The new spawn selection algorithm attempts to search the area
around a selected point, in an effort to reduce the total number
of chunk loads required to select a spawn point.
Additionally, the new spawn selection algorithm does not perform
recursion when the selected area is already loaded and owned by
the current region. This fixes https://github.com/PaperMC/Folia/issues/138
The end gateway is supposed to teleport the person who threw
the ender pearl.
The changes more closely mirror Vanilla behavior. The current
exceptions to Vanilla behavior are:
1. The first teleportation attempt for the end gateway always fails
2. If the ender pearl thrower is riding a vehicle, the thrower is
dismounted from their vehicle.
I don't see any solutions for #1 right now. The root issue is that
since the end gateway does not have a target location, it has to
search for one. However, it can _fail_ to find a target location,
in which case the teleportation should not occur. Since the search
must take place asynchronously, it requires the entity to be
removed from the world.
For #2, this is because Vanilla's behavior is broken and does not
correctly teleport players riding boats. We can fix this by simply
dismounting the player and teleporting them separately of their boat,
which seems to be what Vanilla is trying to do given it does _not_
try to teleport the root vehicle of the player.
This is a partial fix to https://github.com/PaperMC/Folia/issues/51
Since Folia moves the connection tick to the beginning of the tick,
the player's position would be incorrectly updated by the move
packet and be used during the tick.
This would cause the player's bounding box to be incorrect, which
would cause incorrect movement collision calculations, such as
colliding with fire.
Fixes https://github.com/PaperMC/Folia/issues/119
The intention behind erasing the memory was to match the case
where the villager would lose. However, there may not be
any competitors in which case the villager would never lose.
Instead, the new behavior is to behave as if the villager was not
loaded.
Fixes https://github.com/PaperMC/Folia/issues/64
Some plugins are bad and update the `from` position to something
completely garbage. To avoid a crash from this cross-region
teleportation, the teleportAsync function is now used.
The reason the teleport isn't simply ignored is since there may
be legitimate reasons to update the `from` position to something
off-region. This also handles the case where the plugin _uses_
an asynchronous teleport while cancelling the event.
This mirrors the behavior for changing the target destination
but not cancelling the event.
Fixes https://github.com/PaperMC/Folia/issues/115
When there are many chunkholders and regions, the cost of collecting
and checking tick thread for each one for every region save
becomes the biggest cost for the save call. To avoid this from
happening, collect the chunk holders from the current region's
owned sections.
This showed significant speedup locally when running the
"walk test" found in RegionizedServer locally (>90% of time
was spent on the holder iteration/checking).
While for merging the synchronisation occured, it did not synchronise
for splitting. This resolves a possible CME that may occur while
splitting regions.
It becomes invalid switching dimensions or by moving far. If
it used after teleporting, then it may also trip thread checks.
Fixes https://github.com/PaperMC/Folia/issues/94
Fix two regionizer issues:
In ThreadedRegionizer#addChunk, fix the incorrect handling
of merging two regions where one of the regions had
pending merges. If the first region had pending merges,
and the second was marked as "ready" then the merge would
cause a "ready" region to have pending merges. The fix is
to simply downgrade the "ready" region to "transient,"
as was previously done if the merge was delayed in the
case where the first region was "ticking."
Additionally, prevent the creation of empty regions
by checking if any new sections were created. This would
happen when a section existed, but had no marked chunks
in it AND all of the sections neighbours existed. In these
cases, no region needs to be created as no sections were
created.
