The coremod is a bit of an old relic in terms of code. It is being kept up to date but it was created before stuff like "@optional" was a thing.
We should need to take a look at the thing and figure out if it is capable of being removed or substituted.

Seeing as "@optional" is generally shunned, we also need to take a look at where the Capability system is something we could use.
This would also require the cooperation of the other API/Mod though.

The recommended way that Forge wants Capability injection is https://github.com/SleepyTrousers/EnderIO/blob/1.11-base/src/main/java/crazypants/enderio/power/CapInjectHandler.java#L35-L42

If we are not able to cleanly remove said coremod we should need to take a look at our options for 1.13 and signed coremods.

• Minecraft Version: 1.12
• AE2 Version: rv5-1.12
• Forge Version:

The coremod currently exists for the sole reason to support RF. As already said, we should scrap it and be done with it.
IC2 integration might need a bit of additional work on our side, but itself is design to need neither @Optional nor caps to work. Should someone complain, just forward them to lex and/or cpw.

@Optional is simply no option, because it does not give a player the choice to disable certain integration and this was already rejected by forge (probably many times). This is especially useful for an API break. Instead of simply crashing, it allows the player to temporarily disable it until a fix could be released. Which then also includes the issue regarding transitive dependencies. E.g. someone might be forced into the old Mod/API due to some other mod depending heavily on it, therefore it will not see a fix for a longer time. Which then prevents them from updating AE to fix another major issue.

Further it has issues with generics. There is of course stripRefs, but even cpw did not suggest it as solution for the issues we had it, because it was not able to strip generics. Additionally it also does not support complex dependencies like implements GenericContainerInterface<ICoreLibModA, IConcreteImplModB>. E.g. in case something has a core lib (like cofh) and a couple of distinct mods using it. Luckily we never encountered it, but at least we could change our coremod to support it. @Optional will never be changed.

Caps should be fine for most cases (aka energy). For more heavier stuff like inventories it sucks, but we already have to deal with it somehow.
But for AE2 itself it is really difficult, because we will have to break the cap contract on multiple levels.

At first we need at least 8 locations per block (each side + center + "wildcard"). Simply not possible with caps, except we ignore the sided part completely and just work with null (or any side). and then handle the sideness within the cap itself.

Secondly is the whole no caching bullshit, we simply have to ignore it for performance and rely on block updates or explicit ME events to notify about changes. Prepare for other mods complaining about it, because they are designed to never allow block updates or send events because the rely on caps being uncachable by contract.

Further the grids are designed with IGridHost in mind, which allow direct access to other sides without going through the tile entity again to obtain another side. But that can be solved by the first contract break.

Also forge itself does some stupid things like injecting the forge energy cap too early to handle anything but assign it to a field. No option to handle it with a config setting, except by adding a cleanup to fix the mess forge did create earlier.

If we are left without the coremod or @Optional we have to either hard-depend or remove RF/IC2 integration indeed.
The option to temporarily disable said @Optional is indeed something that is not possible at the moment. That would mean that we would have to rework the code to account for that.

But in the end seeing as most mods now support FE we might be able to really obliterate RF indeed.
We support FE and Tesla already. FE through P2P even (I don't think a Tesla P2P is interesting in the long run, seeing as Tesla is on the way out really).

Nevertheless there is the option of doing it without a coremod, without @Optional but it'd be really ugly.

Great to see some thought put into this! On a similar note, can we get f44cddf ported to the rv5 branch?

Why would we need that when the coremod is removed @phit?

Because that wasn't the case until 30minutes ago, and I was hoping for a temporary solution. Didn't expect this to be done so fast, after so much drama around it in 1.10 and no progress on this front in months.

Anyway I appreciate this being resolved now, thanks for your hard work!

Because you guys decided to complain about it and repeat the same already rejected solutions again and again. Instead of just waiting for it to be done. So most of the time was dedicated to discussing why it is not happening and pretty much nothing was done for the code itself as there was no time left.

If you would've read the entire issue report you could've gathered that the end result would be to remove the coremod though.

you guys

Not sure who you mean, but I didn't complain in the issue. I actually provided a solution for server owners and gave you time to implement this. Probably stopping a lot of the complaints you would've gotten otherwise.

I know evaluating the removal of the coremod was a priority from the start, but there was no update in months, then this issue here popped up and it was actually done super quick. So excuse me for being happily surprised.

I do not really remember which exact persons were involved. Removing the coremod was always planned but not possible due to having to support RF. Optional was no alternative. Sure just changing the classes would be easy, but it was simply an incentive to get a better solution. Which did not happen. So it pretty much died to that and me not having enough time to support it at that time. But it is also part of the stable release for rv4 as promised, should we have no other solution.