closes#6096
boundedIntAuto automatically calculates the correct number of bits to use based on the given bounds. The bounds must be constant, of course.
this makes it marginally faster, since we can skip all permutations containing invalid type data.
I measured a performance improvement of about 20% across all blocks.
In addition, this makes it easier to locate where a problem is coming from if invalid inputs are accepted.
I'd prefer a smarter solution for this that automatically disables updates depending on which type of property was changed, but for now, this will significantly improve the performance of cactus farms.
The newly placed cactus block at the top cannot have updates disabled, though, since it needs to check its surroundings in case it grew into a space with a solid block next to it.
Thanks @KingOfTurkey38 for bringing this to light.
Added StaticSupportTrait for blocks which require unconditional support
dynamic support requirements, such as those presented by item frames and torches, are not included.
in addition, double blocks, such as tallgrass, small dripleaf and doors, do not cooperate well with this, so they are also not included.
some blocks which could be migrated (such as chorus plant) were skipped due to unresolved problems.
Previously, we were using codegen to support describing a fixed set of enums.
Instead, we implement an enum() function, allowing any native PHP enum to be described.
All enums used in runtime data have been migrated to native PHP 8.1 enums in minor-next to facilitate this.
This implementation:
- is faster (in extreme cases by 40x, such as with PotionType)
- requires way less code
- does not require a build step
- is way more flexible
This fixes#5877, increasing the range of stuff that plugins are now able to do.
EnumTrait enums are not supported, as it's easier and cleaner to just support native enums. Most core EnumTrait enums have been migrated to native enums by now to facilitate this.
'enchant' just didn't feel right, being a verb.
All these things pertain to the act of enchanting.
This is now also consistent with CraftingTransaction etc. The ship already sailed on EnchantInventory, which will have to be renamed at a later datte. However, that was already inconsistent with 'enchanting table', so that's the odd one out here.
Perhaps this and EnchantOption should be called EnchantingHelper and EnchantingOption respectively. The terminology used is rather inconsistent, but 'enchantment' definitely isn't the right word here.
this was originally submitted by #6000, but considering the overcomplicated PR and the triviality of the feature, I figured it would be quicker to do it myself instead of having a bunch of back-and-forth bikeshedding over it.
closes#5936
This implements all of the basic activation logic for pressure plates.
It also introduces a PressurePlateUpdateEvent, which is called in pulses when entities are standing on top of the plate and when it deactivates. Deactivation can be detected by checking if the list of activating entities is empty.
---------
Co-authored-by: Javier León <58715544+JavierLeon9966@users.noreply.github.com>
