'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.
this is a really dumb bug and seems similar to the armor bug I fixed a while ago.
fixes#5987
it's unlikely that #5727 will be solved by this, but one can hope...
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>
if an enchanted book is obtained via /give without enchantments, it should be able to receive enchantments in an enchanting table, exactly the same as regular books.
This is a step towards #5958.
While it's not actually necessary to add these functions (since people could just use getFile() . "/resources/whatever.yml" instead), this helps preserve the convention of using the `resources` folder, which might be helpful for external tools.
As an example:
stream_get_contents($this->getResource("lang/eng.ini"));
(which is actually incorrect, since it leaks a resource)
can now be replaced by
file_get_contents($this->getResourcePath("lang/eng.ini"));
quite trivially.
getResourceFolder() can be used with scandir() to enumerate resources instead of using getResources(), although getResources() still provides utility in the relativized resource paths.
all this time we've been harping at plugin devs to fix their own leaks, and here's one right under our noses that no one spotted for 10 years ...
this leak is rather common, since it will occur whenever a plugin attempts to save a resource which already exists in the data folder.
This bug was introduced in 2014 by commit 63288346814b7b827f1f7cc7a16419af43bd0bfa.