Hi,

Here is an use practical case with a furnace consuming 3 EU/ticks while the battery is providing 22 EU/ticks. They are linked through an 32 EU -> step up -> 128 EU with some cables -> step down -> 32 EU :

So it look like the transformer which do the step down is always asking energy packet even if its internal buffer is nearly full, which produce many little energy packets on the 128 eu line and create a massive power lose.

Is there a repo to get the sources of the mode and fix it ?

Ach :/

So to understand it, what would be the issue in the following case :

An 128 EU to 32 EU step down implemented as following
512 internal EU buffer
Input of the transformer accept energy packets only if the internal buffer is lower than 384
Output of the transformer are feed by the internal buffer

Is it the input's state changing between accepting and refusing energy packet which make issues/lags ?

yeah that would work but then again thats 1 thing. What if you dont use transformers?
On top of that all machines would have to support that type of system or allow overflow.
Also what if the machine has not enough powerstorage to do that type of thing?
Also UI things in machines would fuck up.

I'm not sure we are talking about the same cases.
Here the idea is to make transformer non continuous energy sink (in contrast to, for example, electrical furnaces)
By this way you can create high EU power line only connected via transformers without having the down sides of continuous energy exchange (which create high power loses at low power usages)

Make that without the transformers and you have the same result. Because transformers just try to transfer 32EU but only 3 EU gets consumed. thats the issue. The transformer is just a relay that you found it on.

Yeah thats a known issue. The thing is when i fix that i cause 5 other bugs that are far worse then that.
GregoriousT (gregtech dev) and i had a 2 days talk about it discussing how to fix it and whenever we thought we found a solution a worse bug came up where the player would create either power out of nothing or causes incorrect calcuation or massive lag into servers when used in mass. So we decided to leave it since its the most stable system and it only causes higher power consumtion on passive electric usage (AdvMachines) or bad cable placement like your cable. But the more power you use the lower that gets.

It's not about solving everything, but making transformers able to create efficient power transmition networks.

I modded a transformer with the API and get very good result with the following (scala)

  override def getDemandedEnergy = {
    val rate = if(stepDown) highRate else lowRate
    if(bufferSpace >= rate) rate else 0   //bufferSpace mean how much of the buffer size is currently not used
  }
  
  override def getOfferedEnergy = {
    val rate = if(stepDown) lowRate else highRate
    if(buffer >= rate) rate else 0
  }

in contrast of the current IC2 implementation :

    public double getDemandedEnergy() {
        return (double)(this.maxEnergy - this.energy);
    }

    public double getOfferedEnergy() {
        if (this.getActive()) {
            if (this.energy >= this.highOutput) {
                return (double)this.highOutput;
            }
        } else if (this.energy >= this.lowOutput) {
            return (double)this.lowOutput;
        }

        return 0.0D;
    }

Because thats not fixable how you think.

It's all about topology, and how i have shown you is currently working well on my fork.
Ok it desn't fix all the issue, but at least it make possible high EU per packet power transmition lines without high power loses at low usage.

The only thing to change is to make the transformer input not asking energy until their buffer can accept a full packet. By this way they will not constantly sink small EU packets

@Dolu1990 the thing you posted doens't solve the issue in the sligthest.
In fact it provides a new set off issues: The buffer no longer gets fully filled in the slightest. Once the output max is reached the buffers stays there. Your fix requires that you push 256EU packets on a 128EU line to fill up the buffer of the Transformer fully. But with your methode the LV Transformer will be max on 159EU out of 256EU storage. And don't forget that the LV-Transformer outputs up to 128EU per game tick so the thing when in high usage either accepts or don't accept things, this can cause that the second idea of the Transformer as packet combiner to a certain extend is destroyed.

You can keep your patch. But it won't make it into IC2Classic for the reason that it can cause bigger issues.

@ The buffer no longer gets fully filled in the slightest
It's not an issue (at all)

@ Once the output max is reached the buffers stays there
Until an consumer ask for some EU

@ Your fix requires that you push 256EU packets on a 128EU line to fill up the buffer of the Transformer fully
Currently in my setup the LV transformer has a 512 EU internal buffer, then it take 4 packets of 128 EU to fill it. I made it bigger than 2 full packets (2*128) to be sure it survive some energy jitter on the input without impacting the output energy flow.

@ But with your methode the LV Transformer will be max on 159EU out of 256EU storage
What do you mean ? Just to get in sync together, in my methode, in the case of an step down 128 into 32 EU, with an internal buffer of 512, the transformer will not ask inputs if it's internal buffer is higher than 384, and will not offer EU packets if it's internal buffer is lower than 32

@ And don't forget that the LV-Transformer outputs up to 128EU per game tick so the thing when in high usage either accepts or don't accept things
?

@ this can cause that the second idea of the Transformer as packet combiner to a certain extend is destroyed.
In my setup, transformers will only offer full packets else nothing.

@ But it won't make it into IC2Classic for the reason that it can cause bigger issues.
Still i don't see any issues to this patch, maybe we are not talking about exactly the same thing.

@Dolu1990
Well according to your logic the Uptransforming doesnt work at all.
Because it isn't requesting any energy.

  override def getDemandedEnergy = {
    val rate = if(stepDown) highRate else lowRate
    if(bufferSpace >= rate) rate else 0   //bufferSpace mean how much of the buffer size is currently not used
  }
  
  override def getOfferedEnergy = {
    val rate = if(stepDown) lowRate else highRate
    if(buffer >= rate) rate else 0
  }

If it is a stepUp then the input amount is only 32EU but the output is 128EU that means unless you get more then 32EU input power which make it explode you can not output power backwards.
About forward you can only accept the amount of power that is the input amount * 2 - 1
(Input = 128EU Max Buffer EU Buffer Usage: 255 EU ((128 * 2) - 1).
because it will accept only when the energy is lower then 128 EU. And since it max can accept 128EU thats 127 + 128 in the best scenario.
For Upscaling thats 63EU (31EU + 32 EU). That means not enough power to make this happen.
Yes you could make a special rule for upscaling but here is hte issue: ITS NOT FIXING YOUR ISSUE!
Its moving it to the generators

  override def getDemandedEnergy = {
    val rate = if(stepDown) highRate else lowRate
    if(bufferSpace >= rate) rate else 0   //bufferSpace mean how much of the buffer size is currently not used
  }

Let's take a practical case for the above code =>
bufferSize = 512
highRate = 128
lowRate = 32
stepDown = true
buffer currently used with 0 EU => bufferSpace = 512
=>
val rate = 128
if(bufferSpace >= rate) is evaluated as true which mean that the function will return 128 (rate)

Now the same case with stepDown = false
val rate = 32
if(bufferSpace >= rate) is evaluated as true which mean that the function will return 32 (rate)

If it is a stepUp then the input amount is only 32EU but the output is 128EU
There you go with the IMultiEnergySource API interface to handle 4 packets per ticks via the getMultipleEnergyPacketAmount

About forward you can only accept the amount of power that is the input amount * 2 - 1
Why this limitation ? Batbox doesn't have it, so why transformer would have it ^^ ? I think this is the most important point. When i'm talking about 'buffer' i'm talking about a dedicated internal buffer into the transformer, implemented very similarly than the batbox one.

ITS NOT FIXING YOUR Its moving it to the generators
I think you are missing some shade of gray. Managing the cable length to be short on the generator/consumers side to avoid EU drop on cables is realy easy, but managing to have a short cable between two buildings/bases is just impossible, by design.