[1.8] Why does armor rendering use ItemStack#isItemEnchanted ?

[coolAlias]

I've got an item that I want to have a base enchantment that is just its 'normal' state, so I don't want the enchanted glow to render. Overriding Item#hasEffect(ItemStack) works great for the item (a helmet, btw) everywhere EXCEPT when it is worn, which I have traced down to this bizarre discrepancy:

 

The easily-customizable Forge method Item#hasEffect(ItemStack) which is called by ItemStack#hasEffect is used everywhere except for LayorArmorBase, which instead calls the impossible-to-modify ItemStack#isItemEnchanted.

 

Was this just missed, or is it intentional?

[Bishamonten]

I'm in 1.7.10, I'm coming across the same issue. I was going to ignore it for the time being (because my gf wants to play and not watch me code), but thought I would do some rudimentary research on the matter to see if there was a "quick" fix.

 

I thought I'd post in your thread instead of writing my own.

[coolAlias]

I thought I'd post in your thread instead of writing my own.

Wow, someone who uses search! Thanks for bumping the thread, I'd totally forgotten about it

 

It seems there is no way to fix this other than to submit a PR to the Forge project or open an issue and hope Lex decides to work on it. All it would need to change is line 80 of LayerArmorBase to use #hasEffect(ItemStack) instead of #isItemEnchanted.

 

I tried setting up a Forge workspace before but had some issues. The first time I set it up the code base was somehow 2000+ commits behind master. No idea how that could have happened, as I cloned straight from the master branch. Second time I got the latest commits but there was an error in the build script that prevented the project from setting up or something, don't remember exactly what it was now, as this was over a month ago, but there was a post with the same problem from back in 1.7.10 and the fix was on Forge's end then.

 

Anyway, long story short, due to technical difficulties, I won't be submitting PRs myself anytime soon.

[jabelar]

I have one weird idea that might work as a workaround.

 

I think that the getSubTypes() method is called on all items when they are used on the client. This method provides a list of ItemStacks with quantity 1 for each subtype. I think this may be the source of ALL ItemStacks on the client, since it would make sense that you always need to check subtypes before rendering, creative tab, etc.

 

Now, the problem method in ItemStack() is the isItemEnchanged(). So what if you made a custom class that extends ItemStack that overrides the isItemEnchanted() method to return false? Then in the getSubTypes() method for your custom Item, for the base item return the custom ItemStack and return regular ItemStacks for the rest?

 

Just possibly might work with only a dozen lines of code.

[jabelar]

Hmmm. I guess that makes sense. What if there was code that used a tick event handler to replace the ItemStack in the player inventory with the custom extended ItemStack? The packets of course would not contain this information, but if both the client and server were replacing the ItemStack it might stay synced.

[coolAlias]

#2081

You're my hero