Aluminum ore no longer recognized by other mods

Devilin Pixy

Member
May 27, 2014
8
2
3
50
devilinpixy.com
I am playing my own modded Minecraft with several mods and was happy to see how Aluminum ore could be processed through Railcraft and Gregtech without having the smelting recipe from ore to ingot. This made making Aluminum ingots or 'Aluminium' products from GregTech hard because in my modpack this meant you needed more advanced GregTech machines to be able to process it. I was using the default download for Galacticraft (build 1010) back then.
We noticed that this version (1010) was causing lag issues and other problems and I decided to update to a latest development build from Jenkins (1044). Ever since that update, Aluminum ore is no longer recognized by other mods, making it impossible to process it with those mods (apart from smelting in any type of furnace) and allowing normal smelting to ingots again. This changes the level of gameplay, because now I can smelt to ingots in any furnace and then use the resulting Ingots to do further processing with the mods again if needed. Example: Previously I could only process the ores to get to 'Aluminium' dusts and to 'Aluminium' ingots through GregTech/Railcraft ((Industrial) Grinder/Rock Crusher (dusts) -> Industrial Blastfurnace (Ingots)). My modpack is supposed to be hard-mode and I loved the fact it needed mid-tier machines to actually be able to get to the 'Aluminium' ingots. Now the balance is broken for my modpack.
Did Ore Dictionary Registry for Aluminum change to break compatibility with the 'Aluminium' used in other mods? Is there a newer development build on Jenkins available that fixes this issue again? Do I have to start a fresh world and disable Aluminum ore to spawn by Galacticraft to fix this?
 

SirKillz

Member
Apr 20, 2013
172
17
18
I have also noticed this. In tekkit, Aluminum is one of the only ores that can't be processed by Thermal Expansion machines and others of the like.
Well thermal machines like the furnaces should work. Pulverizers will not work because there is no pulverized aluminum. It would have to make something that isn't there.
 

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
To help us find the cause of this issue, I'd really appreciate it if players seeing this issue could test some GC builds between 1010 and 1044 to try to identify the exact point when things changed. One idea: please especially test builds either side of 1031.

My understanding is that the aim here is, in other mods, to have both GC Aluminum Ores and GC Aluminum Ingots compatible with "aluminium" equivalents in the Ore Dictionary. Can't add aluminum dusts or powders at this stage, that will have to come in 1.7 (if it comes at all).

But: I'm a little confused, @Devilin Pixy. Galacticraft has had, for a long time, a smelting recipe Aluminum Ore -> Aluminum Ingot. That smelting recipe was very definitely present in 1010. So how is it that you prevented smelting of the ore, in 1010?
 
Last edited:

Devilin Pixy

Member
May 27, 2014
8
2
3
50
devilinpixy.com
To help us find the cause of this issue, I'd really appreciate it if players seeing this issue could test some GC builds between 1010 and 1044 to try to identify the exact point when things changed. One idea: please especially test builds either side of 1031.

My understanding is that the aim here is, in other mods, to have both GC Aluminum Ores and GC Aluminum Ingots compatible with "aluminium" equivalents in the Ore Dictionary. Can't add aluminum dusts or powders at this stage, that will have to come in 1.7 (if it comes at all).

But: I'm a little confused, @Devilin Pixy. Galacticraft has had, for a long time, a smelting recipe Aluminum Ore -> Aluminum Ingot. That smelting recipe was very definitely present in 1010. So how is it that you prevented smelting of the ore, in 1010?
I know that smelting Aluminum ore to ingots from GC has always been default. My assumption is that GregTech uses the ore dictionary entry to change the way it behaves, disabling smelting to ingots, but allowing processing through other machines. This resulted in my pack to not be able to get ingots unless resulting dusts were used in Industrial Blastfurnace to get the ingots. Processing through the Rock Crusher from Railcraft was also an option, but resulting in dusts as well. I have made some updates to my modpack over time, but none of those seem possibly related apart from the GC update from #1010 to #1044.
Not sure if I have time to do some testing on different versions around #1031 or to revert the update I made to GC to see if that is actually the issue. If I do, I will report my findings. I will however post my issue on the GregTech forum to see if others have similar issues since I know some do play with a combination GT/GC.
 

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
@Devilin Pixy, just to be clear for your Gregtech posting - GC does register the Aluminum Ore to the Ore Dictionary, registers it 3 times as "Aluminum Ore", "Aluminium Ore" and "Natural Aluminum Ore". The ore was registered the same way in 1010 and 1044 versions. Before today, the GC Aluminum Ingot was only registered once to the Ore Dictionary, as "ingotAluminum". I have changed that as from today, added "ingotAluminium" and "ingotNaturalAluminum".
 

Devilin Pixy

Member
May 27, 2014
8
2
3
50
devilinpixy.com
@Devilin Pixy, just to be clear for your Gregtech posting - GC does register the Aluminum Ore to the Ore Dictionary, registers it 3 times as "Aluminum Ore", "Aluminium Ore" and "Natural Aluminum Ore". The ore was registered the same way in 1010 and 1044 versions. Before today, the GC Aluminum Ingot was only registered once to the Ore Dictionary, as "ingotAluminum". I have changed that as from today, added "ingotAluminium" and "ingotNaturalAluminum".
Would love to figure out what caused the change in behaviour. If you wish, you can check my forum for this modpack here: http://forum.devilinpixy.com/Fun-Paradise-IV-f4977081.html It includes several topics so you could check the mods used as well as the changes made to the pack. The pack is not public yet though, waiting on CovertJaguar so the download link is fake for now. If you need more info like log files, let me know.
 

Devilin Pixy

Member
May 27, 2014
8
2
3
50
devilinpixy.com
I found the issue! I have done some testing in Single Player.
  1. Reverted client back to the date prior to updating GC. Running version 1010. Created new world (creative SP). No issues, smelting recipe disabled for Aluminum ore to ingots which is changed by GregTech.
  2. Copied instance and updated GC to version 1044. Created new world (creative SP). No issues, smelting recipe for Aluminum ore to ingots is still disabled by GregTech.
  3. Copied instance and updated MineFactoryReloaded to a GregTech friendly version of MFR which I got from someone on the GT forum to remove childish behaviour (console spam with messages added by SkyBoy in his final 1.6.4 release for MFR). Now the issue is there! Smelting recipe for Aluminum ore to ingots is back and only other option showing in NEI is 3 entries in the Ore Dictionary to change Aluminum ore (GC) to Aluminum ore (GC).
Conclusion: The MFR GregTech friendly version is causing the issue! To be clear about this, it is not the original MFR final version causing the issue, but an edited version of this release made by someone else.

I will report back to the GregTech forum as well and revert my MFR to the *childish* version until the *friendly* version is fixed.
 
  • Like
Reactions: Vigilantecow

Devilin Pixy

Member
May 27, 2014
8
2
3
50
devilinpixy.com
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?
 

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
Thank you! Nice job, you are very thorough and as you say, this solves both topics. New build 1066 now available: http://ci.micdoodle8.com/job/Galacticraft/1066/

(Looks like I derped, fixing that in 1.7 but not realising the exact same thing needed to be fixed in 1.6 - been so many changes since 10 May I don't even remember doing that now...)
 
  • Like
Reactions: Ezer'Arch

Share this page