The behavioural nearby sensors are validated every tick on the entities
that registered the respective sensors and are therefore a good subject
to performance improvements.
More specifically this commit replaces the Stream#filter usage with
ArrayList#removeIf as the removeIf method on an array list is heavily
optimized towards a single internal array re-allocation without any
further overhead on the removeIf call.
The only negative of this change is the rather agressive diff these
patches introduce as the methods are basically being reimplemented
compared to the previous stream-based implementation.
See: https://nipafx.dev/java-stream-performance/
Note: Updated LICENCE.md to release this commit under MIT
A lot of plugins seem to use reflection to determine this, so this could be a bit of a starter-patch as future PR'ers could also exposed tracked entities as well.
For some reason, this doesn't always seem to capture all states of shutdown,
either the logger is just being fun, or, potentially, the thread is already
marked as dead when we're getting called so the trace is not generated through
the method on Thread
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
Bukkit Changes:
95ff95ed #588: Add Player#sendBlockDamage()
CraftBukkit Changes:
ea050e6e9 #807: Add Player#sendBlockDamage()
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
Bukkit Changes:
fcbd2266 #587: Fix various javadoc typos
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:
b7eed2546 SPIGOT-6307: Allow chest locks with legacy color codes to match against items with json colors
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
Bukkit Changes:
1e843b72 #510: Add NamespacedKey#fromString() to fetch from user input
a4d18241 #581: Add methods to modify despawn delay for wandering villagers
CraftBukkit Changes:
0cd8f19f #802: Add methods to modify despawn delay for wandering villagers
d5c5d998 SPIGOT-6362: ConcurrentModificationException: null --> Server Crash
8c7d69fe SPIGOT-5228: Entities that are removed during chunk unloads are not properly removed from the chunk.
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
Bukkit Changes:
5b289e69 SPIGOT-5778: Added World.getGameTime method
CraftBukkit Changes:
d97d91871 SPIGOT-6347: Nether Portals Default to Nether, even in Nether
8aa6a953f SPIGOT-5778: Added World.getGameTime method
Spigot Changes:
73fb6094 #107: Add async catching to chunk entity add/remove
This fixes a confusing issue where doing 'merchant.setRecipes(merchant.getRecipes());' would clear the merchants recipes, as the implementation of getRecipes is guavas Lists.transform wrapped in Collections.unmodifiableList, and the implementation of setRecipes clears the backing list before adding the elements of the provided list to the backing list.
The javadoc for the getRecipes method says 'an immutable list of trades', so this patch makes the javadoc correct.
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
Bukkit Changes:
315b69c1 SPIGOT-6349: Material#MOSSY_COBBLESTONE incorrectly claims it is a MultipleFacing block
CraftBukkit Changes:
a82b21297 BUILDTOOLS-569: development maven profile fails build on windows
Spigot Changes:
cd23533a Rebuild patches
this is no longer attached to anything, and from a glance it looks like
the point at which this information is set has moved to a place which wouldn't
fall in line in a way that we could re-implement these without breaking vanilla
behaivior
Also, just noticed that we apparently need to give our own javadocs some love
at some point
