https://i.imgur.com/dv3PHcf.png

This transformer has been there for more then long enough for its internal buffer to have filled by now, yet it's still consuming all of the EU it can take. It has an on lever underneath it, as well.

There is a fairly long (roughly 100-150 blocks) iron cable leading out from it, but that cable is nowhere near long enough for the loss to be this high.

Ok this is a feature that is really cool to me.
And it requries thought to be understood and fixed.

Let me explain this:
Iron Cable uninsulated takes 1EU per block. 4x Insulated its 0.7-0.8EU.
So your loss is between 100-150EU over your distance.

So whats the "Supposed" issue.
The issue you have is that the storage on the other side is full.
EnergyReceivers can accept part of a EnergyPacket if their power only needs parts of it.

So lets say our buffer needs 5EU on the other side and you have this 150EU loss cable per packet.
You pay 155EU just to send 5EU over and that every time.
The solution to your problem is to implement a switch that will not break the connection if the loss would be worse.

TL:DR the less you use per game tick the worse the loss gets. The more you use the less loss affects you.
Thats why you should make it 1x 2048EU packet instead of 4x 512EU packets to send over such a distance because you save much more power because its -3 loss calculation.

TL:DR not a bug a design feature.

That... is indeed a rather interesting feature, though I feel that that's something that should be documented somewhere. That's a big difference from how things work in any version of IC2, which will only send a packet if the destination can accept the full packet, and never send before then, from what I understand.

It's also something that'd be pretty trivially solved by just setting a batbox at the other end to emit redstone when not completely full, then put a cable splitter immediately adjacent to it. Not sure that forcing the player to add that to every destination on a long central cable is really something that improves the game.

@abculatter2. No this is a feature from 1.4.7 IC2. Greg and I looked at the code and found out that it was always like that. Experimental actually changed that in later versions. (The API lied for a long amount of versions)

I just kept that feature. Fixing it is either "Overcharge" or have progress bars go down and up etc. Which i kinda don't want because it can lead to confusion. So it stays like it is.

Accepting a 'packet' of overcharge would make sense, after all it happens in real life too because of inductive loads on the wire itself not even considering the machinery consuming it.