Describe the Suggestion

This request is really long because I had waaaay too much coffee and I can't help make this happen with a pull request, but I can do research for you. I've tried to make short summaries and you can just yeet the extra context if you want, whatever.

TL;DR:

I request EMI gets similar integration to JEI, without needing to also have JEI installed.

Also, a bit of advice: If you get someone complaining that your JEI integration isn't working at all, make sure it's actually JEI. EMI can look similar, and it sounds similar. The quick fix is for them to install JEI, along with their EMI.

Request

I would like to request that EMI gets similarly feature-rich integration as it does with JEI. There are two obvious routes: either through dedicated EMI compatibility classes, or by using TooManyRecipeViewers to bridge your existing JEI compat classes to the EMI API instead. I suggest using TMRV to get quick lazy compat, and then look into dedicated EMI support classes, but you can look at that below if you care. See extra context section for "extra context"

Pain Point This Addresses

TL;DR: No Recipes in EMI makes sad gamer.

There is an existing work-around, but the work-around requires sometimes seriously enormous amounts of RAM, and causes performance problems in any GUI where EMI or JEI integrate themselves. Which is nearly all of them. The performance and RAM problems are not caused by your mod, but by the necessary work-around.

Screenshots and Videos

No response

Additional Context

Oh hey, a separate box for "extra context".

Background Stuff

EMI

EMI is a significant (but much more recent) alternative for REI and JEI. It is available on Modrinth here, and probably on Curseforge or something. It is structurally different and in particular doesn't cause the delay before entering a world - it allows you to enter much quicker, while it works in the background to index (it instead delays access to the recipe manager while you play). This is a huge win for modpacks that add many blocks or new recipe types.

It also allows you to go beyond looking at the just the recipe of an item, to instead creating a whole tree of the recipes of the prerequisites, give you a completely ingredient list, and you can flag an item to make. EMI will then track which ingredients you have, and highlight the ingredients you still need in your inventories. This is another huge benefit for large modpacks, especially the ones with customized crafting or lots of micro-crafting steps. This was the killer feature for myself.

Otherwise it is extremely similar to JEI and REI, all having converged on the same set of very good features for the "recipe viewer" role, and performs them well. They're all slightly but not significantly different, because there's some clear "good and right" features that everyone implemented.

Current Work Around - JEMI

The EMI creator took the extra step of trying to support JEI integration in their mod, which was above and beyond the call of duty IMO. Currently, JEI integration is "emulated" in EMI by also loading JEI (the combination is referred to as JEMI). To do this, both mods are fully installed and loaded, and EMI does Darkest Sorcery to get the JEI mod to send GUI stuff to the EMI GUI and accept events from the EMI GUI, instead of the JEI GUI.

The JEMI configuration forces the creation of two complete registries of recipes, plugins, blocks, items, and whatever else is added by those plugins, which rapidly bloats in modpacks that add lots of blocks, such as decor blocks, requiring more RAM allocation, and for both item recipe registries to be loaded into RAM when any GUI interacting with the recipe managers are opened - like the player inventory, a crafting table, a furnace, almost anything. The JEMI configuration also requires wold-loading to be paused on startup for JEI to do its on things, meaning you loose the EMI benefit of quick world entry. The Darkest Sorcery required for JEMI requires processor activity than using just one API, which also is bad for performance.

It is a pretty clever solution, but a band-aid.

Integration - EMI API

EMI has its own API for mod integration, documented on their Github Wiki. One EMI-specific thing is Recipe Defaults - when there are multiple ways to craft something, this is used to deice which should be used by default in the recipe tree tool. You can also suppress the recipe from the tree tool without hiding it in the item list, possibly you might want this as sifters don't have a guaranteed output and shouldn't be "expected" to provide something? IDK.
Creating a new EmiRecipe doesn't look too bad to me (as a programming bystander), as the API handles catalysts (like is waterlogged, power) and provides helper classes to handle widgets. I don't know how hard it is to use, but it seems to have good features. I don't think any sifting recipes rely on RPM?

Of course this is all extra work classes and learning a new API. But unlike JEMI, you can get EMI support without all of JEI loaded at the same time, and you don't need any other mods.

Integration - TMRV

The final way uses TooManyRecipeViewers (TMRV). TMRV wraps around the EMI API, and impersonates the JEI API. JEI method calls, events, and messages on the event bus from mods like yours are captured and translated to native EMI method calls, events, and messages. If you use EMI + TMRV instead of JEMI, TMRV removes the need to load an entire registry copy for JEI (saving RAM), it eliminates the need to pause world entry while building that second registry, and provides an integration with EMI that needs less CPU cycles. Because it is actually a wrapper around native EMI functions, what it supports is better integrated into EMI.

It has restricted coverage of the JEI API right now, so it just can't catch some kind of requests or handle some kinds of features, and especially has trouble with mods working deeply inside JEI to implement advanced features. It's under development to keep adding coverage, but that's an obvious risk point.

Possible Routs to Implementation###

TL;DR: I recommend you do a quick test against TMRV, and if there's only a little or no work to do, go with that for immediate compatibility. Then make long term plans to include native EMI API compat, while TMRV-based support buys you the time.

This gives you the benefit of lazy-instant-gains and you can think about targeting EMI when you're looking at recipe viewer support in your code anyways.

Background - Implementation pros and cons

These are just My high level analysis, your millage may vary.

• Create a new set of classes against the EMI API, implementing the new recipe type etc natively.
  • Benefits: User doesn't need to install more mods, simpler debugging as you don't have an extra API wrapper inbetween you and the recipe viewer.
  • Problems: You have to add a whole extra set of classes. There may be portable code between the two that can be refactored out into a helper class, but nobody likes adding more maintenance.
• Code JEI integration using only the JEI API methods already-implemented in TMRV. Then test against JEI as the first-class API, then repeat testing against EMI + TMRV (no JEI installed). Whenever you futz around with the JEI integration, rerun the EMI + TMRV test. I'd suggest if TMRV doesn't update for a version you support, just abandon EMI support for that version unless you want to write to its API now.
  • Benefits: You only have to code one set of classes. This means a low bar to entry (and IDK you might be already working great with TMRV with no modifications, so just add it to the testing plan). Makes integration into EMI controllable by the user/modpack developer. IDK why they'd want to remove it, but if they did, they just remove TMRV.
  • Possible Benefit: You could bundle TMRV in the project via Jar-in-Jar. I think, and if the dev agrees. It's just a Gradle change as far as I know, and users won't have to install another mod. Take this point with a grain of salt - I don't know much about JAR-in-JAR, just what other mods devs have said.
  • Problems: Possible implications for JEI support if you were using calls TMRV doesn't cover. If TMRV can't be bundled using Jar-in-Jar, then users need to install a second project. You're dependent on the maintenance of a second project. You have to test EMI integration with an extra layer between you and EMI, making any troubleshooting a little more complex. If you have to do troubleshooting, you might have to learn the EMI API as the TMRV wrapper functions end up in the EMI code eventually anyways.

--

Too much context

If you don't just close the ticket as "Not in scope", this might be useful as a starting point for researching the project and deciding if you even want to. it's less coherent than the main ticket.

Estimated Priority

Overall I would call this a Low-Moderate Priority request. If there was a 1-5 scale where 5 is "deletes my gameworld, corrupts my instance, and calls my mother rude names" and 1 is "typeo in spelling of item in language file", I would rate this a 3 or 2. My reflex is to call it 3, but I'm knocking it down to 2 because of my bias.

The thought process that went into this is as follows.

Symptom Severity: Moderate. Not having the customization show up is bad, but the mod functions and appearances aren't impacted, and there is no save-game impact or cross-mod impact. There is no other reference for recipes (even online) except cracking open the JAR and reading the JSONs, which is A Bit Much for non-developers, and tedious for developers. I even tried giving the JAR to ChatGPT to make a list for a laugh and it apparently can't count that high.
Work arounds: Since there is no other simple reference for recipes, the only work-arounds are installing more mods:

• The simplest solution is to uninstall EMI and install JEI. I rate this sub-optimal because a user probably made a conscious decision to pick the less-famous option.
• The easy to find solution is installing JEI in parallel. The impact of this work-around is modpack bloat, requiring more RAM allocated to the instance, and longer world loading times.
• A more obscure work-around is installing TMRV alongside EMI. You aren't explicitly testing against TMRV, so I would call the reliability of this workaround "fragile".
  Difficulty of discovering/implementing Workarounds: People who chose EMI instead of JEI hopefully already read the mod description to find out why their modded workstation recipes aren't showing up. "Install JEI as well" is well communicated. Finding TMRV is harder, but in either case, you find a mod on popular mod platforms and install it to your instance. No configuration required, drop in (or drop out) solution.
  Reward: Being able to advertise your mod supports both JEI and EMI out-of-the box, which is a good feature (if not world-shattering). Preventing possible issue generation (although as per the work arounds, I'm guessing you don't get many). Improved play experience.

While the symptom is immediately obvious, and moderately interfering to gameplay, it doesn't do any actual damage, and the work-around is pretty easy for a user to find and apply. A user who chose EMI over JEI is probably (one hopes) going to remember that, and think to go back and read the EMI page. I think this because EMI isn't an acronym or contraction; it's hard to find it accidentally before JEI, and bumble into installing it when they wanted JEI instead. Most EMI users will have consciously made the choice to use the alternative, and will "usually" be aware enough to go "Oh, JEI thing doesn't work, I don't have JEI, what do"

Hi!
I'm amazed with your report... thanks so much!
Right now I'm using Create as a base for all my mods JEI integration. It doesn't support EMI and I don't think it will do in the near future.
However I have some issues with my current implementation (leveragin on create) that I want to tackle.

It's easy for me to add all the recipes to the wiki... but many modpacks change them... it's not a viable solution.

Not being able to see the recipes it's kind of critical.

I'm going to study a solution for this problem.

I'm also leaving this issue open to track the progress.

Thanks again for the report.

I'm staring to support EMI directly in the mod. Still some cleanup and testing to do before releasing.