EnchantableBlocks
EnchantableBlocks (formerly EnchantedFurnace) adds effects for enchantments on blocks! Currently only furnaces are supported.
Get It Now
Builds are available on BukkitDev or in the releases.
Development builds are available for use at your own risk on AppVeyor in the Artifacts tab.
Features
Per-World Focus
All features are configurable per-world. Want an OP world? Not a problem. Want to disable blocks for a vanilla world? Absolutely. All block settings can be controlled by per-world overrides, falling through to default values when not specifically configured.
Enchantment Table Enchanting
EnchantableBlocks offers vanilla-style enchantment table usage for supported blocks. Disable certain enchantments, determine your own conflicts (i.e. silk touch/fortune), or modify enchantability either globally or for a specific world set.
Permission can be granted or denied per-implementation or as a whole. More specific overrides always take precedence.
Nodes are available as follows:
<plugin name>.enchant.table.<block name>
- Permission to enchant a specific block implementation by a plugin in an enchanting table
- Ex:
enchantableblocks.enchant.table.enchantablefurnace
- Note that this is not per-material! I.e.
enchantablefurnace
covers 3 material types.
<plugin name>.enchant.table
- Permission to enchant all block implementations by a plugin in an enchanting table
- Ex:
enchantableblocks.enchant.table
<plugin name>.enchant
- Permission to enchant all block implementations by a plugin in any enchantment source
- Ex:
enchantableblocks.enchant
Anvil Enchanting
EnchantableBlocks offers vanilla-style enchantment and combination for supported blocks in anvils. Supported blocks can be combined with either a matching block or an enchanted book to increase enchantment levels. Uses vanilla combination rules - higher level takes precedence, equal levels yield an increase of 1 level up to the level cap. The enchantment level cap is configurable per-enchantment. Enchantments can be disabled to prevent transfer, though this won't remove them from the base item. Conflicts are also determined separately for maximum configurability.
Permission can be granted or denied per-implementation or as a whole. More specific overrides always take precedence.
Nodes are available as follows:
<plugin name>.enchant.anvil.<block name>
- Permission to enchant a specific block implementation by a plugin in an anvil
- Ex:
enchantableblocks.enchant.anvil.enchantablefurnace
- Note that this is not per-material! I.e.
enchantablefurnace
covers 3 material types.
<plugin name>.enchant.anvil
- Permission to enchant all block implementations by a plugin in an anvil
- Ex:
enchantableblocks.enchant.anvil
<plugin name>.enchant
- Permission to enchant all block implementations by a plugin in any enchantment source
- Ex:
enchantableblocks.enchant
Enchantments
Furnaces
See the wiki for furnace enchantments.
Videos
A basic overview of features is available from shop1126.
Alternate English video courtesy of MusicTechnician.
Portuguese video courtesy of AbsintoJ.
Thank you all!
Permissions
- Please refer to the wiki.
Config
- Please refer to the wiki.
Hello! Thanks as always for keeping this one going. Our players love it. Trying to figure out something in 1.18.1, though, which happened occasionally but very rarely in 1.17, but now multiple times a day. The issue doesn't seem to be in placing the block - the furnaces themselves seem to work quite well. Instead the issues arise when breaking the block - many are completely losing all enchants. This happens even after warning players not to quickly place and break, which we don't think they're doing (at least not in the number who are having trouble). The issues seem to occur regardless of added item names or additional lore, but it does seem to affect those more frequently. I'm not seeing any errors. Any suggestions?
Currently on git-Paper-99 (MC: 1.18.1). Thank you!
In reply to mercurialmusic:
Not sure unless Paper has broken block drops again or another plugin is interfering. There's no difference internally for lore and names as far as this plugin goes, the users probably just care more about fancier furnaces and notice issues faster.
Paper changed how drops work to fix an issue with beehives that had the side effect of causing furnaces and other blocks with inventories to not drop their contents when replaced. The problem is that Spigot still does drop contents when the block is replaced, so the old way of dropping the item either would delete the items in the furnace on Paper or duplicate the items in the furnace on Spigot.
My current solution is to remove the block's data I have stored, store the correct item for the location, and when the block fires an event for dropping an item (which should occur immediately afterwards in the same tick), drop the correct item and attempt to locate and remove the default drop. The only way I could see this failing is if one of the events involved is cancelled by another plugin - as far as I'm aware individual worlds still tick on the main thread even if chunk loading is now async, so the cleanup task should not have an opportunity to run.
It'd be cool if you could add custom base smelting time per item type.
In reply to fulbi0:
You can do that with a vanilla datapack. No interest in rewriting a vanilla feature from scratch, sorry.
In reply to Jikoo_K:
Didn't know that, thank you.
I wrote both POTATO and BAKED_POTATO on the config blacklist, and luck applies as it is. In this case, how do I fix it?
In reply to 굿판타:
Per #276, the correct default config is not created in the current release. You are likely editing the wrong configuration section, please manually update your config.
For some reason it's not generating the config file (I've tried both reloading and restarting the server). I'm on paper 1.17, any idea what could be causing this?
In reply to sir_y0ink:
Without server logs, no. Check your logs on server start for errors. If you see something like "invalid plugin" try re-downloading the plugin, the file is probably corrupted.
In reply to Jikoo_K:
There're no errors, and I tried re-downloading before posting my previous commenting. It could be the way stuff downloads on the browser I use, I'll try chrome.
Edit: It created the plugin folder but not the config file
In reply to sir_y0ink:
Ah, looks like I accidentally removed the default config save on load while I was reworking the configuration for 3.0. You can find the defaults here. Unfortunately, you'll have to create the config.yml yourself and paste in the contents. I am on vacation for the next week and will not be around any computers, so my hands are tied.
In reply to Jikoo_K:
Alright, I debated trying that but I didn't know whether or not that would just mess it up further or not but I guess it makes sense.
hello
since the 1.17 came out, the fortune enchantment dosent work with raw iron and raw gold, it only works with food like chicken, porkchops etc.
Jikoo_K, pls fix
In reply to Jahmai_W:
Edit your configuration. If you bothered to read the changelog you'd know that raw metals are included in the default exclusion list to prevent users double dipping in fortune by using a fortune pickaxe and fortune furnace.
Hey Jikoo_K! With the upcoming changes in 1.17 I hoped to put a bug in your ear about the (hopefully) next update, and wondered if it'd be possible to include equations in the config especially for the fortune output? Or otherwise perhaps some tweaks to it to balance since the new ores will themselves be affected by fortune. We're a little worried about output being dramatically increased and inflating the economy.
Thanks as always for the consideration and for your hard work!
In reply to mercurialmusic:
While I get that not being able to configure the formulas can be limiting, it does follow vanilla's fortune system, which you also can't configure. To allow configuration I'd have to bundle in another library to handle parsing equations, which is a lot more work than you might think - finding a decent library is pretty difficult. Is it open source? Is it easy to use? Does it support all the expressions I think users might want? Does it have a permissive enough license for me to bundle it with minimal legal hoops to jump through? Is it a small enough library that it won't hugely inflate download size?
If I were to allow configuration I would surely need to allow it on a per-recipe level, but the options for doing that are either inefficient and laggy or not user-friendly.
Consider adding raw copper/iron/gold to the fortune blacklist once the material names are locked in to prevent users double dipping with fortune. I'll probably add those to the default list when the time comes.
In reply to Jikoo_K:
Yeah, that makes sense, and a simple enough solution with the blacklist. Thanks for taking the time to explain that.
In reply to mercurialmusic:
With the addition of the library loader to Spigot for downloading libraries from Maven Central, this is something I'm willing to consider again in the future as that's one of the big blockers removed. Still unlikely to happen soon (which knowing my current rate of free time investment means it could be years out) but it's no longer a hard "no" response.
In reply to Jikoo_K:
It wasn't exactly a well thought out request either. I had forgotten about the fortune blacklist, which I think is a perfectly fine solution. I'm sure some would still appreciate the added control, but I'm perfectly fine with what we have.
And thanks for the update! I noticed the supported version for 3.0.0 only included 1.17 -- I take it this would not work on 1.16.5?
In reply to mercurialmusic:
Min version is 1.14 for required API additions. Pretty much nothing changed between 1.16 and 1.17 (the actual update to 1.17 was literally just default config changes and declaring a required library that the server already provides, just doesn't expose) but I don't bother tagging versions I don't test unless the plugin is very version-specific (i.e. OpenInv).