Fixes twisted vines not connecting properly when grown via
bonemeal by a player.
In general, look at making this logic more robust (i.e properly handling
cases where a captured entry is overriden) - but for now this will do.
No longer rely on world time as plugins like to screw it up.
Add a new flag -Dpaper.ticklist-max-tick-delay= that
will automatically drop any tick entries that have a delay
exceeding the specified amount. This is only useful
for cleaning up a world that has been corrupted by
certain blocks having a huge tick delay.
Aimed at resolving #3251
Also fix an issue with some rails connecting incorrectly
that I found when testing.
Co-authored-by: Spottedleaf <Spottedleaf@users.noreply.github.com>
Move the criterion storage to the AdvancementDataPlayer object
itself, so the criterion object stores no references - and thus
needs no cleanup.
Fixes#3050
When adding/removing to a chunk, we need to also look at
editing the loaded entity list.
Co-authored-by: Spottedleaf <Spottedleaf@users.noreply.github.com>
The streams hurt performance and allocate tons of garbage, so
replace them with the standard iterator.
Also optimise the stream.anyMatch statement to move to a bitset
where we can replace the call with a single bitwise operation.
Faster Entity iteration using the chunks full entity list and array access.
Faster chunk lookups skipping the cache, as the pattern of access was not suitable
for cache usage (each request will likely blow cache)
This reduces the cost of Entity Activation Range's initial marking.
Only occurred when entries were scheduled with huge tick delays
Add two flags to debug excessive tick delays:
-Dpaper.ticklist-warn-on-excessive-delay=true (false by default)
and -Dpaper.ticklist-excessive-delay-threshold=ticks which
sets the excessive tick delay to the specified ticks (defaults to
60 * 20 ticks, aka 60 seconds)
Removing the try catch and generally reducing ops should make it
faster on its own, however removing the try catch makes it
easier to inline due to code size
* Optimise random block ticking
Massive performance improvement for random block ticking.
The performance increase comes from the fact that the vast
majority of attempted block ticks (~95% in my testing) fail
because the randomly selected block is not tickable.
Now only tickable blocks are targeted, however this means that
the maximum number of block ticks occurs per chunk. However,
not all chunks are going to be targeted. The percent chance
of a chunk being targeted is based on how many tickable blocks
are in the chunk.
This means that while block ticks are spread out less, the
total number of blocks ticked per world tick remains the same.
Therefore, the chance of a random tickable block being ticked
remains the same.
Spottedleaf