http://mod-buildcraft.com/forums/index.php?topic=3538.0
Not necessarily a bug in a way as perhaps it is intended. But I think it would be nice to minimize strange loop oddities.

Back in the day it was mean of storying power now it can cause power voiding.

:D
I use them as a really low-tech energy storage.

2015-03-02 17:39 GMT+06:00 RagaRBM [email protected]:

http://mod-buildcraft.com/forums/index.php?topic=3538.0
Not necessarily a bug in a way as perhaps it is intended. But I think it
would be nice to minimize strange loop oddities.

—
Reply to this email directly or view it on GitHub
#2521.

@asiekierka I think energy system you rolled back is allowing for energy looping.

Inviting @CovertJaguar

@Kubuxu - is that a bad thing?

@Kubuxu - the algorithm, at this point, does not lose excess power, and the energy buffer in the pipe is /theoretically/ infinite (two sets of six sets of 2 billion RF - or 24 billion RF - per pipe) - however, making overloaded power pipes explode in the same vein overloaded item pipes do (only destroys its own block) might be a good idea to prevent lag, overflows making energy go negative, etc.

@asiekierka this way.you are breaking perfectly correct power systems that.are currently existing.

And also IIRC energy loops were major reason for energy system rewrite back then.

How do we limit the flow of power through pipes with lower capacity? I thought the buffer size and power capacity was closely linked.

In general, I believe the "overload" rendering should be changed to reflect if a pipe is actually overloaded (that is, the internal power buffer is at its peak), and not whether it is used at full capacity (which is the normal thing for a pipe to do). What do you think?

The only downside to energy looping is that it reduces the total energy throughput through the looped section.

The cpu cost is identical for loops as non-loops. Power flow is a constantly applied function that it applied to every pipe, every tick.

The amount of power in a pipe should be capped. I'm not aware that its infinite or capable of causing integer overflows, but I could be wrong. I'm pretty sure the power flow limiters would prevent this.

The "overload" state exists as a simple feedback to let people know that things on the other side of the overloaded pipe are requesting more power than the pipe can provide.

Having it display the pipes "internal buffer" is really kind of pointless because the user gets no benefit from knowing that, its a transient state that has no impact on the operation of the network. "internal buffers" are a implementation detail, not a gameplay mechanic.

@CovertJaguar - isn't it already capped at the pipe's maximum RF/t transfer rate per side?

@asiekierka Is what capped? I don't understand the relevance of the question.

waht if the ability for a pipe to accept new energy was related to the
amount of energy already in it -- powerInflow
_((floor(3_maxStorage/currentStorage,1)
that way a power loop can be used with power up to a moderate level, then
after that it slowly stops accepting energy, without going near integer
overflow, but still buffering a few kilo-mj, and it would allow a sensible
buildup/release mechanism to spiky power draws distant from the main power
generators.

On Sun, Apr 12, 2015 at 3:15 PM, CovertJaguar [email protected]
wrote:

@asiekierka https://github.com/asiekierka Is what capped? I don't
understand the relevance of the question.

—
Reply to this email directly or view it on GitHub
#2521 (comment)
.

“Getting information off the Internet is like taking a drink from a fire
hydrant.”
– Mitchell Kapor