• What is the bug? Glass Fiber cable connector holds a charge of about 8,000 EU
• What did you do to make it happen? Connect glass fiber cables from IC2 to relays and then a connector. I noticed this because I was using luminators, and when the energy ran out the light didn't go out.
• Does it happen every time you do this? Does it happen if you do something else as well? Yes and Yes
• Did this happen on a dedicated server (multiplayer servers), in LAN multiplayer or in singleplayer? Server (but I think single player too)
• What other mods were installed when the bug happened?

- applied-llamagistics-1.11.2-rv5-beta-1
- buildcraft-7.99.7
- car-1.1.2
- cfm-4.1.3-mc1.11.2
- CompactSolars-1.11.2-5.0.12.333-universal
- ComputerCraft-SquidDev-CC-ComputerCraft-feature-minecraft-1.11.2-1.80pr1-build0
- coroutil-1.11.2-1.1.19
- energyconverters_1.11.2-1.0.1.22
- FloodLights-1.9.4-1.2.8-151
- ImmersiveEngineering-0.11-63
- industrialcraft-2-2.7.85-ex111
- IndustrialWires-1.5-19
- RebornCore-1.11.2-2.16.1.115-universal
- StevesCarts-1.11.2-2.3.0.22
- weather2-1.11.2-2.5
- worldedit-forge-mc1.11-6.1.6-dist
- Xaeros_Minimap_1.14_Forge_1.11
- applied-llamagistics-1.11.2-rv5-beta-1
- buildcraft-7.99.7
- car-1.1.2
- cfm-4.1.3-mc1.11.2
- CompactSolars-1.11.2-5.0.12.333-universal
- ComputerCraft-SquidDev-CC-ComputerCraft-feature-minecraft-1.11.2-1.80pr1-build0
- coroutil-1.11.2-1.1.19
- energyconverters_1.11.2-1.0.1.22
- FloodLights-1.9.4-1.2.8-151
- ImmersiveEngineering-0.11-63
- industrialcraft-2-2.7.85-ex111
- IndustrialWires-1.5-19
- RebornCore-1.11.2-2.16.1.115-universal
- StevesCarts-1.11.2-2.3.0.22
- weather2-1.11.2-2.5
- worldedit-forge-mc1.11-6.1.6-dist
- Xaeros_Minimap_1.14_Forge_1.11

This is somewhere between "bug" and "intentional". I know they store that much, and I meant for them to store that much, but it isn't ideal. You will probably get similar issues with IE if you take an HV connector, use a transformer to step the voltage down to LV and connect the LV to an electric lantern. I don't think it's possible right now to tell the IC2 net that there is a "magical" connection between non-adjacent blocks, but I'll look into it.

@malte0811 If I use the transformer it doesn't hold a charge (or at least a very little charge). I don't think the glass fiber relay holds the charge, but the connector does. I would be fine with it having a smaller internal storage because if there is a blackout, I want the lines to act as power lines instead of capacitors.

If you connect a batbox to an EV transformer and connect that to a luminator the same thing will happen, but twice as bad (16k EU storage). Chocohead (IC2 dev) didn't seem to consider this a bug. There isn't much I can do about this (with the connectors) on my side, the only solution I can think of would request energy, but potentially consume none, which isn't permitted according to the IC2 API documentation.
Is there a reason you are using glass fibre wires on something that would work with tin just as well?

In theory you should be able to use a "multiblock" cable with a subtile at each end to directly link locations, i.e. an IEnergyConductor implementing ic2.api.energy.tile.IMetaDelegate. It'll make the locations appear as one in the connectivity graph, thus probably doing exactly what you want.

Note that this is rather untested territory, but I'm willing to fix any issues besides the current limitation of all sub-tiles having to be in the same world.

I haven't tried this yet, but from what you said the net would consider them all to be the same/have lossless connections. Is that right or did I misunderstand something? I'd like to keep losses since the wires are meant to be mostly equivalent to the normal cables.

@malte0811 I use glass fiber cables because I created a city and use powerlines to distribute the EV current to businesses and homes.

It's not lossless, but acts as a single piece of conductor with its associated loss. For distance based loss it'd be up to you to calculate that loss and return it from IEnergyConductor.getConductionLoss(). This is obviously only accurate for 1:1 connections, i.e. a single link, so you'd need to do some trickery to handle wire attachment points with multiple destinations.

I played around with IMetaDelegate for a bit. It would be perfect if I didn't need the losses. For losses to work I'd need to know how much energy was transmitted through which subtile, and I'm not sure how good the loss system would be with just that info.
I have an alternative idea, but I don't know how feasible it is since I don't know how the IC2 net works. From the documentation of IEnergySink:

Make sure that injectEnergy() does accepts energy if demandsEnergy() returns anything > 0.

Why is that required? If that condition wasn't there I could limit the buffer size to the amount parameter of injectEnergy. That way there shouldn't be more than a one-tick delay compared to ideal cables. And how much energy do I need to accept for it to work (IE returned 0 when the IC2 compat was in there, don't think it caused any issues in 1.7.10)? Would something like 10^-6 EU/tick work? That would consume one EU roughly every 14 hours, which should be acceptable in most cases, and the value should be big enough to not cause too much floating point trouble.

The problem is that a connector does not have a fixed length of wire attached to it, with a single other end. It has a graph that can be as complex as it wants to be, it can serve as an input for both an output one block away (mostly lossless) and a connector 1km away (very lossy) at the same time. Unless it is possible to have one block in multiple meta delegates (so one delegate for every pair of connectors, I haven't tried that yet) I don't see how I can do this without handling losses myself.

I think the best workaround for connections that aren't 1:1 with the present API is building dummy clusters above/below the world. E.g. if you want to connect point A to the points B, C, D you'd go from A to the out-world node H with zero loss, then add dummy nodes I, J, K adjacent to H and go from I to B, J to C, K to D with each pair using the correct loss.

Support for more than one node per block with extensive connection rules and loosening the tight block-location coupling will come at some point, but not in the near future.

I thought about using dummy nodes outside of the normal building range before, there are 2 issues with that idea:

1. It would cause issues with CubicChunks (not too important, but I'd like to keep compatibility).
2. It is not easily possible, and it will break if anyone else does it. There isn't any reasonable upper bound on the amount of connections one connector can have (~32k for connections with just one relay in between (this is the theoretical upper bound, but more than 6 is reasonable in practice)), so I'd have to make (potentially) large clusters for each node. I'd have to keep track of which places I'm using for this already and I'd have to make sure there is enough space when adding a new fake node (which is more work than I'm willing to put into fixing a minor bug). And if someone else starts using the same positions for similar things everything will break.

You shouldn't need to know the energy if you provide a lossy IC2-style conductor. The conduction loss in IEnergyConductor is typically a constant that only depends on the type and in your case the length, much like Ohms, not the power/energy. For a GF wire this would be * 0.025. Turning that loss value into actual energy loss depends on the active ENet implementation. The default uses the classic "absolute tax" model to encourage up-transforming, different code treats it as actual resistance , thus dropping P = I² * R EU/t with R being the total path loss.

The handling of energy rejected by injectEnergy is quite tricky and almost always biases the results compared to matched inject+demands. This energy has to be rerouted to other sinks or back to the source, taking losses into account - all appearing as if there wasn't too much energy to start with.

Any double value less than the supplied amount should make potential asserts happy, the potential delta can be much smaller than 10^-6.

This didn't work as intended in some cases. Connectors would still blow up when connected to a "matched" source (e.g. tin wire and a batbox) using a cable (but not when connected directly). I assume this is because the IC2 net does not appreciate the connector accepting very little energy. I don't know whether this counts as an IC2 bug, if it does I'll try implementing this again once it is fixed.

I appreciate all of the work you are doing on this :)