Universal Cables to Galacticraft Blocks Crash (and buildcraft api crash)

[Thornbush42]

*Crash 1:

When placing Galacticraft blocks (i.e. launch controller), Minecraft crashes and gives the following crash reports:

Server crash report - http://goo.gl/0wTxQ9
Client crash report - http://goo.gl/rKK98Z
OpenEye report 1 - http://goo.gl/Ng2HLQ
OpenEye report 2 - http://goo.gl/gVo3Jp

Minecraft version - 1.7.10
Buildcraft version - 6.3.3
Galacticraft version - 1.7-3.0.8.257

By the looks of those reports, I think Galacticraft is erroring when pulling buildcraft api's. So, I removed buildcraft - which fixed it, obviously - and that caused crash 2 (below)

*Crash 2

I have another major problem with Galacticraft, and it involves compatibility with Mekanism. Whenever I place a universal cable (from the Mekanism mod) that's next to a Galacticraft mechanical block (i.e. launch controller) Minecraft crashes.

Server crash report - http://goo.gl/Y8oTwe
OpenEye report - http://goo.gl/oh9yMC

From what I've read up about this kind of crash, it seems to be caused by a problem with the pulling of Mekanism's api by Galacticraft. I hope you can fix this, and soon. Thanks.

Minecraft version - 1.7.10
Galacticraft version - 1.7-3.0.8.257
Mekanism version - 1.7.10-1.1.8

[radfast]

From what I've read up about this kind of crash,

Please give links to what you have read about this kind of crash so I can deal with this at the origin. I find it annoying when non-experts "suggest" that the reason for crashes such as these is Galacticraft not implementing other mods APIs correctly. That is not the reason, and it's somewhat of a waste of my time to have to explain why.

Your first one (Buildcraft) is a duplicate of #1368, as a search of our Github might have told you. It is not a Galacticraft bug, it is due to a bug in an outdated version of the Buildcraft API. The Buildcraft guys seem not to be bothered by the bug (because it is so outdated). You need to figure out which other mod is using the outdated API and update that other mod. In #1368 it was Enhanced Portals but you do not have that, so it must be something else. If you cannot find which other mod it is, then we have provided a config option in power-gc3.conf to disable Galacticraft<->MJ power conversion completely, which will avoid the crash if you can live with the loss of functionality.

Your second one is a duplicate of mekanism/Mekanism#2082 and is not a Galacticraft issue at all. Mekanism is, for some reason, testing whether it can connect to the Galacticraft block using RF API - I don't know why Mekanism tests that, it does not need to as Galacticraft implements Mekanism's own API directly, but never mind that for now. The crash is because RF API took the dumb step of changing the API half-way through this Minecraft version, as discussed in detail on #791. Some mods use v1 of the RF API, some mods use v2. It looks like Mekanism is now compatible with v2 of the RF API only, but another mod in your modpack (most likely an outdated version of MFR) has v1. The RF API guys seem to think this is OK because everybody can just update all the mods to the latest. But it creates problems like this for techmods like Mekanism (and Galacticraft) which are not RF mods but offer RF compatibility. With some effort we made Galacticraft dual-compatible with v1 and v2 a couple of weeks back, to avoid this type of problem. I have posted some links on the Mekanism issue thread so they can make Mekanism dual-compatible also, if they are interested, that's really up to them.

[unpairedbracket]

The reason why we check your tiles for IEnergyProvider is easy: we can't tell the difference between a tile that doesn't implement ICableOutputter because it's an RF-only mod and one that doesn't implement it because it's not an outputter. The only way to find out is to check for IEnergyProvider on anything that's not an ICableOutputter. I wouldn't be surprised if this crashed on vanilla chests and stuff as well...

Oh, and thanks for pointing me to your solution to the RF API having changed at such a bad time - it looks like it'll be helpful. It may be a while before I have the time to look it over properly though, I'm really busy with university work at the moment.

[radfast]

Pleasure :) Off topic but for what it's worth, we do implement ICableOutputter but only on our tiles which are energy outputters, but not the rest:
https://github.com/micdoodle8/Galacticraft/blob/master/src/main/java/micdoodle8/mods/galacticraft/core/energy/tile/TileBaseUniversalElectricalSource.java#L227

Are you saying it would help compatibility (e.g. avoiding the need for checking other APIs at all) if we implement ICableOutputter on all our energy tiles, returning false on all the non outputter tiles? We can easily do that.

[radfast]

ok that's done, see c76a27c

@thormbush42 if you update Galacticraft to the latest build 258 when it comes (Monday, maybe), it will maybe fix the Mekanism crash with Galacticraft machines. But you will still get the same Mekanism crash if you connect Univeral Cable to machines from other mods unless you fix the problem by updating MFR.

[Thornbush42]

I updated every mod I had installed and it was fixed - so it must have been some other mod causing problems (sorry).

[radfast]

Please give links to what you have read elsewhere about this type of crash - if it's on another Minecraft forum, we should go and deal with it.

[unpairedbracket]

@radfast That'll fix that specific issue, yes, but still any tile not implementing our energy API will be checked and crash if the correct CoFH interfaces aren't present. I think the best/only way to really solve the issue would be to do what you've done to check for RF version before using any of the interfaces. I'll see about doing that when I have the time

[radfast]

Agreed. That change in the RF API is a pain, but hopefully not too bad for you to fix now. What really bugs me is it makes it look like Mekanism (or Galacticraft) is crashing, and so players think our mods are unstable or crash-prone, when it's totally not our fault.

[unpairedbracket]

The issues caused when the new Energy Interfaces were present but IEnergyHandler was overwritten by a version that didn't extend them were fun too. Machines not passing energy to RF acceptors because the class hierarchy was wrong is such an excellent thing to have to explain to non-programmers. People accusing us of shipping old versions of CoFH API, when we don't ship it at all, and had supported the new version for about 2 months...