[1.8] Multiple Enchantment Effects

[hystericmarine]

I want to create multiple types of visual enchantment effects (the vanilla purple glow not the enchantments themselves). How would I go about doing this?

 

 

So far I've looked at the RenderItem class and it would seem that the game uses the renderItem method to check if an item is enchanted and the renderEffect method to actually create the effect. I thought could override the renderEffect method but it's private. I tried making my own version of the method but it required a lot more private methods and my file started looking like a mangled mess. I thought maybe I could copy over the whole of RenderItem into my own class but I have no idea how to call that instead of the default.

 

Any help would be appreciated! 

 

 

[RANKSHANK]

Made a PR on this a few weeks back and it got shot down because expansion here is bad for performance.

https://github.com/MinecraftForge/MinecraftForge/pull/2458

 

In short you can't do it easily. Even swapping out the render item instances with your own results in a lot of issues caused by the surplus of private methods and GLState headaches.

 

The other option is ASM- which is frowned upon. I've recently written a class transformer for implementing a wrapper for custom effects that does the job but it's skewed towards shader use at the moment. Thinking about pushing it out as an API to make the handling of effect passes an optional thing if there's the demand for it.

 

[hystericmarine]

Very informative, thank you! Would you have any idea if this mod:

 

 

http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1280263-animated-enchantments-1-0-0

 

 

Implements something similar to what you've done? Or has forge changed? Or is it a more basic modification?

 

EDIT: Just saw that the mod is most likely using ASM. Why is it frowned upon?

[Draco18s]

EDIT: Just saw that the mod is most likely using ASM. Why is it frowned upon?

 

His pull request is a patch.  Its like ASM (uses the same principles) but means that if integrated into the Forge codebase it would be shipped with every version of Forge from then on.

 

ASM is frowned upon for two reasons:

1) There is almost certainly another way to make the change through the event system

2) It is very very easy to make a coremod that conflicts with someone else's coremod

3) ASM will drive you insane trying to learn it

[hystericmarine]

Ok, thanks for answering my questions! Since I'm fairly new to forge modding and Java, I'll stick to more basic/less compatability breaking things. But, if I ever decide to look into this some more I'll have a few places to start.

[Draco18s]

Just stay away from coremods, life will be simpler.

 

ASM is a dark abyss that looks back.

[RANKSHANK]

Just stay away from coremods, life will be simpler.

 

I will definitely back this. Mostly because it's a nightmare starting out with

1) You're dealing with byte code which works on a token stack, totally different approaches

2) Errors are sparse and often difficult to read in comparison to 'normal java errors'

3) Very little documentation to be found on the matter. Took me ages to track down the references I needed for it to click

4) Getting help with it will be next to impossible since it takes a lot off back and forth (effort) to troubleshoot something you're being discouraged from doing anyways

5) You can easily mess something up that will take a ton of debugging to actually present itself as an issue

6) Murphy is lurking