Using Mek 8.0.2.201, EIO 2.2.8.364. Energy conduits will not connect to Mekanism machines. Fluid and Item conduits connect normally.

see also: SleepyTrousers/EnderIO-1.5-1.12#2160

This is due to the integration changes made to prevent crashes - CoFHCore in its entirety is now required for interaction with the RF API.

It's a new approach that's meant to prevent issues from people shipping fragmented copies of the RF API. In my opinion, the lack of a single energy implementation is better than a startup crash

The alternative was that we crashed whenever another mod was used that caused the "CoFHAPI|Energy" check to return true (ie. any mod shipping the RF API) that we didn't explicitly add a dependency on, or whenever any mod included a partial CoFHAPI|Energy, but with classes missing.

Beat you to it @unpairedbracket! ^^

It was causing issues with the fact that EnderIO would cause us to crash unless we depended on it (due to including CoFHAPI|Energy), but would cause a circular dependency if we did (due to it depending on our Gas API).

The only other option as far as I can see is to write an alternative to FML's builtin @Optional system, but I would have no idea how to do that. I will look into it, however.

EnderIO ships the entire CoFH API, no fragmented classes. The fact is that those issues are not your fault and it is the wrong way to use the API. It will only cause confusion going forward, imo, and is not an issue you need to solve

@unpairedbracket Why write an alternative? @optional works fine.

@Optional does not ensure that the mod shipping the RF API (EnderIO, in this case) is classloaded before the mod depending on said API. Unless we depend on every mod that does so, we may crash if they're sorted above us (as many mods starting before M in the alphabet are by default), because the classes aren't loaded at the point at which our classes load, but @Optional has not stripped the superclasses, as the modid of the API is present.

Classloading shouldn't have anything to do with this. If the classes exist they will load when you request them. Mod loading order shouldn't affect that.

Depending on every mod that ships the RF api, as I previously attempted to, is firstly impracticable due to their number, and secondly impossible for any that depend on us.

Also all @API containers are loaded before mods, afaik

Mod loading order shouldn't affect it, but many, many crash issues on this very tracker attest to the contrary.

So why are you not just shipping the RF API like you are meant to?

Every interaction I've had with cpw has made it abundantly clear that we're not "meant to". The response to asking for a solution to this issue being an issue is invariably that other mods need to stop shipping APIs they do not own. See MinecraftForge/FML#473, for example.

What? That's a really bad idea. RF is meant to be autonomous from CoFHCore.

RF is a special case because it does not have a specifc owner mod. I don't expect cpw to understand the situation but CoFH does approve of you shipping the API.

The general guidance is NOT to ship APIs you don't need to.

In this case, you do need to ;)

Hmm, fair enough. I'll consider adding the RF API to our shipping classes then.