I looked into the issue some more, because I was curious as to why some 'childish' code in MFR could not be removed without causing a problem with GalactiCraft in this case. Now here is the part of the code in MFR 1.6.4 final that was removed in the MFR GT friendly version (IC2.class):
Code:
@EventHandler
+ public static void postLoad(FMLPostInitializationEvent evt)
+ {
+ ItemStack booties = new ItemStack(Item.bootsLeather, 64, 0);
+ Item.bootsLeather.func_82813_b(booties, 0x3479F2);
+ OreDictionary.registerOre("greggy_greg_do_please_kindly_stuff_a_sock_in_it", booties);
+
+ if (Loader.isModLoaded("gregtech_addon"))
+ {
+ for (String str : OreDictionary.getOreNames())
+ {
+ ArrayList<ItemStack> list = OreDictionary.getOres(str);
+ for (int i = list.size(); i --> 0; )
+ {
+ ItemStack stack = list.get(i);
+ OreDictionary.registerOre(str, stack);
+ OreDictionary.registerOre("\ngreggy_greg_do_please_kindly_stuff_a_sock_in_it\n" + str, stack);
+ }
+ }
+ }
+ }
+
source can be found here:
https://github.com/skyboy/MineFacto...s/minefactoryreloaded/modhelpers/ic2/IC2.java
This bit of code (method) should not have anything to do with other mods and certainly should not cause behaviour to change. It is all about bringing a childish message across to GregTech by registering every entry in the Ore Dictionary twice during postLoad with the addition of a message in the naming the 2nd time.
This got me thinking and I checked NEI with and without the method present in MFR. Without the method there is only 3 registry entries for Aluminum (oreAluminum, oreAluminium and oreNaturalAluminum). Smelting ore -> ingots in this case is default behaviour (not recognized by Railcraft or GregTech). Now with the method still present in MFR, NEI shows 9 entries for Aluminum with the 6 extra entries all coming from MFR. Smelting ore -> ingots is disabled by GregTech and alternative ways to process it show.
This means basically that because of the fact MFR registers each entry in the Ore Dictionary twice, Railcraft and GT pick up on that and alter behaviour for recipes/processing by disabling smelting of Aluminum ore from GC. This does not happen without the postLoad method in MFR, so this means that Galacticraft is not registering the Aluminum ore properly and Railcraft/GT do not pick up on it. Basically MFR solves an issue with GC because of this childish behaviour to register each entry in the Ore Dictionary twice after GC failed to do it properly. I am actually thinking it is because of the ingotAluminum registered elsewhere, but not proven.
Anyways ... then what does GalactiCraft do wrong with registering Aluminum ore then? Well, registry to the Ore Dictionary is done here:
https://github.com/micdoodle8/Galac...ds/galacticraft/core/blocks/GCCoreBlocks.java (should be the right version for GC build #1044)
Code:
OreDictionary.registerOre("oreCopper", new ItemStack(GCCoreBlocks.basicBlock, 1, 5));
OreDictionary.registerOre("oreCopper", new ItemStack(GCCoreBlocks.blockMoon, 1, 0));
OreDictionary.registerOre("oreTin", new ItemStack(GCCoreBlocks.basicBlock, 1, 6));
OreDictionary.registerOre("oreTin", new ItemStack(GCCoreBlocks.blockMoon, 1, 1));
OreDictionary.registerOre("oreAluminum", new ItemStack(GCCoreBlocks.basicBlock, 1, 7));
OreDictionary.registerOre("oreAluminium", new ItemStack(GCCoreBlocks.basicBlock, 1, 7));
OreDictionary.registerOre("oreNaturalAluminum", new ItemStack(GCCoreBlocks.basicBlock, 1, 7));
OreDictionary.registerOre("oreSilicon", new ItemStack(GCCoreBlocks.basicBlock, 1, 8));
OreDictionary.registerOre("oreCheese", new ItemStack(GCCoreBlocks.blockMoon, 1, 2));
Those are 9 entries into the Ore Dictionary and after checking my log files once more, I noticed they all error out, all nine of them.
2014-05-31 17:05:26 [INFO] [STDERR] CRITICAL-ERROR: The OreDict-Registration of an Item by GalacticraftCore is too invalid to even be shown properly. This happens only if you register null, invalid Items, empty Strings or even nonexisting Events to the OreDict.
In console this is followed by the registering of blocks from:
Code:
GCCoreBlocks.setHarvestLevels();
GCCoreBlocks.registerBlocks();
setHarvestLevels does however not show anything, but the registerBlocks is definitely done right after the errors.
Now I did find something else in a different branch on the GitHub for GalactiCraft (1.7/master) where same issue was solved. Check it out here:
https://github.com/micdoodle8/Galacticraft/commit/0815996ad233082a9f523400ee735bff62641aa1
This explains exactly the issue. The blocks need to be registered
first to be able to be picked up by registering the ores. Doing this in the wrong order probably leaves 'nill' values, causing registry to error out like that. The supposed fix is shown in the previous link as well. Just change the order in which things are done, like this:
Code:
GCCoreBlocks.setHarvestLevels();
GCCoreBlocks.registerBlocks();
OreDictionary.registerOre("oreCopper", new ItemStack(GCCoreBlocks.basicBlock, 1, 5));
OreDictionary.registerOre("oreCopper", new ItemStack(GCCoreBlocks.blockMoon, 1, 0));
OreDictionary.registerOre("oreTin", new ItemStack(GCCoreBlocks.basicBlock, 1, 6));
OreDictionary.registerOre("oreTin", new ItemStack(GCCoreBlocks.blockMoon, 1, 1));
OreDictionary.registerOre("oreAluminum", new ItemStack(GCCoreBlocks.basicBlock, 1, 7));
OreDictionary.registerOre("oreAluminium", new ItemStack(GCCoreBlocks.basicBlock, 1, 7));
OreDictionary.registerOre("oreNaturalAluminum", new ItemStack(GCCoreBlocks.basicBlock, 1, 7));
OreDictionary.registerOre("oreSilicon", new ItemStack(GCCoreBlocks.basicBlock, 1, 8));
OreDictionary.registerOre("oreCheese", new ItemStack(GCCoreBlocks.blockMoon, 1, 2));
This should solve the issue completely for registering Aluminum ore and the others in GalactiCraft.
After testing with the method removed in MFR and changing the class file myself, all seems to work as expected.
Only 4 entries for Aluminum in the Ore Dictionary now and smelting -> ingots for Aluminum is properly disabled as it should.
My guess for the 4th entry is once again the ingotAluminum registered elsewhere, not proven, not bothered ...
I feel this issue is also somewhat related with this topic and certainly explains part of it:
http://forum.micdoodle8.com/index.p...-pack-errors-go-away-after-disabling-gc.4000/
Please can this info/fix be used in next updates for GC on Jenkins?