CRAFTBOOK-3332 - Reported by Omanoctoa

Heya!
I was going to report an issue regarding Custom Crafting recipes, so I updated Craftbook to the latest dev version for 1.11.2 (#156). The issue persisted and now I have a second issue.

First, Crafting Recipes. I recall a while ago they worked properly, but I tested tonight and realized (before and after updating) that recipes using custom-lored and named items as ingredients are ignored. Likely the same issue as CRAFTBOOK-2923 (it suggested it to me below).
For example:

    thaumium-chestplate:
        type: Shaped
        ingredients:
            'NETHER_BRICK_ITEM;ARROW_DAMAGE:1|&5Thaumium Ingot ': a
        shape:
        - a a
        - aaa
        - aaa
        results:
            ? 'LEATHER_CHESTPLATE;PROTECTION_ENVIRONMENTAL:10;PROTECTION_PROJECTILE:10|&5Thaumium
                Chestplate|&7Potion Resistance V|&7Bind I|&7Ethereal I|&7|&6Indestructible/color:75,4,189 '
            : 1
        permission-node: thaumium

This works no problem, but my test tonight let players use regular netherbrick items to craft the same enchanted armour...which isn't good. I have many such items using custom crafting recipes, and this would break many of them. The only thing I can think of, is another plugin called Craftinomicon, which displays Crafting Recipes. I'm wondring if perhaps it is not just displaying but also logging the recipes, making them functional. Either way, custom names, lores and enchantments are being ignored.

Secondly, my new issue. The HeadDrops feature is cool but I'm already using the Playerheads plugin and it works just fine, with fine control over each mob's custom head and drop chance. The issue is the /hd alias for the headdrops command that is interfering with HolographicDisplays /hd alias, even though the HeadDrops mechanic is disabled.

Please help!
Omanoctoa

Comment by Omanoctoa

That shoulnd't be necessary - I imagine other players are using that command so removing it may cause them trouble. Is there any way to optionally disable the alias in the config? Or would it be possible to lower the priority for the alias.

Nah I don't use any reload plugins. The server did crash twice earlier this week (yea my bad) but not lately. It's not just that one recipe though - almost any recipe with custom elements appears to be effected. Oddly, a shapeless recipe using the 'Thaumium Ingot' item to create a Block works properly.

I was wondering though, would it have any effect to set up a 2nd custom recipe using the generic item, such as regular netherbrick items for this example, that craft into 8 regular netherbrick items, instead of the armour? Sort of a backwards redundant attempt to override the lored-item recipe.

Comment by me4502

With the command - there isn't a priority system for aliases, so it can't really be lowered. And it's assigned in an annotation so it can't be changed from the config.

I've just tested that specific recipe on my local server and it's working fine. However I tested it on 1.12. I'll try getting a hold of a 1.11.2 jar, however it may have been fixed in 1.12

Comment by Omanoctoa

Hmm...I'll give my other method a shot then. I use a plugin called SimpleAlias that is capable of overriding commands. I'll see if it is able to override aliases as well.

Are the 1.12 releases compatable with 1.11.2 (for the most part)? I only tried the 1.11 version in case the 1.12 version introduced other issues.

Comment by me4502

The 1.12 release isn't compatible for recipes, as 1.12 changed the way recipes work a bit.

Comment by me4502

Also - what I meant by that wasn't that a build of CraftBook fixed it, but that a change in Spigot fixed it.

That part of CraftBook hasn't been changed - the only recipe related thing is they're now given a name - as that's a requirement in 1.12

Comment by Omanoctoa

I figured that. If I recall, they removed the numerical block IDs in exchange for block states. Instead of wool:11 it is now wool_blue...which is great, if you know the item names :D

I can't update to 1.12 yet, sadly, as I need to wait for one or two key plugins to update first.

Comment by me4502

I don't believe that change has been made in 1.12, it's scheduled for 1.13

Comment by me4502

Firstly, for the second issue. Spigot's command system doesn't support conditionally registering commands. So if a plugin has a command, it always has to exist. That's why the command still exists even though the mechanic is disabled (However the command won't do anything). I could potentially remove that alias however, if it's specifically causing a problem.

As for the first. I'll do a bit of testing when I get home. Due to the way the recipe system works in Spigot it can be fairly buggy at times - as it overrides things and doesn't support anything but the item type. Sometimes if a reload plugin is used (Or just /reload), it'll deprioritise plugin recipes and break things. I'll see if I can find out why that specific recipe isn't working correctly however.