Applied Energistics 2

Applied Energistics 2

156M Downloads

[1.12] RF support without coremod

Skillotic0703 opened this issue ยท 3 comments

commented

I know that you removed all core mods last update. But since 1.12 it's possible to have redstone flux api as an optional dependency (https://minecraft.curseforge.com/projects/redstone-flux)

commented

No it is not possible.

If you want RF go talk to Lex and convince him to drop his ridiculuous stance on core mods or fix their own stuff, so we do not have to use coremods.

commented

Actually it really is possible - @optional does work correctly. We've tested. :)

Or is this some coremod specific nonsense w/ @optional? In which case - can you not easily separate out the coremod part?

commented

@Optional does not work for us. The requirement is that we can disable it via a config option. Which is not possible and Lex rejected it multiple times.

This is required for a couple of reasons. The most obvious one is to allow pack authors to limit powering AE to a certain system. E.g. EU only.

The other option is to disably integrations, should someone release a breaking API. This happend for example with RF in 1.7.10 due to some major mod bundling a beta version of it and breaking every other mod until they could release a fixed version. With most mods in 1.8+ supporting two or more APIs, some fallback usually works and players can temporarily disable the offending integration instead of having to wait until every mod is fixed.

This might be no issue anymore with RF due to being a signed .jar and in general a pretty stable API. But due to previous issues with forge and the used classloader, I would not completely trust it. E.g. even if some coremod forced an early load and forge claimed that it was loaded from this mod, the classloader could still load it from a completely different mod.

Or situations were a specific mod depends on a specific outdated version of another mod, which in return will not see a fixed version in the near future and also prevents other mods from being updated with important changes. Yes it is probably rare, but there were some cases during 1.7.10 and should 1.12 be a long term version, it certainly will happen again.

Further we already had issues in the past with @Optional not being able to strip generic interfaces and even cpw did not offer a solution at that point. There are some opinions that the stripRefs parameter might solve it, but I have no longer the code around to test it. And even if it cannot solve something like IMod1<IModB, IModC>. With it not being recommened, I also doubt we will see any changes to it, should we need it. So we would have to go back to a coremod.

Therefore we decided to drop any support when @Optional or a coremod is a requirement. It is sad and in the case of RF supporting it would probably be fine. But we decided to not make any exception. Simply to avoid any situations about "But you use @Optional already" or being forced into a coremod again. You can thank Lex for it.