Cost is a property of individual enchantments, and is used by vanilla in combination with environmental aspects like tool enchantability and bookshelf count to determine the final cost of an enchantment as shown in an enchanting table.
Having access to the base cost of an enchantment using these vanilla methods can allow plugin developers to determine the "value" of an enchantment, and use it in custom logic where needed. I came across this recently when trying to assign an economic value to enchantments during tool repairing, and noticed these values don't seem to be obtainable under the current API.
* Add predicate for block data when raytracing blocks
* Match based on block, instead of block data
* Use instanceof instead of casting
* Use Position instead of Location, add overload for rayTraceEntities
* Implement requested changes
* Invert predicate
* Cleanup
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:
19830133 PR-925: Add hit entity/block to events extending ProjectileHitEvent
CraftBukkit Changes:
5a72c3c04 SPIGOT-7510: Try to fix broken reflection usage of plugins
6fa69f235 PR-1281: Add hit entity/block to events extending ProjectileHitEvent
224f733ac Fix NPE introduced in #f4d977e
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:
897a0a23 SPIGOT-5753: Back PotionType by a minecraft registry
255b2aa1 SPIGOT-7080: Add World#locateNearestBiome
ff984826 Remove javadoc.io doc links
CraftBukkit Changes:
71b0135cc SPIGOT-5753: Back PotionType by a minecraft registry
a6bcb8489 SPIGOT-7080: Add World#locateNearestBiome
ad0e57434 SPIGOT-7502: CraftMetaItem - cannot deserialize BlockStateTag
b3efca57a SPIGOT-6400: Use Mockito instead of InvocationHandler
38c599f9d PR-1272: Only allow one entity in CraftItem instead of two
f065271ac SPIGOT-7498: ChunkSnapshot.getBlockEmittedLight() gets 64 blocks upper in Overworld
Spigot Changes:
e0e223fe Remove javadoc.io doc links
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.
