Workaround Axe Enchantments on Paxel by Checking an Axe

[ChampionAsh5357]

Closes #7860

Changes proposed in this pull request:

Allows the paxel to have axe enchantments by checking whether the enchantment can be applied to an axe. I opted for this solution compared extending AxeItem since that class assumes the tag is MINEABLE_WITH_AXE while paxels have their own tags. This would mean that all of the logic associated with the tag would need to be replaced and swapped out. In favor of avoiding redundancy, it is simpler to just check whether the item is an axe item.

Modded enchantments should check whether the action can perform AXE_DIG, so it should remain compatible.

As this is a workaround, this should work until the mod loader API switches out the enchantment logic for checking tool actions instead.

[pupnewfster]

The one issue with this solution is I believe sharpness is allowed on axes but only via enchanted books and not via the enchantment table. Or at least there was something like that when I looked into it some. Now I don’t know how much that actually matters but definitely needs some more thought. Cc: @thiakil

[thiakil]

Can we use enchantment.category.canEnchant(AXE_item) instead? (preferably with the paxel's normal axe version)
I'm not a fan of making an itemstack here

Re sharpness: on a quick glance look like the methods an anvil uses will pass through here by default so should be fine

[pupnewfster]

My point is it works for anvil here but it adds enchantments as possible to the enchantment table that are normally anvil only.

[thiakil]

how so?

[ChampionAsh5357]

Ah, I see what you're talking about. Enchantment#canEnchant is what's used to check whether the item can be enchanted with that instance at all while Enchantment#canApplyAtEnchantingTable checks only if the logic can be applied at an enchanting table. #canEnchant calls #canApplyAtEnchantingTable.

So, this would probably need to be addressed in NeoForge as a way to disambiguate the two. Otherwise, the only solution I could think of to maintain the logic is to mixin in a check somehow, which wouldn't be very mod-compatible since you revolve. Another solution would just be to say paxels are cool like that and can have the enchantments at the enchanting table.

This is assuming we are still using this method. The safest way would probably just be to extend AxeItem and just override all the tag checks with your own, which is a bit of a logic rewrite, but there's not much to do there.

I'll wait for further opinions before going forward here.

[thiakil]

Which category are axe enchants? (or do they specifically check for axe?)

[ChampionAsh5357]

There is none, it's essentially a hardcoded check in Enchantment#canEnchant within the DamageEnchantment. If anything, they fall under the DIGGER category by default.

[thiakil]

Hmm I see. Ideally a forge fix for being hardcoded would be the way.

Though if you wanna see how it looks with paxels extending axe I'd take a look

[ChampionAsh5357]

@thiakil here you are. It simply just extends AxeItem and changes any indirect checks on the tag to direct ones.

[pupnewfster]

If we are doing it by making it extend the axe we may want to make:

• canPerformAction call super instead of checking the default actions
• Make usOn do something like:

InteractionResult axeResult = super.useOn(context);
if (result != InteractionResult.PASS) {
    return result;
}

And then remove the useAsAxe method. That way we won't have to worry about if mojang adds more features to the axe at some point as it will be handled by the super call.

Also in regards to overriding one vs both isCorrectToolForDrops I don't think we have a choice as in DiggerItem both are overridden to reference blocks rather than passthrough to the less specific variant. Though an alternate solution would be to add an AT in Mekanism Tools' AT file that definalizes and makes blocks protected and then update the tag key that is checked to being the paxel tag.

[ChampionAsh5357]

Ok, I'll get around to it after the 5th since I won't have a computer that can run Java until then.

[ChampionAsh5357]

Okay, I've addressed the comments and added back in the second method for #isCorrectToolForDrops because of pup's comment. I could go for the definalization method if wanted, however.

[pupnewfster]

One more minor nitpick but other than that it looks pretty good (assuming when I test it things work as expected)