[Addon v1.115.304 for MC 1.5.1/1.4.7] OreDupeFix 3.1

Do you use IC2 with lots of other mods and get annoyed by the redundant yet equivalent items?

Well I was. Sure, the duplicate items are interchangeable in recipe inputs thanks to the Forge Ore Dictionary, but they don't stack and clog up your inventory. Wouldn't this be nicer:

One item for each type. How would this be possible? Disabling ore generation for the other mods reduces the problem somewhat, but is not a complete solution – mods will continue to output their own item types. For example, IC2 will output IC2 copper when smelting dust, RedPower2 will output RP2 copper when crafting nuggets, other mods will output their own items:

With OreDupeFix installed, all the outputs are consistent:

Much better eh?

In this example, everything is switched to use RedPower's copper ingots, but you can choose the items from the mods you prefer in config/OreDupeFix.cfg. Any items in the Forge ore dictionary are supported. Want the IC2 macerator to output Thermal Expansion pulverized copper instead of dust? After all, they are interchangeable.

OreDupeFix can be easily configured to use the item from any mod. Here's a sample configuration:

PreferredOres {
S:ingotBronze=IC2
S:ingotCopper=RedPowerBase
S:ingotSilver=RedPowerBase
S:ingotTin=RedPowerBase
S:dustBronze=ThermalExpansion
S:dustCopper=ThermalExpansion
S:dustGold=ThermalExpansion
S:dustIron=ThermalExpansion
S:dustSilver=ThermalExpansion
S:dustTin=ThermalExpansion
}

Compatibility
OreDupeFix currently supports editing the following recipes:

• Crafting recipes: shaped, shapeless, Forge ore, IC2 advanced
• Furnace recipes: normal and metadata-sensitive
• Dungeon loot
• IC2 compressor recipes
• IC2 extractor recipes
• IC2 macerator recipes
• IC2 scrapbox drops

Limitations (may or may not be addressed in the future):

• Does not yet replace other machine recipes from other mods (any suggestions, let me know)
• Does not completely remove the redundant items from the game (can still be spawned in, or in existing inventories)

Change Log
2013/04/25 3.1
* Update for compatibility with IC2 1.115.304+
* Use srgnames for reflection to improve mod compatibility
* Improve output formatting for dumpOreDict

2013/03/30 3.0
* Update for Minecraft 1.5.1, Forge 7.7.1.622, IC2 1.115.268
* Now built as a "version-independent" mod (srgnames)

2013/03/10 2.0-1.5
* Update for Minecraft 1.5 prerelease

2013/03/09 2.0-1.4.7
* Add all ore names to generated default config for easier custom configuration
* Add support for disabling recipe type replacements in config
* Add more defaults to default config
* Allow running even if IC2 recipes cannot be replaced
* Blank preferred ore entries will now be ignored
* New build process using SpecialSource (for development; no end-user visible change)

2013/02/01 1.4
* Fix replaced stack size (e.g. crafting copper block -> 9 ingots)
* Add default silver ingot preference set to RP2
* Add IC2 scrapbox replacements
* Add dungeon loot replacements
* Add verbose config option

2013/01/31 1.3
* Initial public release

Downloads

Source code (BSD licensed): https://github.com/agaricusb/OreDupeFix

All released versions: https://bitbucket.org/agaricusb/oredupefix/downloads

Development builds: https://buildhive.cloudbees.com/job/agaricusb/job/OreDupeFix

Latest releases:

3.1 for Minecraft 1.5.1 + IC2 1.115.304+:https://bitbucket.org/agaricus…nloads/OreDupeFix-3.1.jar
2.0-1.4.7 for Minecraft 1.4.7 + IC2 1.115/112: https://bitbucket.org/agaricus…/OreDupeFix-2.0-1.4.7.jar

Quote from Sinnaj63

A good idea, but a old one. For example, Gregtech Unificat to RP2, too. But at least chaoschamp will like that.

Indeed, this addon itself is also fairly old; had it working about a month ago but was busy working on other more important mods so I only just now got around to doing a proper release. Couldn't find anything like this at the time, but now I see GregTech has a similar feature, and digging further, also found the OreGenDictionary (though it appears to have only replaced blocks generated in the world, not items). Are there any other similar mods out there you're aware of? I'm always interested in other solutions.

Quote from GregoriusT

Ahh, someone makes his own OreDIctUnification Mod. GregTech does that too. I even provided an API-Call for Mods like Thermal Expansion to unificate their Outputs (probably next TE-Update), so that I dont have to hack everything (even though the hack is still a Config Value, until TE updates to my Unification-API).

Very cool, haven't yet tried your mod but I definitely plan to, looks awesome, if I end up using it and it has comparable functionality I may end up abandoning my addon in GregTech's favor. Although I suppose it could be useful to maintain OreDupeFix separately as an standalone addon (currently it requires IC2, however, but I could change this if desired).

Quote from GregoriusT

Due to the hackish Ways of implementation for this kind of Feature, I strongly disrecommend to use this Addon together with GregTech at all. I highly appreciate the Idea of doing this, but your Mod will cause Problems, when other Mods are doing the same.

I will probably detect this Addon and throw an Exception, if its installed. Not because I dislike it (I really like it), but because of the incompatibility it causes with my (and your) Unification, making our unification itself useless.

I just want to underline, that I really like the Idea behind this Addon (I implemented that Feature myself before, so why shouldnt I like it?), its just the incompatibility it causes in conjunction with other Mods, which have the same Feature, which is my Problem.

If there's anything I can do in OreDupeFix to make it compatible, I'm open to suggestions. It is highly configurable, in that an empty 'preferred ores' dict will change nothing and cause no incompatibilities, leaving it up to the user to choose the oredict items they wish to replace, but I include a default config as to make it useful out-of-the-box.

Ideally, I think this 'unified output' functionality we're both including should be part of Forge, in some manner. The Forge ore dictionary goes a long way to ensure compatibility between mods, but it only goes halfway, dealing only in recipe inputs rather than outputs. Maybe your Unification API could be integrated into Forge? If the fundamental problem could be fixed at the source, one-off hacks like OreDupeFix would be unnecessary.

Quote from GregoriusT

Because it doesnt do that automatically, and it doesnt eliminate the wrong Items. My OreDict-Unification is also supported by my Autocrafting Table, to prevent anything wrong from being outputted (and to convert Ores/Dusts/Gems etc automatically). With the Forge Lexicon, you have to do that manually, and that is already possible using Nuggets, Storage Blocks or tiny Piles of Dust (what is generally a PITA to do).

Exactly; the Forge Lexicon is another attack on this problem from a different angle, but IMHO replacing the items as in GregTech and OreDupeFix is a cleaner solution for a number of reasons. Not only is the Lexicon manual, but it lets you choose any oredict-equivalent output, even though there's really no reason why you would want more than one type of item if they are truly equivalent (and if they're not, then the conversions could be considered an exploit – so the latest version only whitelists ore, dusts, and ingots). I'd rather not even know the other item types exist, it should all be automatic..

Quote

agaricus: I saw the removal of wrong Items from the ItemList in your TODO-List. That won't work at all, and would break everything, especially when Mods are using Meta-Items for their Dusts (TE, RC, GregTech). It already breaks things if you remove Items from the OreDict, guess what happens if you remove the whole Item!

Yeah, that was my original approach, hit some serious problems. A base edit to the ItemStack constructor to forcibly replace all newly-created stacks with the unified oredict item *almost* worked, but since various mods initialize their items in different phases (TE in @Init, IC2 in @PreInit, so even editing the mcmod.info priority was ineffective), the replacement item was not always available at the time each mod initialized. Didn't get far enough to look into replacing the valid subtypes, but the dupes in NEI still annoy me.. there's has to be a workable solution to this problem, somehow.

Quote from mak326428

ingotSilver between TE and RP?

I mean config-option

You can add any oredict item in the config, if you want ingotSilver to use RedPower2:

S:ingotSilver=RedPowerBase

But I just added this in the default config in 1.4.

Quote from narc

I'm too tired at the moment to make the change myself, else I'd make you a pull request, but when assigning the new output ItemStack, you should really make sure it has the same .stackSize as the original output. I don't think players like it when their copper block uncraft to a single copper ingot, even if it is the correct variant thereof.

Good catch. Fixed in 1.4.

Quote from Quintine

I like this, Something so you can get similar results without GT, because no matter if you run with or without this is a problem that used to drive me insane.

Thanks.

New version of OreDupeFix released:

2013/02/01 1.4
* Fix replaced stack size (e.g. crafting copper block -> 9 ingots)
* Add default silver ingot preference set to RP2
* Add IC2 scrapbox replacements
* Add dungeon loot replacements
* Add verbose config option

Quote from mak326428

Got crash:
java.lang.NoSuchMethodError: wj.getMetaSmeltingList()Ljava/util/Map;
Forge: 6.5.0.489 (Installed via MultiMC, seems to be latest Forge for 1.4.6), IC2: 1.112.170-lf

In OreDupeFix 2.0-1.4.7 you can now set "B:replaceFurnace=false" in config/OreDupeFix.cfg and it should fix this crash on 1.4.6 (B:replaceFurnaceInsensitive can be left enabled, but the metadata-sensitive recipe replacement relies on API added in Forge for 1.4.7). Alternatively, upgrade to Minecraft 1.4.7.

Quote from GregoriusT

I have also a highly Configurable Unification, but only for certain Mods as I cant control everyones Mods. We are both doing the same thing, it would not make sence to install both Mods. Maybe you could just detect the GregTech Addon, and then do nothing.

I suppose conflicting mod detection and disabling could be added, but I'd prefer to only add if its really necessary.. I agree, most people will probably not install both mods. If they somehow accidentally install both and get confused with the results, well, that's a corner case probably not worth coding for :). Although you actually can use ODF with GT (not to say its a good idea, but maybe there are some cases where it would be useful), I'm testing with it now – to avoid overwrites, the configs can be tweaked appropriately; its really up to the user.

Quote

Good Idea.

I look forward to your pull request =)

Quote

Believe me, this will not work. Many Mods use a Hash System of Item ID's and their Metadata for their Recipes. It would break all these Mods, as you cant hack those HashCodes.

Maybe the hashCode could be overwritten using a coremod? Not sure, probably would be fairly complex to implement, haven't looked into it further at all. I think getting it into Forge would be the best scenario. I see there's now a global object registry in FML for the 1.5 prerelease, maybe it could be involved somehow?

Quote

How exactly did you do that? My way of doing it, is removing the WHOLE LIST of Scrapbox Items in preInit adding one Scrapboxdrop to the List (to not let others Crash) and then in postInit I'm adding the correct (and partially nerfed) Outputs.

Since the IC2 API returns a copy of the list, I had to hack into the internal ItemScrapbox.dropList and replace it using reflection:

List dropList = ItemScrapbox.dropList;




            // 'Drop' inner class
            Class dropClass = ItemScrapbox.class.getDeclaredClasses()[0];




            for (int i = 0; i < dropList.size(); i++) {
                Object drop = dropList.get(i);




                ItemStack output = ReflectionHelper.getPrivateValue((Class<? super Object>)dropClass, drop, 0);




                ItemStack newOutput = getPreferredOre(output);
                if (newOutput == null) {
                    continue;
                }




                log("Modifying IC2 scrapbox drop, replacing "+output.itemID+":"+output.getItemDamage()+" -> "+newOutput.itemID+":"+newOutput.getItemDamage());
                ReflectionHelper.setPrivateValue(dropClass, drop, newOutput, 0);
            }

Btw, this mod is open source, feel free to check out (and borrow any useful bits if you want): https://github.com/agaricusb/O…efix/OreDupeFix.java#L397

Quote from narc

Now if only we could convince people to put their [metal] blocks in the ore dictionary, we could unify those, too (as I don't think it would be appropriate for OreDupeFix to register them).

For what its worth, in my testing for 2.0-1.4.7, noticed some mod(s) are now registering metal blocks: https://gist.github.com/agaric…ed1c1139994/gistfile1.txt

Quote from narc

It does if you configure it... just like the OP says. Here's the relevant section of my own config:

Thanks, I borrowed some of these for the latest default config (but I kept ingotTin, copper as RedPower, since reclaiming ores in the Alloy Furnace always gives RedPower ingots, and I have not found a way to easily change those).

Quote

Agaricus, a recommendation: when generating the config, add blank values for everything in the ore dictionary you don't have a default for, and ensure that when read, they behave as "don't unify". It's easier than dumping the ore dictionary and digging through the FML log.

Good idea, just implemented this. The generated config will have a line for each ore name, and blank will be ignored.

OreDupeFix 2.0-1.4.7 now available, linked in the first post. Changes:

2013/03/09 2.0-1.4.7
* Add all ore names to generated default config for easier custom configuration
* Add support for disabling recipe type replacements in config
* Add more defaults to default config
* Allow running even if IC2 recipes cannot be replaced
* Blank preferred ore entries will now be ignored
* New build process using SpecialSource (for development; no end-user visible change)

Also built an experimental version for the Minecraft 1.5 prerelease, available for testing: https://bitbucket.org/agaricus…ds/OreDupeFix-2.0-1.5.jar . Successfully loads on Forge 7.7.0.562, but of course, I can't test it much further until the other mods update =)

Quote from Mister_Omega

Just to get this straight, ODF basically "forces" mods that implement ingots and dusts that have entries in the ore dict to swap to the 'whitelisted' ingots when certain recipes and/or machines are used (fe. RP's copper nuggets result in IC2 copper ingots if IC2 copper ingots are the 'whitelisted' ingots). Right?

Pretty much. Although note the crafting and furnace recipes changes operate beneath the mods, which is why they work with anything (e.g. RedPower crafting recipes, Project Table, Blulectric Furnace). Mods adding their own recipe types for their own machines (as in IC2) have to be special-cased, however.

Quote

In the case of GT and ODF conflicting when it comes to differing unification targets, wouldn't it be possible that in that corner case, the two mods can communicate and synchronize their unification targets?

Not sure how this would work exactly, what do you have in mind? If both GT and ODF are overwriting the same recipe, one has to take priority.. currently this "priority" can be set in their respective config files (enabling/disabling GT unification targets, and ODF enabling/disabling PreferredOres and replacement types).

Quote

And considering the problem I read above about the problem with the RP Alloy Furnace, I know it would be buggy as all hell, but couldn't you override the offending AF recipes?

Yes, and this would actually be technically very easy. The RedPower2 alloy furnace must somewhere somehow store its list of recipes, so its a simple matter of identifying the correct data structure in RP then modifying it appropriately. Should work fine and the same technique could be applied to many other mods adding their own machines, but...

Quote

I do realize that it would be considered stepping on Elo's toes, it's either that or talk to someone who is in direct contact with her and they forward the request to her.

Exactly, this is the barrier. Not going to reflect into Eloraam's code without her permission. Maybe something to consider for 1.5 once RP2 is updated, but honestly I'm holding out for a better solution which doesn't require this kind of mod-specific code (either modifying the items at a lower level, which may or may not be practical, or something higher-level in Forge itself to avoid the duplicate ore problem entirely - maybe this new FML findItemStack API or similar?). Fortunately IC2 has a fairly liberal reverse-engineering policy so it was the perfect proof-of-concept for this mod. For now, to workaround the problems in editing RP2 Alloy Furnace recipes I've set the default copper/silver/tin ingots to RedPower's (and IIRC GregTech does this too probably for the same reason). Anyways:

OreDupeFix 3.0 now available:

2013/03/30 3.0
* Update for Minecraft 1.5.1, Forge 7.7.1.622, IC2 1.115.268
* Now built as a "version-independent" mod (srgnames)

https://bitbucket.org/agaricus…nloads/OreDupeFix-3.0.jar