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.
If an entity is removed while updating an entity slice, then the
iteration over the entity slice's entities could throw a cryptic
exception. Instead, it is better to prevent the entity removal
with a useful log message.
Fixes https://github.com/PaperMC/Paper/issues/9464
Since the packet is broadcasted for players, it means that
the packet will be sent to multiple players. In this case,
modifying the data results in a possible race condition
where a CME may occur as the packet will be serialized on
many different netty IO threads.
It shouldn't cost too much more to check the correct shape,
provided that it is cached and we use the overall AABB
to collect possible entities to check against.
The issues with the old check code is that it will use two
getEntitiesOfClass calls plus the addition of streams
_and_ the toAabbs() logic on VoxelShape. The new code
caches toAabbs, uses one getEntitiesOfClass call, and
does not use streams. Then compared to 1.12, we are
only performing two additional AABB checks per item.
Forgot to update the distandce field in the single user area map
on update, and additionally used the wrong radius (introduced
last commit) for the broadcast map
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
CraftBukkit Changes:
fd92f1e65 SPIGOT-7378: Add BlockDropItemEvent for Suspicious Sand & Gravel drops
cb1b69d13 SPIGOT-7377: Server sends player list twice
Spigot Changes:
16cfc987 Rebuild patches
For whatever reason, vanilla does not mark the chunk as
dirty when changing its tick lists.
We also have it return dirty if the time since the last
save has changed, since it would affect the tick offsets
in the ticklist.
CB used the dirty flag to construct the chunk unload event,
but then sets mustNotSave to the inverted value of the event
after calling the event without considering that the chunk may
actually be brought up to loaded status again later. Then, CB
overrides the isUnsaved method of LevelChunk to additionally
use mustNotSave.
Thus, if the chunk is not marked dirty when unloading, the
mustNotSave value will be set to true. Then, once the chunk
is reloaded and edited the dirty flag will be set. However,
when unloading the chunk finally, the isUnsaved method
will return false due to mustNotSave being true. Thus, the
chunk will never be saved.
To fix these issues, no longer make mustNotSave override
isUnsaved and always set the save flag for the chunk unload
event.
This issue started popping up recently due to the recent
change to mark chunks as not dirty after saving them, which
increased the chance of the save issue occurring in the first
place.
When we update the chunk state to border, it should be
the case that isChunkLoaded returns true and that
getChunkIfLoadedImmediately returns a non-null value.
Now add the chunk to the loaded map before making any
callbacks after updating to border state.
Patch documentation to come
Issues with the old system that are fixed now:
- World generation does not scale with cpu cores effectively.
- Relies on the main thread for scheduling and maintaining chunk state, dropping chunk load/generate rates at lower tps.
- Unreliable prioritisation of chunk gen/load calls that block the main thread.
- Shutdown logic is utterly unreliable, as it has to wait for all chunks to unload - is it guaranteed that the chunk system is in a state on shutdown that it can reliably do this? Watchdog shutdown also typically failed due to thread checks, which is now resolved.
- Saving of data is not unified (i.e can save chunk data without saving entity data, poses problems for desync if shutdown is really abnormal.
- Entities are not loaded with chunks. This caused quite a bit of headache for Chunk#getEntities API, but now the new chunk system loads entities with chunks so that they are ready whenever the chunk loads in. Effectively brings the behavior back to 1.16 era, but still storing entities in their own separate regionfiles.
The above list is not complete. The patch documentation will complete it.
New chunk system hard relies on starlight and dataconverter, and most importantly the new concurrent utilities in ConcurrentUtil.
Some of the old async chunk i/o interface (i.e the old file io thread reroutes _some_ calls to the new file io thread) is kept for plugin compat reasons. It will be removed in the next major version of minecraft.
The old legacy chunk system patches have been moved to the removed folder in case we need them again.
Logging into an unloaded world isn't going to end well.
This may fix the cases of people seeing errors about regionfiles
being closed, as loading chunks in an unloaded world will cause this
as the regionfile cache is closed but not cleared.
These can be called while an entity is being added to the world,
and if the entity is being added from a chunk load context the
sync load will block indefinitely (because the chunk load context
is for completing the chunk to FULL).
This does raise questions about the current system for these
dynamic registrations, as it looks like there is _zero_ logic
to account for the case where the chunk is _not_ currently loaded
and then later loaded.
Configurable under "settings.chunk-loading.player-max-chunk-load-rate",
defaults to -1. This commit also changes the chunk loading to be
distributed equally for all players, rather than distance based. This is
to ensure players flying around do not take priority over everyone else.
The exception to this new rule is the min-load-radius, which still has
priority over everything else.
The worldgen thread will attempt to get structure references
via the world's getChunkAt method, which is fine if the gen is
not cancelled - but if the chunk was unloaded, the call will block
indefinitely. Instead of using the world state, we use the already
supplied generatoraccess which will always have the chunk available.
Missed patch from tuinity merge
- Save level.dat first, in case the shutdown is killed later
- Force run minecraftserver tasks and the chunk source tasks
while waiting for the chunk system to empty, as there's simply
too much trash that could prevent them from executing during
the chunk source tick (i.e "time left in tick" logic).
Needs one for ItemStack and Entity. It looks like I missed
the entity one because Mojang defined it as being simple,
which it certainly isn't (they "missed" it too).
- Port player chunk loader patch
Makes the chunk system act as it did in 1.17, no additional tickets (and thus logic) to make a chunk ticking.
Adds simulation distance API, deprecates old no-tick method.
- More collision optimisations
Ancient patch from tuinity that never could be pushed to master.
- Fix Optimise ArraySetSorted#removeIf patch
- Execute chunk tasks fairly for worlds while waiting for next tick
- Port Replace ticket level propagator
The data provided is always from the regionfile thread, which
does not copy the data out. So if two separate calls need
the data, then there's going to be a problem.
These used to be here from Spigot, but were dropped with 1.17.
Now in 1.17, this state is _even more_ critical than it was before,
so these must exist to catch stupid plugins.