While being installed together in 1.7.10, they cause stable startup crashing

java.lang.NullPointerException: Initializing game
at gregtech.common.GT_ThaumcraftCompat.addResearch(GT_ThaumcraftCompat.java:107)
at gregtech.loaders.postload.GT_MachineRecipeLoader.run(GT_MachineRecipeLoader.java:741)
at gregtech.GT_Mod.onPostLoad(GT_Mod.java:413)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:513)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74)
at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304)
at com.google.common.eventbus.EventBus.post(EventBus.java:275)
at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:208)
at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:187)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74)
at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304)
at com.google.common.eventbus.EventBus.post(EventBus.java:275)
at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:118)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:694)
at cpw.mods.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:288)
at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:541)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:867)
at net.minecraft.client.main.Main.main(SourceFile:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:134)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)

Related to Issue #256
Unless one of Cover or Greg can duck and agree on an acceptable middle ground solution; It will not be solved.
Now, given Issue #256 is closed and wontfix, I feel pessimistic.
Whoever is right does not matter to us, simple users.

As a work-around, you can disable all Thaumcraft research recipes.

Add this to GregTech/Recipes.cfg

researches {
    B:GT_ADVANCEDMETALLURGY_true=false
    B:GT_CRYSTALLISATION_true=false
    B:GT_FILL_WATER_BUCKET_true=false
    B:GT_IRON_TO_STEEL_true=false
    B:GT_TRANSALUMINIUM_true=false
    B:GT_TRANSANTIMONY_true=false
    B:GT_TRANSBATTERYALLOY_true=false
    B:GT_TRANSBISMUTH_true=false
    B:GT_TRANSBRASS_true=false
    B:GT_TRANSBRONZE_true=false
    B:GT_TRANSCOBALT_true=false
    B:GT_TRANSCUPRONICKEL_true=false
    B:GT_TRANSELECTRUM_true=false
    B:GT_TRANSINVAR_true=false
    B:GT_TRANSNICKEL_true=false
    B:GT_TRANSSOLDERINGALLOY_true=false
    B:GT_TRANSZINC_true=false
    B:GT_WOOD_TO_CHARCOAL_true=false
}

yeah, that works for me perfectly
I'm not runing Thaumcraft at all

At some point, maybe modders will work together to make up for Minecraft's faults rather than causing each other further issues. In any case, Forge standards state that including any more than the interfaces for an API in your mod is developer-error, and any less prevents use of the mod's provided functionality; It's up to developers to fix their code, however.

APIs should not be included in mods. If this isn't fixed soonish, I will have to remove railcraft from our modpack. It got outvoted in a GT vs. RC poll for the players (but only by 12%). I really, REALLY don't want to go with the crowd on this one, but I can't very well sacrifice both.

It should also be noted, loudly, that other mods may have the same problem (namely with Forestry). It's not exactly Greg's fault, because it only looks for APIs, which as many have said, Forge standards strictly forbid. So yeah. Railcraft has made the mistake here by including other mods' APIs.

@axle, we've successfully used leagris's fix in our pack, and when Thaumcraft is finally released you'll be able to add it and remove the fix.
By no means do I insinuate that this is not a bug, what I have mentioned is merely a workaround for an admitted error the developer has stated they do not intend to fix.

That's a nice work-around, but is not acceptable. Refusing to fix a fatal flaw is unethical coding, and still grounds for removal of a mod from the modpack. Bugs are one thing, disruptive features another. And I, as the admin, am not going to play the game of mod-shuffling every few updates because one of our many mods updated and the workarounds or fixes don't work anymore. Significantly more mods are broken by including the APIs than is reasonable. You can't ask every other modder to tread eggshells for your own nonstandard (and universally non-recommended) implementation.

PS: We're prolly not re-adding thaumcraft after all. It seems to be unpopular. This surprised me. A lot.

I don't claim to know much about codding, but from a person that doesn't use Modpacks, but makes his own, having to work around unnecessary API's for magic mods when setting up a technical mod pack is added work that seams ridiculous. Railcraft is about transportation not transmutation last time i checked so what use is a thaumcraft API?

Sounds that way.

As I understood from Jaguar's reply ("If/When Azanor indicates that this is not how the API is meant to be used, then I will make the necessary adaptations."), we should go to Azanor with that?

@axlegear The "fatal flaw" is Greg not properly checking that Thaumcraft is actually present before using the API. This is APIs 101, "Make sure what you need the API for is actually present before calling API functions." It would take Greg one line of code to fix the crash. I'm simply using the API in the exact same manner APIs have always been used. And up until last week, everyone was on board with that.

You do realize it's not just Gregtech, but multiple mods, right?

Deny it as much as you want, but what you've done is NOT standard, and highly unreccomended.
We'll be removing Railcraft from the modpack next update, unless/until the disruptive design is remedied. We have no choice. We can't sacrifice multiple mods just for RC.

It's really common sense. If you make a change, and it causes problems/breaks other mods that worked fine before, and the community advises you to do differently, then you've clearly done something wrong. The fact it wasn't a problem UNTIL you did it is the most obvious supporting fact.

See my comment on "Standards" in the other thread, bottom line, there are two, I use one, Greg the other. Both standards are capable of existing together, but not if you do stupid things like assume that there is only one standard like Greg does.

Forge standards are what are followed on Forge mods. And they clearly say you shouldn't include APIs, because the second there's an assumed dependency (like GT) or other mods include APIs (like the other affected mods), then they stop working together.

Railcraft removed for hostile code.

@axlegear where are these "Standards" defined? I'd love to see them! Please!

The 'Standards' are a general consensus in the modding community of things you simply don't do. This includes not purposely writing a mod or code which sabatoges another mod, not including APIs (as this causes duplication problems, is never necessary, wastes resources, complicates updating, adds overhead, and complicates coding for others), not stealing code or functionality, not wasting textures and item IDs, allowing items to have their IDs reconfigured to remedy ID conflicts (ditto for biomes), having configureable options where reasonable, etc. There are also a few very simple common-sense things, such as how to use the OreDict to keep things clean, and some very loose definitions of 'overpowered' design that makes gaming trivial and unfulfilling.

In particular, the minecraft forge forums have had a good deal of discussion where they do not condone the including of APIs for a number of reasons, some of which I don't even understand. But the simplest is what we have right here: It breaks mods. Not just mods like Gregtech that assume presence of a mod with it's API, but also problems in keeping APIs up to date, and that if even ONE other mod includes the API as well, it will break both. Two additional points i'd like to include is the player impact. And the other is specifically, why does Railcraft even need the Thaumcraft API anyway? How is Railcraft interfacing with Thaumcraft in a way that requires an API at all? Why would a tech mod require Thaumcraft?

Really, I don't need to keep arguing. The points are clear. It cheapens the opinion of the mod, complicates it's utilization*, and serves no realistic advantage.

• = Railcraft has always traditionally been one of the most compatible, 'easy, breezy' and well-liked mods because of it's fantastic ability to play with other mods. To change that now is very hurtful, especially when it causes incompatability between Gregtech and Railcraft, as these have often been largely seen as partnership cooperative mods that work so well together, they might as well be peas in a mod. Why, CovertJaguar, why would you do this now?

PS: One last note. Remember, it doesn't matter to users who is 'right' and who is 'wrong'. They only pay attention to 'does it have these problems'. Please, don't start another inter-modder war. Just.. do the right thing.

Examples of mods affected:
BetterStorage
Gregtech
Baubles
Thaumcraft-Addons

Noted, i'm told the vast majority of other mods don't use @API, and prefer @optional

Remember that standards change. Programming in Java, i'm surprised you'd argue this. I can't count the number of functions, console switches, server configuration settings, and parameters that have been made obsolescent or outright removed just in the past half-decade.

Final edit, then taking a chill pill and breaking: Sorry if i'm a bit rambly. Just that I can't live in a world where Thaumcraft, Gregtech, and Railcraft can't co-exist. And really, again, the community majority frowns on including APIs. They really do, i'm not saying this to make your life difficult. I'd pay you (not much, i'm broke!) to just make the fix and keep the peace. Literally. Right now. Try me. $20 on the spot, more if needed.

Railcraft has Thaumcraft integration and is planning more nor do I consider it a "tech" mod. So the API is needed, because I like Thaumcraft.

I know what a "standard" is, I asking where "this standard" is defined. Including API files does not break mods, it "can" break mods if they use different versions. But that's still true even if they don't include the API. @optional does not change that fact.

Many APIs are created to exist independent of their parent mods. These mods "require" that you include the API files in order to function. Most of the APIs I've ever used did and still do follow this standard. @optional didn't even exist until MC 1.7, and I was using the Thaumcraft API even before then with no issues, in exactly the same way I'm using it now.

I am not a fan of Annotations, and in this case I just don't get the point of @optional since it limits a lot of what you can do with an API and makes them harder to design. @API already solved the issue it is trying to solve, in a much more useful way. Additionally, @optional has a ton nuances related to the class loader that are annoying to figure out. Like what happens if I need to call a method that doesn't exist, or if two APIs share a function?

If Azanor intends the API to be used with @optional, then please point me to where that is defined. I looked, but could not find any documentation at all. Nothing changed in how I used the API from 1.6 to 1.7. The assumption would be that it should still work just fine (case in point, Railcraft won't crash if another mod is present which includes the Thaumcraft API). Why is the burden on me to change rather than on the mods that changed to remain compatible with the ones that didn't?

How come the mods mentioned above have said issues, then?

Also, I HAVE contacted Azanor to get his final word on this, but so far no reply. Has he told you?

Also, what of my pleaded request? I feel very strongly about this, and really, i'll do anything to 'fix' this, whatever the cause. I really, really don't want to have to choose between these mods.

They have issues because they left out one line:

   if(Loader.isModLoaded("Thaumcraft") {
      ... do thaumcraft related stuff...
   }

Which frankly is a no-brainer in my opinion whether or not you use @optional

Honestly, since I don't really even understand exactly why Gregtech is crashing, I can't even be sure that using @optional will fix it. The crash happens in Gregtech code, it can and should be handled in Gregtech code. I mean, I could decompile Gregtech and see if I can figure exactly what is causing the crash...but I'm not sure that is technically my responsibility.

All I know in regards to that is that Gregtech detects that another mod (so far, Railcraft is the one and only one that has this issue) is using Thaumcraft's API, and thus generates recipes for it (Thaumcraft allows transmutation of Stuff into Stuff, and Greg added support for some of his metals, like Zinc). Since Thaumcraft is not actually present in 1.7.10 (due to not being updated yet), it then crashes.
Other mods that GT interfaces with don't have this issue if said mod is missing but another mod also interacts with said mod. Example: Forestry. It plays fine in any configuration.
It's just Railcraft.

For the record, I also include the Forestry API and Greg has no issues with that apparently.

BTW, this was Greg's official response:

Ahem, Forge Standards generally disallow direct inclusion of API Files, which are part of the File Structure of the originating Mod itself (unless said Mod states otherwise, or in case of Interfaces). Existence of API means that the Functionality is existing and working properly, not that the Mod is existing. That is what APIs are for, so that you can include the actual Functionality (and not just the Interfaces!) of said Program in your Program too, and unless you add your own fully functioning Thaumcraft alike Research System to the Game you have absolutely no Reason to include the non-Interface APIs for it.

I am still waiting for further clarification on 'why this happens', because I don't care WHICH of you fixes this problem, or how, as long as it's fixed!

PS: Some Forestry-related mods do have problems with Railcraft now. I believe this was why I couldn't get Gendustry working. IE, Forestry+Gendustry works fine. Forestry+Gendustry+Gregtech, also fine. Forestry+Gendustry+Railcraft, nadda.

Well Forestry still recommends including the API (I would know), so if there is a problem, its Gendustry.

I just find it strange and suspicious that, suddenly, so many mods break as soon as Railcraft includes APIs...

do you see what i'm saying?

Well I didn't "suddenly" include them, I can tell you that.

Hmm, then let me try to understand. What version were they first included? And why did all these mods suddenly break with the move to 1.7.10, and don't play nice with Railcraft, and modders are saying it's because of said APIs, and been reporting it here?

Also, if it would be advantageous, I can bring this to an IM, email, or IRC if you'd like to discuss it here. Just let me know where.

Really, I just want to find out what's wrong so it CAN be fixed.

Forestry and Buildcraft APIs have been included in Railcraft for 2+ years now or something. The Thaumcraft API has been included since mid-MC1.6. @API was added early MC1.6. @optional was added early MC1.7.2.

It seems to me that it is the @optional mods that are having issues. Whereas Railcraft continues to work the same way it always has. Newer isn't always better.

Alright, i'll contact Greg since he's the only person I have strong communication with* out of the mods that are having Thaumcraft-related API shitfits.

It still seems like it's the issue of including APIs, namely Thaumcraft's. I'm guessing it's due to some APIs being designed for it (Forestry) and some not. Since Azanor hasn't responded this week* to me, i'm willing to bet that the latest Thaumcraft changes, if not always, hate including the API. Especially since Railcraft played perfectly fine until the moment the Thaumcraft API was included. The evidence is clear on that conclusion. Hence my begging and lobbying you to remove it and include a different method. (Plus, my players are mortified by the new Thaumcraft changes, and have unilaterally, 12:1, voted on it's removal in 1.7.10... so the fix of 'just including it' to fix Railcraft is not a desireable option.)

• = Why are so many modders so aloof and impossible to speak with?

PPS: Any idea what's up with the others? All I know about them is that they, too, rely on or call for Thaumcraft, and won't play with Railcraft since the Thaumcraft API inclusion. And Baubles is made BY Azanor! So I really doubt it's calling the API wrong.. and I also know it IS updated for 1.7.10, while Thaumcraft is not. And that it works fine without THaumcraft, provided Railcraft is also excluded.

I just scanned the entire Baubles codebase, and it doesn't even reference the Thaumcraft API, so without a crash log I have no idea. But I do not believe its related.

K, then give me a bit and i'll get it.

Would you also like the GT crashlog? And BetterStorage?

I have the GT log, but no source. I do not have a BetterStorage log.

Source?

Source Code

I doubt Greg will give that out. ^.^;;
I'll have the Baubles and BetterStorage crashlogs ASAP. Working on it now.

It's... not crashing on load for me on those anymore. c.c Maybe something updated and it fixed itself?
Well, I guess those are resolved! That just leaves Gregtech! We'll see what Greg says and what we can do to fix this.

Thanks for your help!

The main Problem with including API Files is that as soon as another Mod does the same stupid thing they are 100% incompatible if they don't have the same Version. Including API Files always causes incompatibility with other Mods, and that is the Main Problem. I don't include any API (well except for my own one ofcourse) and it isn't hard not to include them. Does my TC Research require API Files in my Mod? Nope. Does dynamically copying the Recipe System and Bee Scanning of Forestry over to my own Machines require API Files in my Mod? Nope. Does my Railcraft Rock Crusher Compatibility require API Files in my Mod? Nope. Does it crash if one of those Mods drastically changes it's API? Nope.

I always thought Railcraft was a Modular Mod, why doesn't it have a "Thaumcraft" Module, which loads only if Thaumcrafts Functionality is installed, making the inclusion of APIs irrelevant?

People hate Modders who include APIs for a good reason (and it isn't the good kind of hate), which is that it always crashes as soon as the API updates and another Mod tires to use the wrong API, forcing them to update what is causing even more crashes in other Mods due to API inclusion. Not to mention that it breaks nearly all Thaumcraft Addons, and those are essentially a Part of Thaumcraft. And from looking inside your Jar File I just noticed you include the full IC2 API, what is against the restrictions of the IC2 API which state "only include the Interfaces you really need", and I see a ton of things you definetly don't need, I mean like everything.

Player has edited my Thread regarding IC2 API usage here http://forum.industrial-craft.net/index.php?page=Thread&threadID=10528 and he states that there is no need to ever ship the IC2 API, and guess what you do right now.

Oh and my Thaumcraft Compat crashed due to some Research Categories not being existent, what is definetly a Bug on my Side and that is gonna get fixed. But this doesn't mean that inclusion of API Files is still a good Idea.

As stated before, if the API changes sufficiently, @optional won't prevent crashes. And @API already solves all the cases where @optional would prevent a crash.

Well I dont use those two either. But the good old "try/catch" Block prevents crashes in case of NoClassDefFoundError just fine, when the API isn't found.