Issue description:

Crash while loading with exception:
net.minecraftforge.fml.common.LoaderExceptionModCrash: Caught exception from MekanismGenerators (mekanismgenerators)
Caused by: java.lang.NoSuchMethodError: buildcraft.api.fuels.IFuel.getFluid()Lnet/minecraftforge/fluids/Fluid;

Steps to reproduce:

1. Install latest Buildcraft version 7.99.5 + Mekanism 9.3.2.307
2. Start game.
3. ???
4. Profit!

Version:

Forge: 13.20.1.2393
Mekanism: 9.3.2.307
Other relevant version: BuildCraft 7.99.5 Alpha

link here:

Crash

Reported in #4827 and the fix will be available in the next release.

Sadly this problem has returned

Upgraded mekanism to version 9.4.2.327
Buildcraft version is 7.99.12

latest log:
https://gist.github.com/Staegrin/ace62c7cf071f8bb3240177c4c710e76
Crashlog:
https://gist.github.com/Staegrin/014e5442522df855fa7bda251def74fe

Latest version of BuildCraft has a breaking change in their API. They changed a couple methods from Fluid to FluidStack.
BuildCraft/BuildCraftAPI@b396bc7

what sort of integration does mekanism currently have with BC?

also could you please stop shipping the entire API? only shipping the parts that are realy used will atleast make sure it only breaks if a part you use changes (not shipping any of it and using alternatives if available would be best but not sure what the integration exactly is so if that is possible here or not)

@AEnterprise a method in the bc api changed, which they call (IFuel.getFluid). Techreborn had a simalir problem, so they will need to update their usage to fix it. It doesn't matter in this case if they do ship the entire bc api, it would have crashed somehow anyway. Although I haven't checked...

@AEnterprise Mekanism currently supports 2 features of BC as far as I currently see.
One being the BC wrench, allowing it to be used on Mekanism blocks.
The other being the Fuel system for cross mod compatability.

The latest one has a breaking change on BC's end as @AlexIIL pointed out. It might be nice to have a feature getFluid which returns the old Fluid, and a new method getFluidStack which returns a fluidstack. One being deprecated and returns the Fluid of the fluidstack.

*note, I'm not 100% familiair with the code, so I might miss some stuff.

--Edit--
And as far as I see, mekanism doesn't ship the API, only used compile time ;)

I suppose it was a bit naive of me to assume that people wouldn't depend on the api as it's in alpha. I'll probably create a maven repo to hold the sources for the api, so that you can use it a little easier.

One thing that I changed (silently) was that registerFuel takes MJ rather than RF, which means that values passed in Buildcraft need to be multiplied by MjAPI.MJ, which is currently 1,000,000. I haven't actually tested yet, but if you're passing in values meant for RF then all fuels are going to produce less than a thousandth of what they should :P

Mekanism uses BC's api for a long time ;) The current version being used is 3 months old, from the Mekanism port to 1.11.

A maven repo sounds good! Would be nice as there's one mod less to keep track of directly.

Mekanism currently uses a constant "FROM_RF", which would exactly indicate all the fluids produce a "bit" less than intended.

Will update "soon". Thanks for providing some information!

Any eta on when the next "update" might be? Just got this issue today(mecanism generators) and am curious.

I'll open a pull request for 1.11.2 tomorrow ;)

Alright. Sounds good!

@AlexIIL
I'll probably create a maven repo to hold the sources for the api, so that you can use it a little easier.
There's already a BC maven repo which holds the API, it's only pretty outdated.
http://files.minecraftforge.net/maven/com/mod-buildcraft/buildcraft

Opened a PR here for Mekanism with an update to the newest API

Maven for bc is here: https://mod-buildcraft.com/maven/com/mod-buildcraft/buildcraft-api/

@AlexIIL could you exclude the package-info files from the API jar? When they are present, it means one can't test Forge's Optional.Interface stripping is working correctly within IDE debugging sessions as it will always consider the API loaded

Wouldn't that defeat the point of having package-info files in the first place? And that would mean that you couldn't test with them loaded.

If you really need to test the it would probably be simpler to delete them manually. Or just remove the maven dependency temporarily and test without?

Alternatively I could publish "buildcraft-api-missing" artifacts to test that with... but I'm not convinced it would be useful.

EDIT: I'll need to test it actually before deciding it's not useful...

No, because the package info files are just to tell forge that the API is present (and should not be stripped when @Optional is used correctly). It only has real benefit if you are shipping the API, which as a maven dep will never happen.

An API jar from maven should only be compile time classes AFAIK.

And that would mean that you couldn't test with them loaded.

They would be loaded when the Buildcraft mod itself is present and usable. You can't test without the api in the IDE when present. So you could forget an @Optional and you'd never know until you tested it outside the IDE.

If you really need to test the it would probably be simpler to delete them manually. Or just remove the maven dependency temporarily and test without?

Nothing would compile, you'd need to have an extracted copy like we just got rid of.

I'm not going to be able to test anything in my dev environment for another week and a half so I can't test api dependency stuffs right now unfortunately. However:

They would be loaded when the BuildCraft mod itself is present and usable.

Most of the BC api can be used without Buildcraft being loaded, so by definition if the api is loaded then it is fully loaded.

Nothing would compile

Can you try using the eclipse compiler? That should be able to compile code even if the dependencies are missing, although it might not fully work.

you'd need to have an extracted copy, like we just got rid of

Did the bc api do this previously, or are you referring to yourself removing them manually?

I might just be wrong and it's not a problem unless the dep isn't set as compile-only in the IDE. Carry on.

Did the bc api do this previously, or are you referring to yourself removing them manually?

Essentially needing to revert https://github.com/aidancbrady/Mekanism/pull/4523/files
(for some reason I though this was part of the 1.12 port and was set to be pulled in along with it)

Any idea when mekanism will update and resolve this issue?

Aidan will take a look at the pull request (made to fix this issue) this weekend, I will not say it's solved by the end of it, but we will certainly be a lot closer ;)

Any Progress?

There's currently a pull request open to fix this issue. See #4523 for the progress.
It's almost ready, needs some final checks to confirm functionality before merging.

Any closer to the solution?

Please be patient, we all have a social life and things besides Minecraft ;)
Aidan is quite busy, give him some time.

I guess stuff will progress this weekend. (my guess, no promises)

Nope. Same crash. You can reopen this

Closed as in, fix will be available in the next release ;)

Ah, not on the 310 then. ok

Nope, not yet. Once the related PR gets merged to the master branch. I expect it very soon.

well, so til there is a patch for it i have to deside between BC and Mek.

The version you're looking for has been released a couple hours ago ;)

wait, of what, Mekanism or BC? because i got the newest BC just 0.5h ago from the BC website... 7.99.6

Mekanism. Version 1.11.2-9.3.3.311-fix is available on curseforge.

It still crashed. :c

I can haz logs plz?

oh nvm, i just tried to open a Broken world with it...

Which mod was doing the crashing?

Advanced Rocketry. was a Problem with Mining Missions... negative time, etc. game didn't knew what to do and it just died.