With our own energy system being a bit lacking, we have to support at least one 3rd party one. Ideally more.

Should have (or even must)

These should be limited to capability based ones or at least require no hard dependency and method stripping. @Optional should really be avoided due to being not reliable.

• Tesla (Capability)
• Forge one (Capability)

Nice to have

Not necessarily capability based, but should be usable as soft dependency.

• IC2 EU. Not a capability, but due to its design it should be possible to instanciate a different object like a null object should the API not be present. So likely no stripping of methods. Not that commonly used anymore.

Unlikely to be supported

These will require us to keep our own method stripping or switch to @Optional.
This should also allow us to drop the core mod.
Might be an idea to support them as second class member just with the energy acceptor, but no other tile entity.

• RF. Same interface based approach since forever. No Caps. Hard dependency.
• Mekanism. Same as RF.

Mekanism's Universal Cables use Joules, correct? That might be good.

Mekanism attempts to convert between RF, EU, J, and I think it started supporting Tesla when it came out. Mek should be covered by Tesla compatibility.

@yueh Nah it's not as easy. We need to call super.drawSlot(..), but without renaming the original method that's not as easy. IIRC we cannot call super-methods via Reflection.

Is Tesla a new thing?

We can't drop the core mod currently due to using it for exposing drawSlot in ME containers.
We could copy the entirety of the vanilla rendering there, but if possible, we should avoid it.

If you mean the one changing the visibility, than that is completely obsolete and can be replaced by a simple access transformer to hand it over to forge. It was never really changed because it works and iirc ATs were not even a thing as the development of AE2 started.

Thus we pretty much just need the core mod for stripping methods.

Yes, it is probably the first capabality based energy system. Or at least the first one being mostly used by tech mods even if that is still not a huge number. The alternatives were usually custom ports of RF or their own old energy system based on interfaces. You could argue about some issues like using long and some idiot will make a mod producing 2^63 T/tick. But who cares really. RF by itself is more or less completely unbalanced.

Then there is the forge energy system, which is basically a straight port of RF to be capability based, but made as worse as possible. Like no separation between receiver and providers anymore. No canConnect() anymore for the mods desperately needing it, etc.

Injecting power into something is probably something like for each operation.

if( te.hasCapability(ForgeEnergy, side) ) {
  val cap = te.getCapability(ForgeEnergy, side)
  if ( cap != null && cap.canReceive() ) {
    cap.receiveEnergy(amount, simulate)
  }
}

It might be possible to cache the cap locally and like hope every other mod out there does send a neighbour update everytime the configuration changes and it no longer exports the cap on this side. But this is modded minecraft...

@shartte Maybe. I just remember the core mod doing 3 things

1. Method/interface stripping
2. access transformer
3. patching 2 minecraft core classes

1. Should really be avoided to make it easier. Or if moving it to @Optional but that means absolutely no generics. 2) Can just be moved to a access transformer file, can even change final when needed.
   Pretty much just leaves 3), something we should consider removing when possible via other means. Maybe forge hooks are now a thing, whatever.

@yueh I'd prefer access transformers too, and briefly considered them for drawSlot. I wasn't sure at the time whether they actually would affect the decompiled sources or not. All content on access transformers seems to have vanished from the net (the wiki disappeared), and the Forge forum is riddled with posts that state "don't use ATs!"... Discouraging...

Right now massive banks of Vibration Chambers are required to power even a small AE system, let alone a large one. Personally, I think that this issue should be focused on. At the moment, RF is used by most mods, so it would make sense to support it even if only for a few months,

Actually, scratch that. There are mods such as Energy Synergy that allow conversion between RF and Tesla, only really requiring Tesla to be supported.

is ender io using tesla? i got the rv4 version of 1.10.2 and i cant get energy in the controller (enderio end Ie doesnt work). i think tesla is the new rf because everyone is using it

It's not implemented at the moment, that's why you couldn't get it in to the controller.

Energy Synergy only converts from Tesla/Forge energy to RF or EU, not the other way around.

Do we already know what we can use to test each of the energy systems?

So, which mod implements the forge energy system? Which mod implements Tesla?

Enderio was an early adopter of forge energy (and Rf ofc)
Mekanism has joules as it's native power
Industrial craft 2 has eu exclusively
Iirc telsa has an API mod that is designed to be utilised by other mods as
their power API to alleviate the need to code a power system themselves and
to attempt to unify power in modded mc.

I'm sure there are more but those are the ones I can think of at the
moment.

On 19 Oct 2016 5:50 am, "shartte" [email protected] wrote:

Do we already know what we can use to test each of the energy systems?

So, which mod implements the forge energy system? Which mod implements
Tesla?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2438 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADeu1cwPyrtUDT4kOg0XjCLaMbIuH1QDks5q1T8WgaJpZM4KOMhr
.

Telsa = tesla

On 19 Oct 2016 8:43 am, "Troy Scorer" [email protected] wrote:

Enderio was an early adopter of forge energy (and Rf ofc)
Mekanism has joules as it's native power
Industrial craft 2 has eu exclusively
Iirc telsa has an API mod that is designed to be utilised by other mods as
their power API to alleviate the need to code a power system themselves and
to attempt to unify power in modded mc.

I'm sure there are more but those are the ones I can think of at the
moment.

On 19 Oct 2016 5:50 am, "shartte" [email protected] wrote:

Do we already know what we can use to test each of the energy systems?

So, which mod implements the forge energy system? Which mod implements
Tesla?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2438 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADeu1cwPyrtUDT4kOg0XjCLaMbIuH1QDks5q1T8WgaJpZM4KOMhr
.

So I did an early integration with Forge Energy, but I have to look into what the conversion ratio will actually be. I am unsure if it:s 1:1 with RF or not. I hooked up an EnderIO generator and have yet to figure out if EnderIO applies any conversions

Added Tesla energy API support with conversion ratio equivalent to RF.
Tested with EnderIO (Forge Energy disabled), with and without the Tesla API actually being present. Seemed to work well.

Oh btw. This currently doesn't mean that the P2P RF Tunnel works, this is just for the energy acceptor. The P2P Tunnel is still to come.

Woo for killing RF: one mod at a time!

Forge Energy is 1:1 with RF and Tesla. EnderIO supports RF, Tesla, and FE atm. Here's a pretty well updated doc of current mods and energies they support.

RF killing is mostly due to use wanting to dump our custom method stripping and maybe replace it with @Optional when absolutely necessary. But otherwise we should either use caps or something which allows using delegates/proxies to be use and we can simply use a null implementation once the mod is missing.

Especially as @Optional as well as @SideOnly immediately fails once you use things added after java 1.4. Which are certainly more widely used in 1.8+ compared to 1.7.10 times. So we do not want to be in a situation, where we dumped our own handling months ago and suddenly some popular mod appears requiring to still use method stripping but @Optional is simply not feasible for it.

RF will live on as a universal unit of energy, which is the most important part I think.

RF just doesn't make sense to use anymore. Either use Forge energy (which is exactly the same as RF, but uses caps) or Tesla (which functions like RF but is easier to use). RF simply has no place anymore

Sure RF has a place, it was and still is the golden standard of Minecraft energy. Just the API is outdated and hard to keep constant because the original creators aren't focusing on it anymore.

I am not sure if the link in the readme is the most recent nightly or if I have to change some configs so this woks but for some reason none of those cables transmit power. I changed default energy of Mekanism to Tesla and am using the most recent version of all shown mods. Using appliedenergistics2-rv4-nightly-41b875 on a server ( I didn't want to open a new issue since this kind of thing was already reported and closed )

edit: Your nightly is outdated (a lot). Please download a newer version from the nightly link on the front page (https://github.com/AppliedEnergistics/Applied-Energistics-2)

Immersive Engineering is currently not supported due to it not supporting any capability based energy system.
Do you have the Tesla API jar inside your mods folder?
p.s.: If EnderIO doesn't connect, you dont have the latest EnderIO version.

I updated my modpac exactly 2 days ago including EnderIO. Tesla API is installed. ( also I just tried all available cables in the game so I didn't expect it to work. ) Thank you for your quick reply! Didn't know my link was outdated. I used the one in the readme file.

I'm thinking this is a problem with AE. I've heard others say it wasn't working with tesla as well.

@ProfessorProspector I tested it with Tesla, and it did work. The most common reasons I've seen so far for this not working:

• Assuming that having the other Power mod and AE2 in the mods folder is enough. The Tesla API JAR file is always needed.
• Using an outdated AE2 nightly

If all else fails, there's always Teslafied :P - I added AE2 support the same day shartte added Tesla support to AE.

Well, not sure you still need to advertise adding Tesla to AE2 in teslafied :P
But, Teslafied solves the problem of accepting power from Immersive Engineering.

Started working on IC2 integration here: https://github.com/AppliedEnergistics/Applied-Energistics-2/tree/ic2

I will close this now that IC2 is supported at least for accepting power. The status of implementing the IC2 P2P tunnel is tracked in #2523