EU capability ??

NEVER. EVER. LISTEN. TO. ANYTHING. LEX. SAYS.

Lex ruins Forge since years, and the capability System is a part of the garbage he allowed to happen, seeing how terribly laggy it was implemented.

The shit he does is one of the primary reasons I am still on 1.7.10, and that I will leave MC after I am fully done with GT6.

Last time I checked you had to iterate through all Capabilities until you find the right one for example, dont you think that might be a teeny tiny bit on the laggy side, especially if you have to do that every tick with an energy network, because of not being notified when a tileentity got unloaded?

The more capabilities a TileEntity has the more time it will take to iterate through all of them to find the right one.

Quote from loordgek

that can be solved. TEs need to markdirty when they change cap

Not only our tes would need to do that, but also other people's tes. That would slow things down as well.

Another reason why there's no point of moving to capabilities is because our api is not less dynamic than capabilities and is easier to use.

Quote from loordgek

i can just froward caps from a different te and not knowing what the cap is, can i do that w/ the EU API ?

I don't know why you would want to do that, but yes, of course you can do that.

Quote from loordgek

easier to use??

than "hey TE do you have cap x on side y"

Asking the te "Do you have this capability" is as easy as asking the enet whether that block is a energy tile. Implementing the energy tile logic is easier with our api than if it was a capability.

Quote from loordgek

but i dont think you/other change caps every tick

They don't. They shouldn't. But we need to check every tick to make sure. A TileEntity can switch between accepting energy and not accepting energy anytime. With the tileentity not notifying us, we need to ask every single tileentity every single tick.

Quote from loordgek

so the cap needs to be told when caps are unloaded/destroyed ??

No, but we need to get notified because of the above problem.

There's are 3 problems to solve with energy net integration:

1. Getting the IEnergyTile object (sink, source or conductor)

2. Knowing when it becomes valid (put/loaded into the world)

3. Knowing when it becomes invalid (chunk unload/block break)

Usually mods do (2) and (3) through neighbor notifications and polling, their cables try to detect when an adjacent grid participant appears or disappears. This is usually broken with chunk unloading, but more importantly IC2 doesn't necessarily own all cables. We allow addons to provide their own cables, so there's possibly not a single IC2 native tile entity in a grid that could detect changes.

Capabilities can't do (2) nor (3), they just solve (1) somewhat. Forge's capabilities don't receive any such notifications they can forward, neither do we get any suitable global events when a capability holder loads or unloads.

The obvious solution is to notify the energy net from TileEntity.onLoad(), .onChunkUnload() and .invalidate().

However once you do that, you may as well include the IEnergyTile object in this notification, i.e. tell the energy net that IEnergyTile x has been loaded or unloaded. As a result it's no longer needed to query the tile entity for x. The capability system is what handles that query, no query = no point in having a capability.

Since MC 1.7.10, IC2 supports x being an arbitrary TileEntity instance that implements IEnergyTile, whether it is the the in-world TE or not. All that matters is that its position and world are set correctly and someone tells the energy net about loads/unloads to determine the liveness. In later MC versions x can implement ILocatable instead of extending TileEntity, making this leaner and more obvious.

Overall there's nothing to gain from a capability. The delegate support during registration already provides everything needed to interface with IC2 without implementing the IC2 API in the actual TileEntity class. Either way the "annoying" part is funnelling the load/unload notifications to IC2.

An example integration implementation may work like this:

- TileEntity.onLoad: call Integrations.onTeLoad(this)

- TileEntity.onChunkUnload: call Integrations.onTeUnload(this)

- TileEntity.invalidate: call Integrations.onTeUnload(this)

- Integrations.onTeLoad: call availableIntegrations.foreach(x -> x.onTeLoad(te))

- Integrations.onTeUnload: call availableIntegrations.foreach(x -> x.onTeUnload(te))

- IC2Integration.onTeLoad: call EnergyNet.instance.addTile(new Ic2ProxySink(te))

- IC2Integration.onTeUnload: call EnergyNet.instance.removeTile(EnergyNet.instance.getTile(te.getWorld(), te.getPos())) if getTile didn't return null

- Ic2ProxySink implements ILocatable and IEnergySink similar to BasicSink, but accesses your own energy buffer in the real te instead of being a stateful battery. I'll probably add another class to simplify this.

I bet you, lex is gonna try to even PREVENT that from being fixed.

Good luck.

BasicSink and friends have some example code in their Javadoc. To make the example code independent of IC2, all code accessing IC2 needs to be moved to a separate class and the field type needs changing to Object. The field can be also omitted by fetching the instance from the ENet as needed like in my IC2Integration.onTeUnload example does above.

I've just pushed some changes to Jenkins that make Basic* more easily usable as Proxies. Overriding the energy storage setter+getter and the capacity getter allows to directly access an energy buffer in the parent tile entity.