EU capability ??

    • Official Post

    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.

    • Official Post

    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.

  • Worst Idea ever... It will hurt performance in every single way and also breaks the EU network...

    On top of that Capabilities doesn't have to be persistend. The Enet relies on Relyability... Which capability can't provide

  • Quote

    On top of that Capabilities doesn't have to be persistend. The Enet relies on Relyability... Which capability can't provide

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

  • because our api is not less dynamic than capabilities and is easier to use


    explain


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


    easier to use??


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




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

    but i dont think you/other change caps every tick

    because of not being notified when a tileentity got unloaded

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

    • Official Post

    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.


    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.


    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.


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

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

  • Basically capabilities make with a EnergySystem Processor like IC2 has it no sense at all. It actually makes the System slower,
    more complex, and more likely to break. Since its a Global Manager that handles everything about EU.
    RFBased Systems dont work that way. Each individual part in a RF System processes its own little thing, which is actually more havy then a Global manager. Even if the Global manager is poorly written...


    Its overall less to process, more stable and has a lot of upsides to it. I am wondering why RF is not using one for their system. Because RF would benefit more then EU out of a Global Manager System.


    But yeah capabilities would bring in only more instability thats all what it provides, nothing based of Uniqe freedome, its actually less freedom for the person who handles the EnergySystem and is not a user of the build System...

    And the User can use a Interface the same as a Capability. Forge even adds systems that allow you to make interfaces more worth then Capabilities.

    • Official Post

    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.

    • Official Post

    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.