[Bug][Mod Interaction]RotaryCraft Compat breaks all RC ore handling #72
Comments
|
Turning off RC handling on an existing world seems to put my server in a crash loop. 😢 I hope this gets fixed. |
|
It works for everyone else. Log? |
|
Nevermind. I think our admin did something wrong with the config. It's working, now. Sorry about the false start. |
|
All I'm doing is this. I'm not sure how that could break it |
|
Maybe it has to do with duplicate registrations or something? Or maybe the OreDict names are off. Or, are you pulling things out of the OreDict then re-adding them? The timing may simply be bad (causing DragonAPI's caches to be emptied and not refilled). Also, does AOBD not replace all vanilla ores? If so, globally setting all of them with the same settings is going to break other things, in particular the multiplication rates of nether and rare ores. |
|
-Could be duplicate registrations. I'll check on that. |
|
All I have been told is that my handlers stop working, and since they build caches of the Ore Dictionary, that means something either edited those caches (unlikely), or edited the Ore Dictionary. Basically it is a Map < ItemStack, OreType > . |
|
Hey @ReikaKalseki mind pointing me to the class in RotaryCraft that adds the default recipes? So I can make sure I'm not adding dupes |
|
So, I've confirmed that I'm not adding duped recipes... What do you mean when you say "edited the OreDictionary", because I add stuff to it, would that count? =P |
Mostly RotaryRecipes, but also ExtractorModOres. However, most of the Extractor code is internal to the TileEntity class. |
|
So after some tweaking/testing, the recipes that AOBD added are indeed not working (for everyone's surprise...), but I was at least able to stop it from breaking the Extractor completely. I noticed this error showing up in the logs (tested against V7f): [12:16:33] [Client thread/INFO] [FML]: Could not load Extracts API!
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: java.lang.NoSuchFieldException: modOres
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at java.lang.Class.getDeclaredField(Class.java:2070)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at Reika.RotaryCraft.API.ExtractAPI.<clinit>(ExtractAPI.java:98)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at ganymedes01.aobd.recipes.modules.RotaryCraft.initOre(RotaryCraft.java:28)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at ganymedes01.aobd.recipes.RecipesModule.init(RecipesModule.java:49)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at ganymedes01.aobd.recipes.ModulesHandler.init(ModulesHandler.java:31)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at ganymedes01.aobd.AOBD.init(AOBD.java:70)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at java.lang.reflect.Method.invoke(Method.java:497)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:532)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at java.lang.reflect.Method.invoke(Method.java:497)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at com.google.common.eventbus.EventBus.post(EventBus.java:275)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:212)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:190)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at java.lang.reflect.Method.invoke(Method.java:497)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at com.google.common.eventbus.EventBus.post(EventBus.java:275)
[12:16:33] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:119)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at cpw.mods.fml.common.Loader.initializeMods(Loader.java:737)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at cpw.mods.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:311)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:552)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:878)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.client.main.Main.main(SourceFile:148)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at java.lang.reflect.Method.invoke(Method.java:497)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
[12:16:34] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.launchwrapper.Launch.main(Launch.java:28)Also, after a quick look through your code, it seems to me that the Extractor tile entity doesn't check against the registry of recipes added by other mods, which is what could be causing the issue as well. |
|
This is not the cause of the issue, as it only breaks the "add extra ores as already handled types", which, as the documentation says, is equivalent to just adding it to the OreDict. Also, the relevant code for recipe fetching is in fact here; the code you linked above was largely unused. Recipe instantiation happens the first world tick (or first Extractor tick), so as long as you add the custom ore types, or register new ores to the OreDict before then, it should work. |
|
As okay, yeah sorry, My look wasn't exactly thorough, it's hard to figure out how other people's code work without any previous knowledge of it. I register the items on the OreDictionary (and the recipes with RotaryCraft) on init, so that shouldn't be a problem... So back to the drawing board, because I'm out of ideas again as to what's going on )= |
|
Okay, so I have another theory lol |
|
Two questions:
Also, a heads-up: the OreType interface has been moved into a subpackage for v8. EDIT: No, this is not the cause. That method, though incorrect, only controls automation and shift-clicking. Manual left-click placement would still work, and ore pumped in directly would be processed. |
|
-It doesn't really? I'm not touching anything I shouldn't (wouldn't want to break your balance), all I'm doing is calling the ExtratAPI method... that's literally all. -I'll try doing that tomorrow (2am here, heading to bed). Should tell us whether or not there's a problem. |
|
Hm, well I don't remember if I tried left-clicking the stack in, I might have only tries shift-clicking. And I also did not attempt to insert it using a hopper (or similars). I'll try it too, just in case :3 |
Then why do mod ores stop working? ModOreList.getModOreFromOre(ItemStack is) would still return the appropriate values. |
|
I wish I knew... The |
Made it print it out on the console. That stack is of an ore registered as oreEndium. AOBD adds support for it and the recipe shows up on NEI. But as you can see, every slot refuses the item. Here's the control to prove that my testing method actually works (yay for the scientific method): |
|
That is not what I meant. Put the ores in the slot - forcibly call setStackInSlot - and see if the machine processes it. The code breaking the ore handling is not necessarily in your RC interface code. It is breaking this somehow: https://github.com/ReikaKalseki/DragonAPI/blob/master/ModRegistry/ModOreList.java#L295 Load a world and check for messages like "no ore blocks detected for COPPER" or "3 Ore blocks detected for TIN". |
Right, sorry about the misunderstanding. I'll do that straight away. Update: Nope, forcibly setting the item in doesn't seem to work. The machine just sits there doing nothing. |
|
|
Also found this: Which I guess indicates that the ore dictionary side of things is working soundly. |
Maybe |
ModOreList does not handle API registrations. But look - even natively handled things are breaking: "No ores detected" for every single ore type. |
I think that's because there truly aren't any of those ores in my instance of Minecraft. But Cobalt and Ardite are still not being processed. Though the machine does accept them to be placed into the right slots. |
That means the ore handling is recognizing them.... |
|
So I found a way around the problem... I know it's something I shouldn't be doing, but I wanted to try it anyway. Don't worry, it won't be in any release. What I did was I added an entry to the ModOreList enum at runtime containing the ore I wanted to add support for. And surprisingly enough it worked! So hey, if you want to turn that into the "official" API I can give you the code =P |
|
...How...how did this work? But doing it this way is going to break the registries, so it is not a viable solution. In particular, that means all of the added products will be pure white, more than a certain amount will be "missingtex", an OOB error is imminent, and, if installed, MeteorCraft will start erroring out. |
|
Yeah I noticed so. Like I said, this was more of a "lets see what happens" than a attempt at solving the problem. But forge has an EnumHelper class that allows you to add entries to any enum. That's basically all I had to do. |
|
I know. I use that for ModCropList. Still...I have no idea what is going wrong... |
|
So @ReikaKalseki "Caused by: java.lang.UnsupportedOperationException: This map does not support overwriting values! Item tile.brOre.0:0 already mapped to '1xitem.item.modextracts@40'!" AOBD is causing some recipe overlap or some sorts? |
|
The HashMap<ItemStack, ItemStack> I use does not allow for a put() operation with a pre-existing key, hence the error. Something tried to register the same recipe twice. |
|
Do you know which metal "1xitem.item.modextracts@40" corresponds to? |
|
ModExtracts is the ModOreList items. Metadata 40 would mean ordinal 10 which means Uranium. Metadata 40 means ExtractorStage 0, or the dust, which would turn into meta 41 (the slurry). Did you try adding recipes with these items? |
|
It shouldn't be... Let me do some testing. Oh, glad to see you on Curse :D Here's mine as an example in case you don't find it: |
Did some testing, and was unable to reproduce the crash. Uranium is blacklisted and is not touched by AOBD (because it's handled by RC itself). So I'm not sure what happened there. Maybe it's just something that was broken on a previous version of RC and you fixed it "by accident" (I tested this only on v8c) |
|
v8c is working for everyone else... As for dependencies, I am not going to go through and list all the files as depending on DragonAPI, when I will have to go through and do it again when I upload a new version. |
|
Edit: Apologies, I was sure I had the latest version of AOBD, but I do not, it would appear that the two more recent versions of AOBD have fixed both the Yellorium and Dark Iron interactions. This issue should probably be closed. Sorry for disturbing you Reika. Original comment: My guess is that RotaryCraft is registering Big Reactors Yellorite Ore to produce Uranium dust/slurry/solution/flakes regardless of AOBD (disabling RotaryCraft Uranium support in AOBD does not disable RotaryCraft support for Uranium), however, AOBD will try to register RotaryCraft Yellorium dust/etc. for the Yellorite Ore. Disabling Yellorium RotaryCraft support fixes this. I'm guessing that RotaryCraft has a mapping somewhere that maps tile.brOre.0:0 to '1xitem.item.modextracts@40', then AOBD tries to map tile.brOre.0:0 to '1xitem.item.customextract@4' (Yellorium Dust) which RotaryCraft won't have any of. Furthermore, RotaryCraft is handling Factorization Dark Iron itself too, so with Factorization, AOBD and RotaryCraft I'm getting a very similar crash, this time The fix for people currently running these mods is to disable AOBD RotaryCraft support for Yellorium and FZDarkIron (I don't think having Uranium on or off for RotaryCraft actually does anything in the AOBD config, but I turned it off anyway). I'm sure that @ganymedes01 and @ReikaKalseki can work out the best way to solve this incompatibility between the two mods. |
|
The recipes are shown in NEI, but I can't put them in the extractor. When I disable the integration of one ore in the aobd.cfg ( Adamantine { ... B:RotaryCraft=false ... } ) then the recipes are gone. So I think, that this is added by aobd. Further testing has given me the following additional informations:
Could the last point be the issue? |
|
I had accidental tested another thing. Test sample was Atlarus Ore. The ore itself doesn't go into the extractor, but all "in between products" of the extractor, like the dust, slurry and solution are working in the extractor. Only the first step from the ore to the dust doesn't work. |
|
I spent some time trying to find the issue of the problem @BakermanLP is describing and this is what I found: |
|
I have made a issue on Reikas side about this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The title says it all. :P
Turning off the RC handling in the AOBD config seems to fix the issue.
The text was updated successfully, but these errors were encountered: