[feature request] EHV power transfer lines

[theunkn0wn1]

So i had noticed that HV power has an poorer power distribution range than MV, 20 chunks till 100% loss, and thought that a true long-range power transfer cable from IE with high transfer rate with a low decay rate would be well suited. in the config it noted that HV was intended for Long-range transport, yet the effective range for HV cabling is only 10->15 chunks (50->75% power loss). This limitation makes it impractical for true long-range power transportation, such as powering a quarry 50+ chunks down a railway, as the power would drop off completely well before it would reach the quarry. The railway chunks would all ready be force-loaded by Railcraft anchors for the quarry+railway to be functional to begin with, so why not have IE power cables that can bridge the gap?

IRL, the higher the voltage the less power loss occurs, exponentially. This can be modeled with f(V)= R^2/V^2 when V = input voltage and R = cable resistance That is why power mains irl are so high voltage, because its cheaper and more efficient.

Based on how you are currently modeling power loss over distance, the power throughput (RF/connection) is not even put in consideration, you are currently using a linear power decay model. the only factors that make any difference based on what i can derive are the max cable length and the linear resistance value. Your current power model can be represented as below: ΔP=B-max(min(B*(X/LR))) or ΔP=B-max(min(X/LR),B^2),0) where P = output power, B is input power, X is distance, R is cable resistance (a fixed linear value),and L is max cable length (per connection)

So why is it that HV has a significantly higher power loss, twice to be exact, than MV if it is intended for long-range transport? HV travels 320 meters (20 chunks) at 100% power loss MV travels 640 meters (40 chunks) at 100% power loss These numbers are based on default config values and experimentation to validate the functions stated above. MV can transfer power over the same distance that HV cannot transfer any.

By adding an EHV tier of power, one designed only for the long-range transport of power (20+ chunks) IE would become even more practical for big bases and big builds alike

[BluSunrize]

Instead of adding EHV I should probably just buff HV to work like it was intended all along, shouldn't I?

[theunkn0wn1]

that would work too :P I calculate if HV had a resistance of 0.02 and a max cable length of 32, it could reach 100 chunks to 100% loss of it had 0.01 resistance instead, it would reach 200 chunks to 100% loss.

[bakaxyf]

Immersive Integration have similar request. https://github.com/UnwrittenFun/ImmersiveIntegration/issues/26

[theunkn0wn1]

Similar, but for a different function. UnwrittenFun/ImmersiveIntegration#26 wants a EHV line for consumers, filling a void that does not exist(IMHO). One can simply trunk HV connectors through one line to get the same effect. Power transmission in IE is limited per connector rather than per line.

By adding an EHV cable that is of higher than HV transfer rate, such a cable would be more efficient at transferring the power,therefor go longer with less decay, but would need to be stepped-down before it should be able to be consumed.

What i am asking for is a line capable of long-distance power transmission, and IRL HV is the way to go. Since HV exists in IE as it stands, and i am assuming that the default config is where @BluSunrize wants it, i am asking for a higher tier transport line that would satisfy long range transport.

[mindforger]

well ... and i think people gonna kill me for that ... how about ... making transformers REQUIRED by removing the HV connectors ability to be placed whereever you want, with something like a whitelist where to attach and where not, so IE machines with HV capability can attach HV connectos only, and some other known mods could be added by default :D and a modpack designer can decide on it's own where allowed and where not ... man i can hear @XFactHD swearing from here when this get's ingame and is breaking his connections all over again XD

[theunkn0wn1]

@mindforger Yeah, tried to bring that up before, IIRC @BluSunrize did not like the idea, something about such an action would make IE incompatible with every other RF mod.... I like the idea, and i am totally for it.

Anyways. @mindforger it seems you are getting off topic.

[mindforger]

yeah i forgot to direct my offcourse back to topic .... and when this is done, you can completely remove or greatly reduce the power loss, as it would not get OP ... PS i do not want to make it incompatible, just a bit more challenging to connect

[BluSunrize]

It doesn't work like that though If you use transformers, you'd be dealing with a line that can transfer up to 4096RF/t, but will onyl transfer 256 because a part of the connection operates on a low level.

I hate to admit it, but IE's power system really isn't that great. I'm kinda frustrated with itself and I'm open for input, .~.

[theunkn0wn1]

I have run some numbers with a homegrown script, keeping the existing HV Cables properties and only replacing the resistance value for it to 0.01 would yield a better (imho) distribution range of 200 chunks (3200 meters) to 100% loss, leaving an effective range of 100 chunks (1600 meters)

Assuming cable legnth and power throughput remain constant:

Resistance value	max range (in chunks till 100%)
.01	200
0.0075	266.6875
0.005	400
0.0025	800

@BluSunrize When i imagine what IE's power grid should be, it is not exactly what i see. I have noticed that if one Steps-down the HV into MV current, then imediatly steps it back up to HV, most of the power is lost. From my understanding on how your mod works, it checks to find the lowest tier of transport along the chain from point S to point R, and limits the rate into which it transfers power to that lowest tier. I feel this is poorly done. When IC2 power is stepped-up/down it splits or combines packets of power before sending it along. By doing this, power is not wasted to such a large extent in the transformer, though some is (IRL this occurs as well). If IE's transformers worked the same way, sending the RF in the form of RF/P/T (read: Redstone Flux per packet per tick) and limiting the per connection to RF/P/T, the network would be much more compatible with itself. So even if the player has a huge array of Windmills or a several solar farms, that user would be able to concatenate the power produced from the several L/MVsources into one HV line for transmission at the HV rate. This is something i always wanted to do with IE but could not due to the current limitations. If i want something to transfer at the HV rate from the producer to the consumer, i would have to wire the whole network for it, and that's a bummer when individual generators are not always worth the effort.

[BluSunrize]

Okay, let me chuck an idea in then:

Say I adopt a packet system. That means transformers will always 'store' energy, and when it's enough energy to form their packet, they will send it. That means that a step-up transformer would store energy till it reaches 1024 RF/t, then send those. Say there's two step down transformers on the network and it's sending to those. Each receives 512RF/t and distributes them along over the next 2 ticks as packets of 256 each

Sounds reasonable right? Thee thing to make that work would be adding storage to transformers, effectively allowing them to receive power and store it till it's enough for a valid packet, and a boolean to switch transformers between step up and step down.

Problem with this would be, that a watermill generating ~32 RF/t would be working just fine when faced with an LV only network, but lv going into MV would take 32ticks to store up the 1024RF to send as an MV packet.

[AEnterprise]

maybe if a tranformer is empty have it request a partial packet?

[BluSunrize]

You can't really request with RF :/

[theunkn0wn1]

OK, so just because MV can carry 1024 Rf/P/T Does not inherently mean it has to have 1024 RF to create a packet, lesser voltages can be carried on larger lines, just with higher loss. because watermills produce such little power, in order to produce an usable amount of charge from it, such as for automation, the player will be pushed to use multiple watermills to improve RF/T.

If the user only has one watermill for his entire power production, the player just won't have the infrastructure to make an MV power transmission network yet. Yes it would take a long time for that single watermill to produce enough RF to step-up the voltage, but the user is still in early-game where MV is not yet in use. By the time MV becomes an option to the user, that user will have the infrastructure and some understanding of the power grid to use MV power.

IC:2/E gets around the mentioned issue by how it impliments the EU per packet per tick. One machine will only accept 32 EU per tick, regardless of the actual amount per packet. So if the user has the right machine, he can send that machine 32 EU per tick... at 512 EU per packet. The packet should (as it does in stock IC:2/E) match the EU/T but does not have to. IRL power networks are variable, they are not fixed; not even HVDC. By allowing for some fluctuation in how much RF is in each packet, IE's power network can become flexible to fluctuating power demands. so MV can carry 1024 RF/T as it stands, With packets it can be _up to_1024 RF/P/T. Wtih that one watermill scenario, that L->MV transformer does not neccesarialy need to hold that charge for 32 ticks, it can throw the 32RF into an MV packet and throw it down the line. your existing power model is compatible with this. As mentioned above in my OP, your current model is as follows:

ΔP=B-max(min(B*(X/LR))) or ΔP=B-max(min(X/LR),B^2),0) where P = output power, B is input power, X is distance, R is cable resistance (a fixed linear value),and L is max cable length (per connection)

currently, B is fixed to the transfer rate of the cable, with packets the RF per packet becomes B. Therefor, LV power can technically be transmitted over MV lines with an input of 32 RF/P/T . the power can then be wired into an MV capacitor for buffering before transmitting to the true consumers on the network

In the case the cable provides more power than the endpoint will accept, the surplus can be simply sent back into the network in a smaller packet, so it can be consumed by something else. I think the power cables "transfer rate" should be "transfer limit", with the use of transformers to concatenate smaller packets, consuming them, and turning them into larger, higher voltage packets for more efficient transfer. Imho, smaller packets (L/MV) should be what are consumed by endpoints, while HV, or any other larger packets, should be used for transport rather than consumption by endpoints,excluding the machines that run exclusively on HV, as those are OK

[BluSunrize]

But how else would you determine it? RF is a push based system (and I don't intend to move away from RF as a whole. It's just too practical). Meaning that a watermill that pushes 32 RF into the net needs to put it somewhere. Tile's tick after one another, so you need to store the RF somewhere to be able to unite multiple packets in the first place. The transformer would /have/ to store its power to allow all watermills on the same tick to send power to then unify into one bigger packet. And if you don't have a limit of making the packet require 1024, the transformer might tick to early and send /very/ fluctuating packets. And you really don't want such inconsistent transfer.

[theunkn0wn1]

You can stay with RF, would be too difficult and not worth it to move away from it. My suggestion for temporary storage: use a capacitor daisy-chained to the transformer. when the capacitor receives power from the watermill, its ability to push power into the transformer increases the same. when the transformer detects it is getting a push of sufficient magnitude it will fire, consuming the required LV packets from the capacitor and pushing the MV packet into the net.

So the producer pushes 32 rf/t into the capacitor. the capacitor pushes its current capacity into the transformer. once the transformer detects enough LV packets from the capacitor are being pushed to it, it will fire off the MV packet and consume the LV charge

[BluSunrize]

That sounds very similar to my approach, with the added capacitor. In the end, it'd still store RF till it's enough for an MV packet, no?

[theunkn0wn1]

Yes, it seems the most effective way of doing it is to hold the LV packets till its enough to constitute an MV Packet. The capacitor also acts as a voltage regulator, dampening input power fluctuation, smoothing out the distribution of packets. by having the capacitors output leading into the transformers input, the transformer has a place to put the packets if it has nowhere to push them to;allowing the transformer to indirectly handle the power without itself needing to have charge capacity.

[BluSunrize]

Why add a capacitor for it though? Just internal storage should do the trick, no? makign two machines cooperate is more complex than havign one do everything

[theunkn0wn1]

Its getting late where i am at...

If the transformer had the required capacity built in, it still needs something to limit the direction of the flow of power. the external capacitor has fixed I/O sides. you are welcome to drop the external capacitor as long as you add separate step-up step-down transformers. without fixing the direction of energy flow to/from the transformer a feedback loop can and will occur. besides, IRL transformer equipment is specialized to one direction of flow as i understand it...

[malte0811]

This transformer with internal storage sounds like a tesla coil. So why not make the old transformer only transform downstep and add a new type with a different model, the tesla transformer? That would separate them and explain the internal capacitor.

[theunkn0wn1]

Tesla coils produce HVAC, making them suitable for the MV to HV step up transformer as well as an area denial system when live😀. However the MV from LV remains a question that needs an answer. Otherwise I do agree with your proposition On Aug 28, 2015 3:52 AM, "malte0811" notifications@github.com wrote:

This transformer with internal storage sounds like a tesla coil. So why not make the old transformer only transform downstep and add a new type with a different model, the tesla transformer? That would separate them and explain the internal capacitor.

— Reply to this email directly or view it on GitHub https://github.com/BluSunrize/ImmersiveEngineering/issues/362#issuecomment-135738071 .

[BluSunrize]

And now you're getting back into electricity, which sadly, I lack expert knowledge of Reason I never would do voltage and amperage: I don't understand the maths behind it. x3

[mindforger]

it's very simple, the higher the voltage the lower the amp when transporting the same power, which is P = U x I and the higher the Amperage the higher the loss

by the way didn't EnderIO set a event like request system on top of the RF push system? EIO Capacitory eaqualize each others out through the whole system when in bidirectional mode ... one of the reasons, why 2 caps in bidirectional mode are continously pumping energy to each other when connected via IE wires until they wasted all energy over the loss

[cobra]

The basics of electrical power transmission in real life are really simple. Transmission lines are resistors (disregarding any AC effects; those don't influence losses much but are very complex and nearly impossible to model in MC). Basic equations: P=U*I (P: power, U: voltage, I: current), R=U/I (R: resistance, U: voltage across the resistor/line). Power "lost" when travelling through a wire with resistance R, causing a voltage drop U_wire=R*I over the length of the wire: P_lost=U_wire*I => P_lost=R*I^2. The power transferred is just P=U*I (same I, but different U than in the power loss equation!). It's quite simple - this equation is the single cause why (very!) high voltage is the only viable option for long distance power transport. The power loss of a transmission line doesn't depend on the voltage it's operating at, only on the resistance (which you can't change much due to other constraints) and the current it's carrying. In order to minimize the losses, you have to minimize the current. Use half the current, loose only a quarter of the power you lost with a higher current. Ideally, power transmission would operate at extremely high voltages, but these are difficult to handle (arcing when switching, discharges, etc).

I think anything involving energy packets is just going to get very complex, won't quite be RF-style and somewhat unrealistic. Of all the lossy MC power systems I used, I liked the one from RedPower2 the best (maybe that's influenced a little bit by the wires and aesthetics, I have to admit.) Pulses/packets just get messy and irregular. @BluSunrize what exactly don't you like about the current system? You did only mention that you're a bit frustrated, but not why.

[BluSunrize]

I'm frustrated due to my inability to make everyone happy, really. I don't like the current loss system we're working with, because it makes HV effectively useless, and transformers are entirely pointless as they are, since the lowest throughput wire determines the entire connection. I'm considering this packet change to give Transformers an actual job and distinguish IE from other RF transports out there. If anyone else has a different approach they'd like to pitch, I'm all ears.

[theunkn0wn1]

@BluSunrize you can never make everyone happy, your aim should be to make most people happy, unless you are going for the GregTech angle... Based on the Exponential decay for power loss due to voltage, the higher the voltage, the less voltage, and thus energy, is lost. by quite simply changing your linear model for decay to a more realistic exponential decay, wires would act in a more appropriate manor.

Edit, redacted code, had not properly thought it through.

[XFactHD]

IIRC Buildcraft and Railcraft are using a pulse based output system for their engines, maybe this could be used as a model in some way.

@mindforger funny little joke 😜

[theunkn0wn1]

Had to redact the code i offered up, it was not doing what i thought it was. Now, after doing some research on how power transmission works and how voltage drop occurs, i have come up with a properly working python script. This new script takes into account power line resistance and the physical size of the line. It uses real-world formulae to calculate the power loss over a distance, and outputs the maximum distance a line with the given properties can reach at 100% loss. The cable radius was extracted from current IE source files. Instead of pasting a wall of text, i created a repository containing it. @BluSunrize have a look and tell me what you think please https://github.com/theunkn0wn1/PowerLoss

[wooky]

This might sound like a crazy idea, but why not implement AC-like system? This way you can feed machines with RF, distribute power with "Alternating Flux (AF)" across the grid, and use transformers to go from one system to another.

You wouldn't be able to feed AF to machines directly (unless someone makes a machine that accepts/produces AF). You'll probably also need to have 2-3 wires for AF as opposed to just 1 for RF.

I'm just giving ideas based on IRL electricity, which may or may not make sense in a Minecraft world.

[BluSunrize]

I don't want to stray from RF, I don't want another energy unit that needs conversion. @theunkn0wn1 I don't know python, I can't really read that .-.

[wooky]

Would it not be possible to use the same RF API and just make it so machines can't use that energy directly?

[theunkn0wn1]

@wooky ... Do you know how complicated AC power is? Idk if we could even implement some of the formulae used to calculate power throughput and voltage drop in MC....

IRL power mains are HVAC. the formulae associated with HVAC involves math beyond my understanding... DC is soo much simpler to model.

@BluSunrize , my python script is documented, anything folowing a # is a comment in python. as i understand it, indentation is used to represent nesting (such as the contents of an if (conditional):) 'def' is used to define a function. there are no 'end' opperators in python.

I define the Rf from the RF API to be treated as volts. The amps and wattage are both proportional to the voltage. That's what my python script does, treats the input rf/t as volts; calculates resistance from assumed cable material, thickness, and distance; and calculates the voltage drop over x distance.

def crossSection(r):
    global CS
    CS = int(r)^2*int(math.pi) 
    return CS
    # area of cross section is a circle. formula for area of a circle.

which follows the formula when cs= cross sectional area, and r = radius of cable

This function is used to calculate the cross-section of the wire, this is needed as part of the function to calculate resistance as shown below

def resistance(rad,x): #resistance over x distance, r is resistivity
    #r is resistivity
    Resistance = rad*x/crossSection(rad)
    #return Resistance #output is in Ohms
    return(Resistance)

which follows resistance formula when R = resistance, r = radius, d = distance, and CS(r) = crossSection(r)

This function calculates the current on the line:

def current(resist,volt): #converts Resistance and voltage into ampage
    i=resist/volt # i = r/v as v = r*i
    return i

which follows the function and therefor when I = current, R = resistance and v = voltage

This function calculates the power drop based on the distance traveled, the current of the line, and the resistance

def powerDrop(dist,current,resist):
    #Formula for voltage drop is:
    # Vd = I*(2LR/1km)
    Vd = current * ((2*dist*resist)/1000)

    return Vd

using the formula When Vd is voltage dropped, I is current, L is distance, and R is resistance at given distance.

All of those functions are setup for the next function.

def remainingPwr(x,b):
    distance = x
    i = current(resistance(radius,x),b)
    resist = resistance(radius,x)
    PwrLossed = b-(powerDrop(distance,i,resist))

    return PwrLossed

This final function uses the outputs of all the above functions to preform an simple formula Where V0 is the output voltage over the given distance and other vars declared at the beginning of the script.

the python while 0==0 is the equivilance of an

 while true {}

in java. Everything below line 62 is used to itterate the value of x, to eventualy find how far the cable can go before reaching 100% voltage drop.

[wooky]

I'm not saying that we have to simulate a real AC system. Something simplistic should suffice. For example, the AC ("AF") system should transfer energy 10 times faster than DC (RF) while being 5x more efficient. Implementing IRL systems and behaviors into a Minecraft mod is... unrealistic, to say the least.

[theunkn0wn1]

IRL AC systems are not linearly better than the equivalent DC circuit, And arbitrarily defining AC to be X times better than DC would not do us any good, as people will find a way to just use the AC system if they could, because its more 'efficient' than DC. in fact, DC is more efficient with transfering power in HVDC systems than HVAC systems, for certain applications.

All that i am proposing is to use a different power drop system that interacts more like the real world, by doing so it becomes more immersive. If @BluSunrize adopts the model i described in my previous post, power loss would be a quadratic function rather than an linear function. The higher the voltage on the line, the farther the power will go; to an extent. My model (based on RL) self-clamps maximum voltages for a given line to the principle of diminishing returns, there is a point where increasing the voltage any higher just reduces maximum distance. It becomes a trade off, do i want extreme RF/T or do i want maximum transmission distance?

the way MC works and the way RF works, an AC system in principle would be rather dificult to program. RF is a 'push-based' power distribution system, AC is power that flows in both directions down the transmission lines, alternating at x reversals per second. Since RF is push-based system, both the sender and the receiver would need to be able to generate charge, consume charge, pull charge, and push charge. the RF system just is not designed for this.

We don't need 'real' AC, we just would want 'realistic' AC. Something that in principle i just don't see how it could be done with the RF api. If you come up with a way to make it work, please share the Proof of concept

[malte0811]

@theunkn0wn1 the assumption that rf/tick is volt does not really work, since rf=rf/tick*time is energy and voltage*time is not. You should use rf/tick as wattage because 1W*1s=1J. I don't really understand your formulas, but it seems like they are ignoring the resistance of the load/the machine being powered. I have a model based on these assumptions which i will upload later today. Btw, how did you get LaTex formulas working in markdown?

[theunkn0wn1]

@malte0811 LaTex formulas? what are those? the formulae i show above are not written in markdown, they are just images. i wrote the formulae in the windows math input panel and captured the screen output. I made the assumption that Rf/T was voltage as it was the understanding i had come too, since that is the current packet size, though TBH i had no real idea how to translate it into the formula. So.. my assumption should be that RF/T = I?

The model i suggested above are (from what i can tell) the formulae to calculate Voltage drop on a DC circuit. Yes i did ignore the load of the machine, as i felt it to be irrelevant to what i was attempting to achieve. the resistance of the machine receiving the power can also be calculated by my above formulae, but was outside the grasp of the concept i was attempting to prove. i Focused only on the Voltage drop over the Line at a given input voltage over x meters of distance. It would not be too hard to reconfigure my script to use the RF input as the current, and calculate the voltage from that. I will reconfigure my script later today, after i get some sleep...

[malte0811]

No, rf/tick is volt*ampere since volt*ampere*second is joule and rf is energy as well. LaTex is what i use for writing formulas and such, https://en.m.wikipedia.org/wiki/LaTeX)

[theunkn0wn1]

Ah, OK... So i should treat Rf/t to be equal to W in the below, right? since v = volts, a = amps, j = joules

[malte0811]

Yes

[cobra]

Errrm. Stop overcomplicating things. Remember KISS. Especially for @theunkn0wn1: don't spend so much time and effort writing over-formatted tickets and comments ;)

Back to the basic problem:

• We have: rf/t (as power, rf as energy); Higher tier wire supporting high power transfer with lower losses.
• We need: something to differentiate tiers, making higher tier wire more efficient for lang distances than lower tier wire. Ideally, following a somewhat realistic pattern; A use for transformers; Maybe some rebalancing of the config values.
• We don't have: voltage or packets. Won't happen unless breaking nearly everything.

There's absolutely no need to think about differences between AC and DC in real life when looking at IE's game design. Also, the idea of bouncing RF around to simulate AC is imho completely wrong - you don't do anything like this when calculating AC related stuff. Simply assume that RF is AC current - we have simple transformers, so DC wouldn't make sense for IE - and assume DC physics to keep everything simple. There is nothing wrong when doing this. Trust me, I'm an electrical engineer.

My proposal for the wiring: don't use voltage in-game, only as design element for the tiers influencing the losses. Each wire type has a resistance, maybe even the same across all tiers, but the "virtual" voltage lowers the losses. For example: we want to transfer 100 rf/t (W) over wires with 10 Ohm resistance. LV=100 V, MV=1 kV, HV=10 kV, so the currents would be 1 A, 0,1 A, 0,01 A, leading to losses of 10 W, 0,1 W, 0,001 W. This results in fixed loss factors for each tier, something like 10% per segment for LV, 0,1% for MV, 0,001% for HV (numbers aren't balanced at all and only examples) - just how it's handled in IE at the moment. For everyone wanting real-life numbers and more information: https://en.wikipedia.org/wiki/Electric_power_transmission#Losses, Diagram of power lost over power transferred

I don't know yet how to cram transformers into RF without breaking compatibility. The obvious choice would be connection restrictions, but this doesn't help when you want to connect high-powered machines from other mods with high-tier IE wire. Anything changing the energy transferred would break RF compatibility at all. I can't find either a penalty for using HV for low-powered machines without a transformer nor an incentive for stepping up lower tier power to a higher tier. I really like the transformers, but at the moment they are just expensive decoration.

[malte0811]

How about something like a "minimum used energy", so if less than x rf were inserted (but not 0), it will remove x rf from the source anyway. X could be the max transfer rate of the tier below, so 1 for lv, since it does not have a tier below, 256 for mv, since it is the max for lv and 1024 for hv. That would allow for every machine with a constant power draw to be operated without additional power loss. Step down transformers would not allow for less than x rf to be inserted and buffer those x rf. For step up transformers i dont have any ideas yet, the "tesla coil" transformer does not really feel "natural" to me

[theunkn0wn1]

@cobra the problem is as it stands the power loss at a given 'transfer rate' is a constant. B, the RF/T, is being treated as voltage as it stands,as i understand it, and is linearly being dropped. This leads to the impracticality of using HV powerlines, the constant loss of power over distance. I may be going a little OTT with going and writing an script showing a different power model, but its better than empty air. You guys are welcome to reject it, i am not attempting to force it on anyone.

tweaking the reistance/cable length value for the existing problem does not get around the issue, the model is linear. For hv here is a representation and for MV and here is both of them side by side

Anyways... Here is an idea We don't need to add voltage as an output or input of the system, just a reference used in the power loss calculations. The input and the output of the system remains RF, the RF going through the network is modified based on resistance calculations. RF is treated as Wattage inside the system, the volts and amps (used only for the power loss calculations), and the Rf output would be less than the input, in a non-linear way. We can fit Transformers in this somewhay easily, but would require redoing how IE calculates power loss. The transformers affect the power loss the block they input into. the power loss from the first storage device to the transformer, block A would be calculated and the output given to the transformer. the transformer converts the 'voltage' up and uses that as the starting point for block B's calculations. Block B calculates the power loss from the transformer device to the second storage device. Its voltage, and thus resistance, are different than block A. By using this model, the transfer rate is not limited by the lowest cable, but by the max power put through the cables on the network.

If Block A was MV and B was LV, then perhaps multiple LV lines would be used to draw off the power.

If Block B was MV while Block A was LV, the transfoermer would take the LV packets and transform them into MV packets before sending them on. the Step-up transformer would have to store the LV packets until enough power is stored to fire off a MV packet. Want to speed up the upward conversion? put more providers on the input side of the transformer.

Currently IE uses the transfer rate and resistance(?)of the lowest cable. it sums the distance of A+B and uses that into its linear power loss formula

[mindforger]

i'd like to bridge over to the CME issue here and to assist @theunkn0wn1 with an idea to deal with both issues in one dish (i hope this was translated correctly)

i searched in enderio a bit to get an idea but this system is only usable for cable-per-block solutions.

what you need @BluSunrize is a edge graph network with 2 specific layers of weights("Kantennetzwerk" in german)! Every Connection has it's "resistance" attribute and its maximum capacity beeing it's max Voltage.

the loss is calculated by the size of inputparameter of "transferEnergy", and the more power is input(throughput to be more specific), the lower the loss becomes

to explain: as R = U / I where U is the voltage drop over the resistor(the cable specific resistance multiplied by length), the higher the voltage becomes (voltage means input in this case) the lower the loss becomes

if someone is now transfering HV to a machine only accepting a fraction of the HV capability, the loss increases dramatically, making the installation of a buffering transformer practical

the path calculation is the tricky one here, but this will become more realistic than you would believe! it's kind of adapting the current system but in a different way!

when you connect a cable, you start a graph discovery, storing all recepting nodes with all possible routes

the route calculations goes as follows.

1. every edge has an distance, specific resistance and maxV attribute(the wireCoil Classes).
2. every route between exit nodes needs to be discovered, doing the following for every discovered route before storing it toi the connections map: 2.1. discovering the maxVoltage of the route 2.2. calculating the resistance of the route (every edge needs a function to determine it's resistance in respect to it's maxV versus the actual maxV of the route like double getResistance(int maxV), which gets sum up)
3. the route gets stored in the map with it's resistance and maxV

when you transfer energy into a node at what ammount ever, you try to fit it repeatedly into the routes with the lowest resistance until you have no power left or you are out of routes, but you would still have to calculate the actual loss when your inserted power is below the maximum or the transfered ammount is less then the input amount.

[mindforger]

    static double dist = 10;
    static double specificR = 0.01;
    static double maxV = 100;
    static double scale = 1; //scale must be adjusted carefully!!!
    public static double getLoss(double input)
    {
        double vR = specificR * dist;
        double vI = Math.pow((maxV/input),scale);
        double lossU = vR * vI;
        return lossU;
    }

the transformers will become a mess in this, they need to accumulate a charge up to twice of the size of the input to work continously (but only if there are nodes behind the transformer, so there is no need to implement IEnergyStorage for them) and they need to block incoming transfers that would exeecd their capacity. Additionally, every tick they need to check their internal buffer and emit another transfer until they are empty.

i can literally see the recursive loop to and from the transformer via any other mod cable, which needs to be prevented also .... @BluSunrize ... you need to somehow check either the callstack or some sort of marker to avoid recursive "transferEnergy" loopback through other mods! IE_con1.transfer -> IE_con1.output -> EIO_con1.transfer -> EIO_con1.con2.output -> IE_con1.transfer

[theunkn0wn1]

@mindforger thanks. But be careful, I have been told off once for making incorrect assumptions about the nature of RF, RF =/= I =/= U when I = Intensity(amp) and U=voltage. @malte0811 states:

the assumption that rf/tick is volt does not really work, since rf=rf/tick*time is energy
 and voltage*time is not. 
You should use rf/tick as wattage because 1W*1s=1J
...
rf/tick is volt*ampere since volt*ampere*second is joule and rf is energy as well

So the trick is how to get I out of W=VI when all we know is W

Otherwise i don't have any objections what you have proposed above.

---

The EIO issue i can also confirm, its leading to a rather annoyingly large static power loss on my EIO capacitors using IE for transmission...

[BluSunrize]

first off, let me say thank you to @kane-thornwyrd for attempting to COMPLETLY derail the discussion. This is the IE Issue Tracker, and we're discussing the Redstone Flux energy net. Your input was about as needed as a bull in a china shop.

Back to the topic at hand, I must say, that I'm slowly agreeing on one thing here: We're overcomplicating this by a landslide. RF is supposed to be a simple system of input and output, and at the moment, IE already ads one step of complexity to it: the fact that there is loss at all. Now don't get me wrong, I wish to keep loss, and I wish to keep transformers and make them useful. Those are my three main concerns in doing /something/ with this system right now. I still feel drawn to the packet system, mostly because it seems to be the most logical use for transformers, apart from being (as @cobra put) very expensive decorations. What I feel will be too much to handle is the suggested callstack tracing. Because as far as I'm aware, they way that this is done in java is by throwing and exception, catching it and then using its trace, which, I have been told previously, is quite resource costly. I must also admit, that most of you seem to surpass me in the understanding of all these numbers and values, and I fear that you will also surpass many of the userbase. Hence why I think that we need a simple solution, that still somehow compensates the flaw of linear resistance. Now, I see two aproaches to this: 1) instate transformers as a storage device, similar to capacitors, making them store power until they reach the packsize they are stepping up to, or when stepping down, storinh power to distribute in smaller packets. 2) similarly to 1 but rather than storing till the packetsize is met, I'd make transformers /try/ to store that much in a single tick, and at the end of the tick, if they don't have enough stored, they send an incomplete packet. This would still allow "power fluctuations" rather than the fixed RF/t values per wire, with the downside that sending smaller packets through HV lines has them lose more power.

[malte0811]

My idea regarding a "minimum transfered energy" seems relativly simple to me, but my understanding of simple is generally not "normal". That system would probably be, compared to the other suggestions, easy to implement and it would make transformers usefull to prevent wasted energy (imagine running an 20 rf/tick machine and having to use 1024 rf/t because you have it wired to hv). Power loss would still be needed, but it would solve one of the problems. Buffering energy for 1 tick and sending it at the end (for up step transformers) would probably work well with that system

[theunkn0wn1]

The userbase does not need to understand exactly how power loss occurs. All they need to know is something along the lines of The higer the voltage, the farther your RF will travel and the less you will loose along the way. By increasing the voltage, your can get more RF/T through the system per tick

I do agree we are complicating things, but the simplistic model we have atm just, omho, is not very immersive and cannot be balanced. As it stands, at least for me, i don;t bother thinking "Oh, should i use LV or MV for this application?" as the power loss for short-term transfer is negligible. Its only when the player attempts long-range transmission that the flaws in the design become apparent. no amount of tinkering with the resistance and cable length will fully fix this.

Electricity is a complex phenomena that Rf, like so many tech mods before it, simplify this force into simple numbers. This is ok, its a game, they are not bothering with resistance, it makes no difference whether the power is low tier or high tier; Rf is Rf. But because IE is going that extra mile by adding resistance, i wish it would be done properly. Properly is not the same thing as correctly, just done in a fun, immersive method. IC2 adds complex nuclear reactors, they are a pain to learn at first, the player may die many times, many bases go up in that iconic mushroom cloud, yet once the player learns the ins and outs of that complex system they become satisfied with the fact they did something difficult. The back-end formulae and dynamics of those nuclear reactors do not need to need to understood by the userbase at large, as the understanding of how the components of the reactor impact the outcome is sufficient. That is what got me at least into tech mods to begin with, the satisfaction of doing something new, something complex, something immersive. We choose to do these things, not because they are easy, but because they are hard. just because the numbers and formulae are big and hairy does not mean every user needs to understand them to apply the results the math brings, much of what we can do today is based on the underlying complexity that defines the modern world, the modern world uses the internet to survive with little understanding or caring about exactly how it functions, only the fact that it does. A light bulb or a computer that is powered by electricity, the end user appreciates the energy, but does not need to know the complexity of the power grid that supplies him/her.

Someone should be able to download this mod and make a working power grid with ease, but the most efficient means of making a grid would become available to that person as they become more familiar with it. With IC2/E someone with no experience with it before can pick it up, follow a tutorial or two, and make a working nuclear reactor. Those initial reactors are simple in design, and are efficient but have great room for improvement. This improvement comes with experimentation and communication. Immersive Engineering could have that layer of complexity for its power transmission without overburdening the userbase. Those whom become knowledgeable of the basics of power transport can move onto more advanced topics. By the time the player would need long-range high-efficiency power transport, he would have attained a sufficient understanding on how the system works to create that high-efficiency power grid. Complexity is not the enemy, poor design/implementation is.

The decision on how any/all this applies to Immersive Engineering is ultimately yours to make @BluSunrize, I will accept your judgment without complaint.

Now, to the issue at large: @BluSunrize I fully agree with your transformer proposition, and have no objections with it. step-up transformers hold the input charge until enough is present to send as the output voltage. Or the transformers would consume as much power on the input block as it can within one tick, and output that power as full and partial packets of charge over the output block. Step-down transformers do the inverse, accepting one input packet and break it down into several output packets. Each packet would be worth %packetSize% RF per tick's worth of energy. and by block i mean the energy network segment the transformers given face is connected to.

[wooky]

The problem with having higher tier cables have lower power loss is that people would just stop using the lower tier cables. Since the material costs for cables is almost the same, and higher tier cables have a higher transfer rate with a lower resistance, there would be no point in using lower tier cables since the throughput is lower and energy loss is higher.

[theunkn0wn1]

That is the key problem with any vertical progression system, TE has that problem, and IC2/E gets around it. IC2/E makes machines explode if they get too much power, but i know @BluSunrize will never do that. perhaps machines become damaged/burst into flames if they receive too much power?

perhaps participating modders can add utilize an API hook into IE that sets the max power per tick they can receive from the network. Something bad would happen if the user attempts to shove HV power into that basic redstone furnace, for example, what exactly is not for me to say. Perhaps that could be configured by the modder?