Expose some marker interface or way to know if a screen is an EmiScreen

[pupnewfster]

So in Mekanism I have some semi cursed code to workaround an issue with mods that capture the current screen, replace it, and then set it back to the same screen. This is because when Minecraft switches the screens it calls Screen#removed, which in AbstractContainerScreen removes the player from being tracked by the menu (AbstractContainerMenu#removed). In vanilla this doesn't really have much of a behavior as the container menu remove call only does something if it is a server player, but the screen passes the client player; but in Mekanism (and I presume other mods may do similar), we have other cleanup related code that runs when called. To workaround this I basically added a listener to the screen open event, and if it was on my current screen, and is opening a jei screen (IRecipesGui) then I set a boolean, and I don't actually execute the code in my override of Screen#removed). For EMI I currently am doing this, but I would rather have a cleaner way (be it an interface I can check, or even EMI just skipping the removed call yourself if the new screen is going to store a reference to the old one) than me checking the package name.

Version: 1.1.1+1.20.4

[emilyploszaj]

It probably wouldn't be unreasonable to implement a marker interface. As a note though, have you seen EmiApi.getHandledScreen()? It returns the "underlying" HandledScreen (moj!ContainerScreen I believe?) being used for the currently open screen. This would indicate, for non HandledScreens, that an EMI screen is open... though it is a bit roundabout. I'm having trouble understanding exactly what you're doing here and if this would resolve your issue, but I thought I'd point it out.

[pupnewfster]

Unfortunately getHandledScreen isn't of use here. Basically what we do is when we are switching from a mekanism gui to a JEI (or in this case EMI) one:

• we set a boolean when the screen is about to be changed over from the mekanism one
• vanilla calls Screen#removed on the old screen (in this case the mekanism one), but because our boolean is set we skip actually running it
• new screen gets added and the player interacts with it however they want
• player leaves it , and the recipe viewer sets the screen back to the instance it was before, but as the container isn't reinitialized and the screen isn't entirely reconstructed some parts that got cleaned aren't reinitialized

[emilyploszaj]

That makes it clear to me, thanks.

[SGZ-Creations]

So is this what would be the reason to why EMI is closing the UI when using the QIO crafting grid?

Minecraft 1.19.2 EMI 1.1.10 Mekanism 10.3.9.13