Describe the bug
Due to recipes being registered after plugin, causes incompatibity with TMRV for EMI
\/ Reference issue from TMRV explaining problem
Nolij/TooManyRecipeViewers#6

Include a log
https://mclo.gs/6LSlX0D

Other mods
EMI + TMRV

The recipes in this plugin are registered after onRuntimeAvailable for good reason - the multiblock data is read from IE's API, and IE hasn't loaded the required data on the client by the time JEI fires runtime available (this was actually something that needed fixing in #6 after an IE refactor for 1.20) . Therefore we wait until a later part of the lifecycle to register recipes. If EMI / TMRV don't allow recipe modifications later than that point in the lifecycle, then this may be a straight-up incompatible situation.

In the linked issue from TMRV, @Nolij mentions something about blocking onRuntimeAvailable. Are you able to clarify what that means? If there's some way to stop JEI from firing the runtime available until later in the lifecycle that would be great and would allow me to clean up the registration. However, I'm not aware of any way to do that. If by "block" the meaning was to finish registering the recipes before returning from onRuntimeAvailable, that's sadly not an option.

would it just be possible to add emi support? if tmrv doesn't work, maybe emi has it's own system to accomplish this type of thing?

According to the TMRV README this is not a TMRV limitation, but an EMI limitation, as it states the concept of runtime registry changes are incompatible with EMI. I'm not familiar with EMI's API, but a quick scan of the EMI docs doesn't show any obvious way to get around that limitation, so I'm inclined to believe the author of TMRV. They've spent much more time looking into EMI than I have.

I can understand why EMI would not add such a feature to their API from a code design standpoint. However, omitting such a feature is going to limit what plugins can do, and this is one such case. Multiblock data simply isn't available from IE's API by the time onRuntimeAvailable finishes.

I'm going to preface this comment with a note that implementing the following would probably take a lot of work, and I don't want anyone to bother @sguest to do so if they don't want to. It's clearly outside the scope of this mod, which is best described as a JEI plugin, not an EMI plugin.

Upon further reflection, blocking onRuntimeAvailable (by which I meant spam Thread.sleep(100) until the IE multiblock data is available, or something along those lines) would break compat with vanilla JEI, though it would fix the EMI issue (meaning it isn't an option here).

That being said, this shouldn't cause any issues with plugin written explicitly for EMI to the best of my knowledge. I believe the EMI API should be able to consume IE mutliblock data just fine. Runtime registry modification is necessary for implementing this plugin using the JEI API, as JEI does plugin initialization before the world loads. EMI on the other hand does plugin initialization after the world loads (this is not an insignificant part of why TMRV is able to improve loading times so much over JEMI), so I don't think lack of runtime registry modification would be an issue for using the EMI API in a plugin of this nature.

As stated, this requires adding explicit EMI compatibility (or using ugly hacks, such as detecting TMRV and blocking onRuntimeAvailable if it's present, which I wouldn't advocate), which would probably require a fair amount of work. I'm happy to help with doing so if it is something you're interested in doing (feel free to reach out on Discord: @xdMatthewbx#1337), but if you aren't (which again, is very reasonable), it seems users will just have to go without compatibility between our mods for the time being.

Incompatibilities are inevitable in modding. Again, nobody use this information as ammunition for pestering @sguest to add compatibility. Just because something is technically possible doesn't mean it makes sense to do in reality.

Thank you for the info @Nolij. The fact that EMI freezes modification later in the pipeline is good to know. I think that's enough for me to re-open this issue and consider adding hooks into the EMI API as well. I'm not promising anything, but it's enough to move from a hard no to a maybe.