RenderWorldLastEvent for LookingGlass
Guichaguri opened this issue ยท 8 comments
My suggestion would be about creating a RenderWorldLastEvent for LookingGlass views, but after looking at the code, I've seen that RenderWorldLastEvent is fired on LookingGlass views and that could cause rendering issues with other mods.
What you can do for a hacky workaround is setting the listeners field on net.minecraftforge.fml.common.eventhandler.Event to a new ListenerList instance before rendering and setting it back right after. You can also use ASM, but I think you don't want to make LookingGlass a coremod, right?!
I don't see any reason for not having a RenderViewLastEvent, maybe it's because I'm not familiar with the code yet
Well, my goal was a suggestion for a RenderWorldLastEvent event to let mods render whatever they want inside a LookingGlass view.
I was reading through the code and noticed a renderWorld call. If you look into the renderWorld method, it executes renderWorldPass which also fires a RenderWorldLastEvent inside the view. That could cause problems, mainly if the coordinates of the view are the same from the theWorld. (For example Botania, it has a custom particle renderer using RenderWorldLastEvent)
So I suggested two fixes for that: disabling the EventHandler temporary (My code suggestion was not good idea because it disables the whole EventHandler system and could affect the tick based events) or using ASM.
It's a suggestion followed by a bug report
I expect that the solution to this problem will be pretty complex. Thanks for bringing it up. :)
Hopefully a solution can be devised moving forward that works well for those that use the event normally without ASM or otherwise breaking things.
I think, for now, LookingGlass should have "isRenderingView" and "getCurrentView", so other mods can add manual fixes
That sounds like a reasonable midway fix, yes. :) Feel like taking a shot at the PR for it? I'm not sure when I could get to it.
Given the architecture of the API handling, you'll either need to create a new version of that API interface or a new API interface entirely. Once an API interface is included in a release, it can never be modified.
For creating a new version this means making a WorldViewAPI3 which extends WorldViewAPI2 (or repeats the functions, at least), and all the backend stuff to go with that, like the implementation wrapper and registration ("view-3").
For creating a new interface, it's basically the same without the replication of the other API handling. The registration will be something new, then, at version 1. You'd probably still have to model it off of the existing APIs just to see what needs to be done.