NotEnoughItems Unofficial 1.7.10

NotEnoughItems Unofficial 1.7.10

436k Downloads

Support for NEI Recipe Handlers and other mods that add stuff for NEI.

MagmaBro123 opened this issue ยท 10 comments

commented

Title. Most other NEI tabs by other mods show up as unknown, unlike in normal NEI.

NEI GTNH 2.3.19, CodeChickenCore GTNH 1.1.6.

2022-12-30_00 16 28
2022-12-30_10 18 51

commented

There are two ways to do this. The preferred way is for the other mod to register the Catalyst and Handler with NEI via IMC. An example from good generators is available here

The other method, generally only for mods that aren't still being developed, is for you (or someone else) to submit a PR with edits to handlers.csv and catalysts.csv in the NEI repo here

commented

im unsure if that is a possible thing and if it even going to be done. I assume that this is done by NEI but there are things that can allow for other mod developers to use to add them. Just a hunch but I wont count on it unless im wrong

commented

Most of these mods are dead, so these will never happen, unless its done on NEI's side.
I'm not a mod dev, and have no clue what PRs are, nor how to code.

commented

The problem with NEIRecipeHandlers is that every tab is under the same name, and path.
There's nothing with catalysts or handlers to differentiate them, unless I'm not understanding something about how they work. So, if you try to make one have an icon, all of them have that icon.

commented

You need to add a HandlerID (via getOverlayIdentifier) to differentiate different tabs from the same class.

GT5u uses the same handler class, but has each recipe handler return a different getOverlayIdentifier. NEI looks up the handler by handler name, and id.

        if (handler instanceof TemplateRecipeHandler) {
            handlerID = handler.getOverlayIdentifier();
        }
    public String getOverlayIdentifier() {
        return this.mRecipeMap.mNEIName;
    }

image

commented

It registers multiple instances of the same class multiple times. It only has a unique memory address for each instance that isn't persistent, or consistent across runs.

Might be possible with the ordering that they're registered in, but honestly the "correct" solution is to have a unique identifier returned from the base mod, like gt5u does.

I'd review and probably accept the PR if someone wanted add support for the tuple HandlerName, RegisteredOrder; but no plans to implement it myself.

commented

This is the problem:
2023-01-01_05 09 27
2023-01-01_05 09 35
2023-01-01_05 09 37

Fixing it seems like it would need changes to the mod itself, unless there's an alternative here?

commented

NEI needs a way to differentiate the tabs. If it uses the same HandlerName for all, it's got the problem you've identified. That's why I also added in HandlerID. Some mods use a different class for each tab, which is easy. Some mods use the same one, in which case a secondary identification is needed to differentiate them.

Unless you can think of another way to differentiate them, I can't think of anything that doesn't involve changes to the base mod itself. In which case I'd also recommend adding the IMC handler.

commented

Well, NEI's able to tell the tabs apart somehow. Maybe if they were given a simple numeric identifier under the mod's path when they're registered?
It wouldn't be the most reliable, probably unstable between mod additions/removals, but it would be something.
Or, since they've got unique names, if you were able to use those as the identifier, at the cost of not being able to rename those tabs?

commented

Actually the author of the mod seems to be working on this CraftedMods/nei-recipe-handlers#48 (comment)