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

BluSunrize on 27 Aug 2015

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.

theunkn0wn1 on 27 Aug 2015

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

bakaxyf on 28 Aug 2015

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.

theunkn0wn1 on 28 Aug 2015

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

mindforger on 28 Aug 2015

@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.

theunkn0wn1 on 28 Aug 2015

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

mindforger on 28 Aug 2015

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, .~.

BluSunrize on 28 Aug 2015

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.

theunkn0wn1 on 28 Aug 2015

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.

BluSunrize on 28 Aug 2015

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

AEnterprise on 28 Aug 2015

You can't really request with RF :/

BluSunrize on 28 Aug 2015

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

theunkn0wn1 on 28 Aug 2015

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.

BluSunrize on 28 Aug 2015

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

theunkn0wn1 on 28 Aug 2015

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?

BluSunrize on 28 Aug 2015

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.

theunkn0wn1 on 28 Aug 2015

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

BluSunrize on 28 Aug 2015

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...

theunkn0wn1 on 28 Aug 2015

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.

malte0811 on 28 Aug 2015

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" [email protected] 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
.

theunkn0wn1 on 28 Aug 2015

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

BluSunrize on 28 Aug 2015

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

mindforger on 28 Aug 2015

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.

cobra on 28 Aug 2015

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.

BluSunrize on 28 Aug 2015

@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.

theunkn0wn1 on 29 Aug 2015

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 😜

XFactHD on 29 Aug 2015

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

theunkn0wn1 on 29 Aug 2015

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.

wooky on 29 Aug 2015

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 .-.

BluSunrize on 30 Aug 2015

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

wooky on 30 Aug 2015

@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.

theunkn0wn1 on 30 Aug 2015

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.

wooky on 30 Aug 2015

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

theunkn0wn1 on 30 Aug 2015

@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?

malte0811 on 30 Aug 2015

@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...

theunkn0wn1 on 30 Aug 2015

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)

malte0811 on 30 Aug 2015

Ah, OK...
So i should treat Rf/t to be equal to W in the below, right?

since

v = volts, a = amps, j = joules

theunkn0wn1 on 30 Aug 2015

Yes

malte0811 on 30 Aug 2015

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.

cobra on 30 Aug 2015

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

malte0811 on 30 Aug 2015

@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

theunkn0wn1 on 31 Aug 2015

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.

every edge has an distance, specific resistance and maxV attribute(the wireCoil Classes).
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)
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 on 31 Aug 2015

    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

mindforger on 31 Aug 2015

@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...

theunkn0wn1 on 31 Aug 2015

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.

BluSunrize on 31 Aug 2015

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

malte0811 on 31 Aug 2015

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.

theunkn0wn1 on 1 Sep 2015

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.

wooky on 1 Sep 2015

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?

theunkn0wn1 on 1 Sep 2015

I think by saying that he will never make machines explode he means that he does not want machines to be damaged by wrong setup.
@BluSunrize If i did not understand that correctly, please tell me.
Also making machines break at to high voltage would possibly destroy working setups, since server admins don't always inform their users before updating. What i suggested would just make those setups temporarely inefficient, which could easily be fixed. It would be nice to have some feedback on that idea, since no one reacted to it in any way yet.

malte0811 on 1 Sep 2015

People do make mistakes, and honest errors can occur when setting up a legit build. If the Server admins change the power throughput of H/MV cabling without informing the players, that is a problem between the Server operator and the players.
However, things can be overlooked, i do not wish to punish players if their server Opp changes values between a restart or they go tinkering with the config without understanding fully what they are doing.
Perhaps those circumstances can be mitigated by adding Circuit breakers. So, unless its a very sensitive device, such as a mars rover, it can tolerate for very short periods of time being exposed to too higher voltage than it has been rated to. The breakers, which would sit just upstream of the consuming device, could be 'rated' or otherwise configured to only allow a given maximum Rf throughput to pass through it. If too much attempts to pass through, within a few game ticks the breaker would 'trip', interrupting the circuit. This would also mitigate power surges caused by lightning striking the power transmission lines. (not currently implemented, but would be cool)

As it stands we have switch breakers, which have to be 'tripped' manually, though i don't figure it would be too difficult to add an automated breaker. Though since I have not attempted to make an addon for IE or any other mod myself, i have no true idea of the difficulty of adding such an item.

theunkn0wn1 on 1 Sep 2015

What i was talking about is this: assume this gets added in 0.6. I have only been on one server yet, but the admins usually did not inform the users in advance of the update. Also not all users would be aware of those changes. Now it is very possible that a user has attached lets say a few crushers to hv. If the server now updates to 0.6, this setup that was perfectly valid before the update now destroys the crushers, without the user having had a change to prevent that.
I like the idea of circuit breakers, maybe make them triggerable by redstone as well?
Also, yet again, what do you think of my suggestion regarding a minimum transfered energy?

malte0811 on 1 Sep 2015

OK, in that case the server operators, the ones retrieving the updated IE binaries, should encounter a big, fat warning saying

"WARNING: MACHINES MAY EXPLODE DUE TO THIS UPDATE, WE ADVISE THAT ALL IE CABLES IN YOUR WORLDS ARE DISCONNECTED BEFORE UPDATING"

Or something to that affect. By doing this, any competent - i hate using that word without knowing who exactly its used on - server opp should then go and warn the servers players of this and providing a grace period for people to dismantle the sensitive parts of their networks before the big upgrade

Minimum transferred energy.... I don't like the idea myself, however that would greatly improve compatibility with other Rf mods. Just because we have connectors that operate at 1024 RF/T does not mean that another mod that is producing charge is gonna be at some multiple of 1024. However, the idea of 'wasted' energy because it was not consumed I cannot agree with from the way I understand you intend it to be implemented. IE all ready has issues with power feedback loops with other power mods (such as EIO capacitors) and this will only make it even worse.

As for RS circuit breakers: YES, PLEASE!
I was bummed to find out the breaker switches act in the inverse.

theunkn0wn1 on 1 Sep 2015

again, with my solution, there will be no punishment for using large scale power distribution at all but punishment for abusing it in a way where no significant power is transported over that line!

here another verison of my idea, but ALWAYS this needs a little rewrite to route based networking instead of node based!

LV: short cable range, low resistance, low capacity (ideal for early distribution and device connections) 128RF/t, no underload punishment

MV: medium range, low resistance, slight underload punishment(not as high scaled as with HV), medium capacity(thus usefull for midgame power distribution, can be optimized by using transformers to ensure maximum line load per energy burst) 1024RF/t

MV - LV Transformer: 1 Block Size instead of 2 (can be placed top down or wall mounted as well, to make it more integrable into a base), outputs MV to LV to as much wires as you want without punishment, accepts up to 1 MV-Burst per tick in or outputs only 1 MV-Burst per tick when there is enough stored (storage invisible to API)

HV: long range, reistance can scale from high punishment to nearly zero depending on the capacity usage, making HV transformers required! 4k RF/t

MV - LV Transformer: usual size, compareable power in and output and internal storage invisible to the API
BUT when you put on more than 4 MV wires, you could EITHER end up in an uneven power distribution, depending on which route is served first OR probably higher losses, as the transformer is only providing 1HV-Burst/t = 4 MV-Bursts/t and any sink accepting less that 1 MV burst will increase the punishment on the particular line for not using it's full capacity

transformers needs to be part of the route network when evaluating routes

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

the trick is, that i utilize the usage of the cable capacity and look at it as beeing the voltage (this is not as close to what RF is defined i know)
while I increase the voltage, the virtual non visible current drops, thus reducing the voltage(RF) loss over the resistance of the cable, this is my idea of a dimishing return ... well but per definition it's a inverted dimishing return :(, depends on the point of view

mindforger on 1 Sep 2015

So you want to force people to use step-down transformers to go from HV to LV/MV if the machine cannot accept 4kRF/t. How do you check for that? What if the machine could accept this much input, but doesn't (for example, a Resonant Energy Cell whose input/output capped to only 1kRF/t)?

Besides, this doesn't really solve the primary issue, which is having wires that can transfer at a much higher rate than 4kRF/t. Let's say the HV lines are bumped up to infinity RF/t. What happens if you hook up a machine directly to the line, but it only accepts 4kRF/t? You can't use transformers because you end up with a needless bottleneck. Does the machine end up blowing up?

Who knew that this issue would become so complicated.

wooky on 1 Sep 2015

Okay, first off:
No damage to machines. No explosion, no burn, nothing. It might be realistic for it to explode when you plug your hairdryer into an HV outlet, but I'm forever scared by my stupidity when playing with early IC2. I don't like losing my pretty rooms like that.
@mindforger has good ideas here: big power loss for "incorrect" setups.
If you have an HV line going into a crusher, and that line pumps in whatever I decide is the new HV (no it will never be infinite RF), the crusher only has space for ~80RF, because it used that much on its last tick, so the rest of that HV is wasted, since the transformer will output the entire packet =3

BluSunrize on 1 Sep 2015

dropping the whole package would be harsh :p

correct me but as i do understand, you say "transfer(amount_to_push)" and get back "amount used" ? then you decrease the storage of that transfered amount + the loss?

so you could easily go and calculate the actual loss after the transfer without dropping the whole rest of the input !?

cap the input and calculate a loss depending on how many is transfered VS how many can be transferred at max per route

@wooky yes indeed, if you config-bump the values for HV to 16k and do not use up the whole line, you will increase your losses (maybe make the formula somewhat configurable or at lleast it's scaling factors), this is the point where you need to decide how much your MV can transport and how much MV you can connect to one HV transformer at once before loosing efficiency :)

mindforger on 1 Sep 2015

I could, yeah... xD

BluSunrize on 1 Sep 2015

OK, then how exactly do we communicate affectively that the packet is being
dropped?
OK, missed @mindforger's latest post... I totaly agree with that proposal

The whole point of the IC2 power system is the more energy one pumps
around, the more dangerous it becomes. If the prayer does not get that in
their mind the first time then yes, rooms can be lost. That is why I don't
build pretty when I am learning a new mod. The difference between MV and LV
becomes quite clear soon enough.

My fear is that without a straightforward if you intentionally do something stupid like plug your 120 volt hair dryer into that industrial grade 2048v outlet of yours, bad things will happen, so just don't do that. Players will have a
really difficult time understanding that mechanic. It like telling a child don't smoke boy, it will kill you and give you cancer! Most players are just
going to ignore it like they can with most other power mods. We, as players
are conditioned by tech mods to assume that bigger, higher tier transport
is always better than the lower tier t-shirts for every application. The
reason IC 2 is such a shock is because it turns this expectation of ours on
its head. It gives us a clear reason why NOT to upgrade everything to HV as
soon as you can, why NOT to use the same power source for your mass fabs as
your macerators directly.

That energy you are dropping has to go somewhere. And most players will not
read the book or be voltage conscientious if there is not a blunt 'you
cannot do that' and if they ignore that warning it should become a 'you
where warned' and something bad occurs. It does not have to be an
explosion, it does not have to be a fireball, but it must be clear, and it
must discourage running HV into a LV consumer.

I understand you are still scared and mortally wounded by your first time
with IC2, but that is to be expected. IMHO, right now IE is not complex
enough, I use MV for everything because I know there is no point to
anything else. Everything runs on MV if I want them to. I just hope that whatever we/you decide on will be immersive enough. :3
On Sep 1, 2015 3:10 AM, "BluSunrize" [email protected] wrote:

Okay, first off:
No damage to machines. No explosion, no burn, nothing. It might be
realistic for it to explode when you plug your hairdryer into an HV outlet,
but I'm forever scared by my stupidity when playing with early IC2. I don't
like losing my pretty rooms like that.
@mindforger https://github.com/mindforger has good ideas here: big
power loss for "incorrect" setups.
If you have an HV line going into a crusher, and that line pumps in
whatever I decide is the new HV (no it will never be infinite RF), the
crusher only has space for ~80RF, because it used that much on its last
tick, so the rest of that HV is wasted, since the transformer will output
the entire packet =3

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

theunkn0wn1 on 1 Sep 2015

Well, @BluSunrize , you don't need the machines to explode to get across a penalty for incorrect wiring. It could be as simple as having the machine burst the connectors attached to it and deal health damage to all nearby entities relative to the connector type.
Connectors are cheap to replace and since it'll usually be the last part of a circuit to be connected, the player responsible will be right there when things go bad and figure it out without needing to replace an expensive machine.

VermillionX on 3 Sep 2015

I have no objections to this proposal. The machine itself does not need to
explode, as much as that would be 'fun'. Frying that last cable and its
connector would be sufficient, perhaps leaving a small latch of fire in its
wake :3
On Sep 2, 2015 6:36 PM, "VermillionX" [email protected] wrote:

Well, @BluSunrize https://github.com/BluSunrize , you don't need the
machines to explode to get across a penalty for incorrect wiring. It could
be as simple as having the machine burst the connectors attached to it and
deal health damage relative to the connector type.
Connectors are cheap to replace and since it'll usually be the last part
of a circuit to be connected, the player responsible will be right there
when things go bad and figure it out without needing to replace an
expensive machine.

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

theunkn0wn1 on 3 Sep 2015

Alright, two things that came to me:

1) Damage to cables: I agree that burning up cables would be a nice way to compensate for too much power in a line. The problem is, that IE does not allow you precise control of power output, meaning that you might, simply due to lack of control might insert too much power into the line.

2) The packet idea just doesn't work. I've mulled it over in my head, it does not really work with RF. Instead, I propose a new balancing concept for powerlines.
Now I know this was brought up in a pullrequest before, and I blatantly ignored it, I'm sorry for that.
What I'd liek to suggest is a perTick limiter of connections. Currently, having multiple lines connect in one allows you to send power through the line multiple times per tick. Every connector acts as a seperate input and they all unite via one wire, allowing you a possible throughput of multiple times the wires transferrate. I'm thinking of a HashMap of super.getDamage(stack)!=0 per Connection, which stores the amount of power that went through that wire in one tick, limiting your throughput. To balance that, I'd buff up the transferrates, obviously, and transformers would get useful by uniting multiple LV lines in an MV line for longer distance.
Sound interesting?

BluSunrize on 4 Sep 2015

Hm... OK if packets don;t work ok.

Limiting the total Rf/T per line is ok, provided the numbers are balanced. We should be able to carry multiple times the capacity of an individual connector, so we can have multiple outputs on one line. I kinda really like the idea that cables have a max transfer rate, would finially give meaning to my twin-hv mains line i have running down my rail network.

@BluSunrize , yes, you do have 'persise' control over the amount of power a given connection can output. That is how TE does its power tiers. Each output/input is limited to the Rf/T it can push/pull on the line. I saw when digging through your code you seem to have the ability to define the "maxReceive" of a given connector. I have noticed as IE works now there is one value that dictates the true energy flow in the network, excluding resistance, and that is the max flow rate. That gives you, as the developer, direct control as to how much power can be thrown into one connection. It would then be down to the player to engineer his network correctly as not to overload the lines. I have noticed that unimplemented 'power meter' you have there, when completed, it can show the engineer just how close s/he is to frying them cables.

You should not plan on when players act daft, it is a game after all. Though we should plan for the accidents/hard learners. IE can be forgiving.

If, for example, We have a HV main line that can carry 16KiRf/T MAX. Each HV connector can I/O 4KiRf/T MAX. As long as these numbers are understandable and accessible to the player, its up to them to know they can put up to four HV Inputs onto the line. If they put even one more, short fry. Now, the Entire network segment would go up as a result of that error, unless the player has mitigated this risk. By adding *_Circuit Breakers_ * to IE, they can be used as a means to limit the damage a power surge can do on the network. The Breaker could be installed in-line and setup to trip when the max capacity of the line is reached/exceeded. By the act of installing one of these devices, say half-way down the segment, only the exposed half of the segment would be fried as the breaker tripped before the whole segment goes up.

what do you think?

theunkn0wn1 on 4 Sep 2015

The packet idea just doesn't work

i must disagree on that, i've calculated it and with an adequate factor of lentgth the HV wires become very efficient! it's all about finding the right balance.

to your limit per connection, i am just working on a simplified version of your net with 2 benefits:

it's CME safe! but you may have to deal with artefacts as an iterator will not update it's content until newly created! So running iterations will still report a node even if it was broken right in that actual moment the iterator runs over it! But it will never "failfast" again and any calculation will safely end with an maybe outdated version of the list!
the indirect connections list is altered, so it works per power route with multiple routes for each pair of endpoints, so you can calculate the effective maximum transport capability through the net including the effective loss!

i'll upload it asap, but it is still very simplified, using ConcurrentSkipListMap, Comparators for automatic sorting and hopefully effective calculations :P

only the discovery of the routes is very very tricky XD

PS: and flipping a circuit breaker would not have to create a new calculation, it would just look up and update the corresponding routes and update the loss to infinite, which results in no transfer via this route and a downgrading through the comparator

PPS: to make it even better and more immersive, my net idea seems to punisch people with redundant loops! if i was to put a set of connectors A,B,C and D, with a diamond shape config A-B A-C B-C B-D C-D, you can actually transfer power via A-C and A-B-C and A-B-D-C (just scribble it on paper , you'll understand)

with my system, as long as the line A-C can handle the input, would be the only one
but when you put too much power into A, the overflowing power will start flowing first A-B-C and as last A-B-C-D ... so you need to either define the flow somehow or you'll have to use a transformer at the input to shape your packages or the excess power will take additional routes and waste energy!

mindforger on 4 Sep 2015

Mind, this sounds severely complicated .-.

BluSunrize on 4 Sep 2015

@BluSunrize how about summing up what you're planning so far? Everything that mindforger says is just plainly too confusing to read, and all too likely too confusing to be in any mod.

VermillionX on 4 Sep 2015

yeah ... and you know what ... i just found a big ol messy bogus in there ... when i calculate the routes, i seem not be able to see beyond transformators ... this .. kinda .. killed my whole idea

well even with your old system, still i may have your failure prone map problem solved, but you need to wrap yourself a multimap :P i'll post it on my fork this evening

mindforger on 4 Sep 2015

I don't know all the technical terms that Mind uses either. xD
The actual, limit PER TICK on Wires is my new plan for the energy system. Whether I can implement overlaoded lines in there, I do not yet know, that depends on what implementation I come up with
A more pressign matter is the fact that I took step one of changign the systme today, by changing every refernece of ChunkCoordinate to IImmersiveConnectable instead.
This was made for take of issue #386 where IE apparently ghostloads chunks.
Also this /might/ allow connectors to be moved with frames or such, provided the frames are written well.
The issue with this is, that I somehow killed the SaveData system in the progress, and now I can't get wires to save at all.

BluSunrize on 4 Sep 2015

Changing everything to work with the IImmersiveConnectable may not be a good idea since that usually means the tile entity of the block and those contain calls to getTileEntity quite often. A different approach would be to check World.blockExists before World.getTileEntity. That may also reduce memory usage, since tile entities probably take up more memory than the chunk coordinates

malte0811 on 4 Sep 2015

I guess, yeah, but that'd break transfer across unloaded areas, no?

BluSunrize on 4 Sep 2015

no other mod can transfer across unloaded areas except actual teleporting the energy from point to point!

mindforger on 4 Sep 2015

Yeah, but people actually appreciated that fact about IE >_>

BluSunrize on 4 Sep 2015

even if you will make this possible, you'll get strange behaviour, like after a dimension got loaded the network will completely be unloaded, until you walked the whole area once .... so the net won't work at all... one short question about the API here, can't you write "getStorage" and "getMaxStorage" methodes to mirror the actual storing block connected to the wireconnector? i would almost guess this would make EnderIO working better with your cable ... or is that not allowed by any means that i did not see

mindforger on 4 Sep 2015

Then, I guess it doesn't count as transferring across unloaded chunks if it's ghostloading them. last I remember, someone told me ghostloading was actually worse. xD

BluSunrize on 4 Sep 2015

new feature: multiblock chunkloader! scnr

cobra on 4 Sep 2015

Wait, IE can transfer power over unloaded chunks?! I was under the
impression I had to chunkload every point on the network. :confused:
Because straight lines are easiest to build over, I have just been using
rAilcraft anchors with sentinels to chunkload the line. Or.. At least
that's how I am doing it now... Based on a false impression.

@blusunrise, can we go ahead and summarize everything that has been agreed
upon for change? This thread is getting long :D

@blusunrise, I will ask you again, what do you think about adding circuit
breakers?
On Sep 4, 2015 6:04 AM, "cobra" [email protected] wrote:

new feature: multiblock chunkloader! _scnr_

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

theunkn0wn1 on 4 Sep 2015

My nick is spelled with a Z, Sunrize. xD

And yeah, circuit breakers should probably be a thing. for one, I want one toggleable with redstone so that people can turn off their electric lanterns during the day, and I guess we also need one that stops overcharges lines.

I guess the "agreement" would be:
1) Transferrates on wires will actually be per tick now
2) To compensate, the maximum transferrates will be boosted up considerably.
3) As possible, I'll try to implement an overcharge system, making wires burn up (hopefully with some nice flame particles, lol)
4) To prevent 3), circuit breakers, capacitors and transformers in between will prevent the "burn up" to jump between segments

BluSunrize on 4 Sep 2015

How about implementing simple non-linear decay like:
P(L) = P0 * L0 / (L0 + L)
where P(L) is output at length L, P0 is input and L0 is a constant ?
Or is division like that too costly operation to implement in such time-critical point ?

L0 would be simply scale of the cable loss, so that at distance L0 half power is lost. It could be parameter of wire type. Implementing such non-linear decay would mean that _some_ power always makes it through, even if you try to send it to the other side of the world. Being non-exponential, it would not inflict unbearable losses at longer distances, while not being completely ignorable at shorter.

Example how current and proposed compare.
Currently Pc(L) = P0 * (L0 - L) / L0
If we scale it that half power is lost at the same distance as now (current L0=320, proposed for this condition L0=160), then for HV wires we get following fraction of power transmitted (distance, current -> proposed):
16, 0.95 -> 0.91
64, 0.8 -> 0.71
160, 0.5 -> 0.5
320, 0 -> 0.33
640, -1 -> 0.2
1600, -4 -> 0.09

This doesn't solve issues of forcing appropriate voltage, but I think would solve the issues of power loss with distance, allowing long-distance transfer, while still imposing penalty even on smaller distances.

dantedarkstar on 4 Sep 2015

Yeah but that would makes transfer over short distances even worse. Ideally I'd like a calculation that is still worthwhile over distance

BluSunrize on 4 Sep 2015

If the same L0 would be used as current "maximum range", then you get all across board better power transmission:
16, 0.95 -> 0.95
64, 0.8 -> 0.83
160, 0.5 -> 0.67
320, 0 -> 0.5
640, -1 -> 0.33
1600, -4 -> 0.17
What I'm proposing is the type of dependence, the formula, not the values of the constants (I assume you know what kind of transfer efficiency over distance you want to achieve, I'm just proposing a "tool" that maybe fits that vision).
If you want to set the cable to transmit P fraction at distance L, you can inverse the formula to calculate needed L0 as L0 = L P / (1 - P)

some more musings about different formulas

If this formula results in too slow decay with distance (after setting L0 that fits one point of your envisioned transfer efficiency), then perhaps square dependence would be what's fitting
P(L) = P0 L0_L0 / ((L0+L)_(L0+L))
(I specifically did not use exponent notation here so it's clear it is still computationally not much more complex than previous)

At extreme end, one could use exponential scale
P(L) = P0 2^(-L/L0)
but that would require much more computational expense at computing exponential function with non-integer exponent.
Exponential function would mean losses rise fast with distance, although it can still be scaled. If L0=320, then trying to transmit at 320 would yield half power, quarter at 640, 1/8 at 960, 1/16 at 1280 and so on, with mere 3% transmission left by 1600 meters (compared to 17% left with my first proposition, when both transmit 0.5 at 320 meters).
The only advantage of exponential function is that adding transformers/batteries interposed along the line does not change the overall efficiency of transmission. In current implementation adding such would increase power transmission, while in proposed P(L) = P L0 / (L0 + L) adding capacitors along the line would decrease efficiency.

dantedarkstar on 4 Sep 2015

Hey guys. Quick question. Do you think these changes would reward building "electrical substations," or areas that have multiple transformers to better handle step-ups/downs? Or will that kind of mentality not prove beneficial?

Voxel-Friend on 13 Sep 2015

Wikipedia link for those who are unfamiliar:
https://en.wikipedia.org/wiki/Electrical_substation

Voxel-Friend on 13 Sep 2015

Honestly, the idea of substations is siding do already with IE, before
these changes just because it is more immersive. I would love it if
substations are rewarded though I have not yet had an opportunity to play
with the changes yet. From my understanding of the changes, yes substations
become a requirement for IE power transfer over a distance \ later game
when HV generation becomes optimal. Not all the changes have been
implemented yet, so none besides Blu can answer that with certainty.
On Sep 13, 2015 12:07 AM, "Voxel-Friend" [email protected] wrote:

Hey guys. Quick question. Do you think these changes would reward building
"electrical substations," or areas that have multiple transformers to
better handle step-ups/downs? Or will that kind of mentality not prove
beneficial?

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

theunkn0wn1 on 13 Sep 2015

Alright, I've started work on rebalancing the transfervalues with the new system.
My idea is for LV to allow 2048 RF/t, MV 8192 RF/t and HV 32768 RF/t.
The inputs stay the same, effectively making it so you can unify up to 8 inputs into a single wire without burn.
Now the thing that I'm still antsy on is transferrates. I'd rather not make it to complicated, but I'd still like MV and HV to have separate purposes. So I'm considering adding a "modifier", that is calculated based on the power send and the max value that could be sent fro ma connector.

Example: A generator (any kind) produces 256RF/t and inserts it into an MV connector which will accept up to 1024RF/t. It's only using 25% of it's potential, so I'm considering increasing the loss by ~30% (10% per missing quarter?)

I'd like opinions on this, especially from @cobra, @malte0811 and @mindforger

BluSunrize on 13 Oct 2015

I don't get it...
Wouldn't changing the transfer rates to that basically defeat the purpose of having different types of cable? I'm probably misunderstanding something in there.

VermillionX on 13 Oct 2015

Not quite. I buffed the maximum transferrates to 8 times the original, but wires can now burn, so while unifying multiple wires into one is possible, it is also only possible to a certain degree. The case of loss still exists, and linear loss is one of the things that was critisized in the past, which is why I want to change it.

BluSunrize on 13 Oct 2015

i like the idea, especially because you can overload the cable, so you can deal with spikes to a certain degree!

and for transformer, give em an intelligent input, they ONLY accept any hv or mv input, when there is enough space to receive a whole one time line capacity once until their buffer drained enough to accept more ... so can a transformer at the end of a line make it always use up it's capacity and prevent any underrun ... for the other direction, if the buffer is full try to push the whole load at once .. if the receiver can not take all, the design is poor and needs to be punished

mindforger on 13 Oct 2015

Well, since I didn't go wit the power packet idea, transformers do not have any internal storage...

BluSunrize on 13 Oct 2015

There's been so many changes to power in 0.6.0 and I have no clue how it works since 0.5.4.
LV Cables now transfer 2048 RF/t(?) and burn when? Better yet, why?

Please explain for those of us still stuck on 0.5.4 how the power works now, without all the coding talk included.

VermillionX on 14 Oct 2015

@BluSunrize I have no complaints. I approve of higher maximum transfer rates whilst keeping the per Input/output rates the same as well as punishing inefficient setups.

@VermillionX Power works as follows:

The transfer rate Per Cable is _currently_ limited to the max transfer rate of one connector.
If you attempt to funnel more power into the line than it can carry, the line melts.

for example, HV can _currently_ carry 4069 RF/T, thats one connectors worth. If you connect two Inputs and outputs with One wire in the middle, the middle wire will melt. This bad setup is shown below:

The above will not work as of current as you are transfering the power at twice the cables capacity. You loose the wire if it melts.. obviously.

theunkn0wn1 on 14 Oct 2015

Well, yeah. That's common sense. I figured there was some technical reason why the cables' transfer rates were being buffed that much. Guess not.
But now, there's pretty much no reason for an MV capacitor to use MV cables, since now LV Cables can handle multiple MV inputs without problems. Similarly, HV Capacitors can use MV cables in the same way.
Instead of increasing the rates by 8x their current values, why not just x3 or x4? 8x seems excessive and easily allows levels outside their intended voltage range into cables not intended for the purpose.
If someone's trying to put even more than that into a cable, they should really be using multiple parallel cables instead of trying to fit everything into a single cable.
Aside from the Arc Furnace and Excavator, nothing else could even consume that much. Even a dozen Crushers couldn't (Seriously, why are the machines so cheap to run and the generators produce such a massive amount of free RF?).

VermillionX on 14 Oct 2015

"(Seriously, why are the machines so cheap to run and the generators produce such a massive amount of free RF?)"
you haven't worked with AE2, used an excavator yet or used other mods at all, haven't you? ... 4k RF/t is a well ammount and to keep it permanently running you need quiet a bit of farming effort!
When you consider Mods like Big Reactor you could easily ask why 23k RF/t and 2mio RF/Yellorium Ingot ... there are plenty mods using an enourmous amount of RF and the excavator itself runs around 2 days on static 4kRF/t .. i do not like crunch on numbers, but you'll need a LOT of barrels full of seeds and 4 times the amount of "fruits" to ferment to keep it running .. (those number are just rough guesses by what i played with that mod)

mindforger on 14 Oct 2015

@mindforger Could not have said it better myself..

The proposed changes make little difference to those who keep their systems
small while expanding the capabilities of those of us who strive to make
big, powerful systems. If you have not found a proper use for HV yet, then
you don't know true modded Minecraft on the tech side.

The different tiers will still have meaning is their max transfer rates per
line are buffed, as the lower tiers will still be favorable for small
systems whilst allowing the bigger tiers to become useful for applications
they would be found in.

There is always reason behind anything a programmer does, regardless of how
obscure that reason may be. :)

Edit: my tablet went to town on the formatting.. sorry :/

theunkn0wn1 on 14 Oct 2015

I've worked with all those mods, for many years. In fact, i've played with almost every decent tech mod released for the last 4 years. But we're not here to discuss how one of 200 _OTHER_ mods work with IE, we're here about IE in it's perfect form, by itself. Or at the very least, how it interacts with mods of a similar aesthetic and functionality work with/compliment it (e.g. The Holy Trinity: _BC, RC & FR_).

What i'm seeing from you two, is a simple _'murican_ desire to just have more. Regardless of whether you use it or need it. Instead of being satisfied with running a single excavator for an hour, for more ores than you'll ever need, than an entire server would ever need; You want to run a dozen excavators and have a dozen BR Reactors to do so simply because you could do it, regardless of whether or not you should do it.
_insert Steve Goldblum meme here_

VermillionX on 14 Oct 2015

Relax fellas. I do aknowledge the fact that these values may seems blown out of proportion, but in fact, even with IE, bigscale production and consumption is possible. IT may not be common, but there are RP multiplayer servers, which run an economy system on energy. With the planned Energy Meter in IE, people will be able to "sell" power to other members of the server, and the ability to have a single HV line to a substation and then multiple MV lines to the houses is actually a nice way to deal with that sort of thing.

Now stop going at eachothers throats and appreciate the effort each member of this discussion has made to help IE take the step towards a new and balanced power grid.

BluSunrize on 14 Oct 2015

@BluSunrize sorry in first place for not bein relaxed about somebody flaming without bringing in something usefull but complaining

@VermillionX [content moderated because of slight rage]
you could have asked more nicely and not being insulting in the first place! ... i am from germany so do not murica me!
playing one mod alone does not make the point
and bluesunrize, who cares of balancing with other mods did a very well job here

ore processing is somewhat early- to mid-game and thus pretty cheap as you do not need awefull lot of steel

later with your "ore-gen" aka excavator you'll have to put way more effort into it to keep it running .... i must admit, there is some machinery for mid tier missing now, but therefore other mods fit this space very well! and IE is adding up with that pretty good and balanced

i again begging for excuse here to not keeping it down but [...] this one was the straw that broke the camel's back (this is some wierd translation)

mindforger on 14 Oct 2015

OI! Mindforger, I said stop. I will not tolerate anymore ranting my my github from anyone.

BluSunrize on 14 Oct 2015

@BluSunrize I'll move my issues with balance to a seperate thread. For the most part IE is well balanced with what there is. Though as mindforger said, there does need to be some mid-tier machinery/fuelled power gen. Instead of relying on a 3rd-party mod to fill the gap.

@mindforger I was not being insulting. I asked a serious question about IE with a comedic slant, to which _you_ replied insultingly to.

Back to the topic:
@BluSunrize So, the greater the distance between the input voltage and the maximum transfer rate of a cable increases the loss? That should keep people from putting lower voltages into higher cables; but with the 8x maximum rate, it would mean that the low output generators like the Wind Mill (seperate in this instance from the Watermill) would suffer the most due to the massive disparity between the minimum and maximum range of the cable. So once again, I suggest changing it from 8x to 4x to reduce that gap and prevent higher voltages from being put into cables they're not meant to be put in. Ideally, 3x would be better but the numbers (768, 3072, 12288) are a bit irregular to people familiar with the usual progression rates set down by IC2 that seems to have pervaded still; since 4x would still allow people to put higher voltages into lower tier cables without suffering any of the loss bonuses of using a cable of its intended tier.

VermillionX on 14 Oct 2015

@VermillionX No, the loss is increased by the distance between the input and the max input of the connector. So putting 256RF into an HV connector which can take 4096RF, means you are only using a 16th of it's capacity. That means you are wasting 93.75% of the potential, and for each 25% the loss increase by 10%.
It sounds complex but is quite simple:
256 in 1024 = 75% wasted potential, that's 3*25%, loss increases by 30%
256 in 4096 = 93,75% wasted potential, that's 3.75%, loss increases by 37.5%

In the end, this is to motivate players to use LV when dealing with windmills, rather than making HV the answer for everything.

BluSunrize on 14 Oct 2015

@BluSunrize, is the static over-distance energy loss going to be redone as well? I find it quite disheartening how low little distance HV can go. Perhaps the closer we get to max voltage for the given, the exponentially slower the decay and therefor the greater distance the current can travel?

theunkn0wn1 on 14 Oct 2015

a friend came up with some simpler logic but it maybe unfitting to the current plans: additional to the capacity punishment, the loss gets calculcated by hops instead of blockdistance + more range on HV and a bit less range on LV ... you can bridge long distance with lesser hops using HV thus making HV "cheaper" in loss over the same distance compared to the other wires, but it requires you to produce enough power or some sort of logic to not underrun the line capacity

this remembers me of "contact resistance" when you plug a wire to a wire to a wire, gaining resistance on every connection ... well but still might be unfitting for your current plans

@VermillionX i guess you were offended by my expectance of low experience on your side.. i see that and apologize i was truly implying you were not aware the other mods when talking about OP with 4kRF, why i enganged was, that I felt insulted by the "muricanisation" and some sort of WTF moment

mindforger on 14 Oct 2015

well, I'm nerfing the general loss of HV @theunkn0wn1, it'll have the same loss as MV, and the additional loss thing described above is to discourage from running it instead of MV in your base ^^

So yes, loss stays linear, but HV loss is getting way better.

BluSunrize on 14 Oct 2015

Ok. Fair enough
On Oct 14, 2015 8:19 AM, "BluSunrize" [email protected] wrote:

well, I'm nerfing the general loss of HV @theunkn0wn1
https://github.com/theunkn0wn1, it'll have the same loss as MV, and the
additional loss thing described above is to discourage from running it
instead of MV in your base ^^

So yes, loss stays linear, but HV loss is getting way better.

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

theunkn0wn1 on 14 Oct 2015

No reason to leave this open any longer...

theunkn0wn1 on 17 Feb 2016

Can we have that EHV line with 32k RF/t? I'd like to have this 765 kV line :D

Some fun wiki info:
For example, a 100-mile (160 km) 765 kV line carrying 1000 MW of power can have losses of 1.1% to 0.5%. A 345 kV line carrying the same load across the same distance has losses of 4.2%

cpypcy on 28 Oct 2016

Except that there is no concepts of Voltage, Amps and Watts in RF.
So what you are asking for is simply "more RF per tick" and the answer to that remains no. 4k is more than enough to power any sensible base ^^

BluSunrize on 28 Oct 2016

👍1

Sensible base? 1 excavator eats 4k alone! Let's say you have 4 so you have to have 4 wires just for that, 1 wire for ender quarry and 1 wire for everything else.

cpypcy on 28 Oct 2016

You can transfer up to 4x the max transfer per connector on one line. You
can tinker with edge config values if it bugs you that much

On Oct 28, 2016 6:25 AM, "BluSunrize" [email protected] wrote:

Except that there is no concepts of Voltage, Amps and Watts in RF.
So what you are asking for is simply "more RF per tick" and the answer to
that remains no. 4k is more than enough to power any sensible base ^^

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/BluSunrize/ImmersiveEngineering/issues/362#issuecomment-256919333,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC94SoMDMFXs9WIinK3PNyB4nFnXD8SUks5q4fe9gaJpZM4FzpFT
.

theunkn0wn1 on 28 Oct 2016

👍2

For one, ^ that.
Wires take more power than their connectors input.

Secondly: Posts have multiple places to put wires on. One wire not enough? Run more wires. xD

BluSunrize on 28 Oct 2016

👍1

Also, EnderQuarries don't fall into my definition of "sensible base" anymore, not with the copious amounts of imbalance that Tema has been churning out lately.

BluSunrize on 28 Oct 2016

👍1

I think you don't understand how the wires work (unless I don't understand it...). One connector will accept/output 4kRF/tick, but multible inputs can be fed into one transmission line. At 8 times the input value (so 32kRF/tick), the line will break down, but it is perfectly possible to power 6-7 excavators of one HV line with 8 inputs (and an 7th/8th excavator at lower speed due to losses.)
Edit: I guess I am too slow. But is it 8x or 4x?

malte0811 on 28 Oct 2016

👍2

@cpypcy then crank up your installation ! That's the point of the game :) Beside the Ender quarry is out of scope imho.

I can't recommend more to anyone interested in the power systems to watch the last video talk about it from Amadornes. He clearly explain those kind of things.

kane-thornwyrd on 28 Oct 2016

So i can just feed multiple connections to 1 wire and it will work? HELL YEA! Time to fry some wires!

cpypcy on 28 Oct 2016

🎉1 👍1

I was doing some research on this topic and came across this thread.

My understanding of the changes made after this thread were to mess around with the line loss and transfer rates, correct? So far, this seems to work pretty well.

As a power engineer, this system is pretty analogous to real world networks. I think too many people were trying to overthink the issue at hand and got too deep into the weeds. Going that far down the rabbit hole tends to cloud the issue IMO. Keeping the drop linear is fairly close to how I have handled line drop characteristics. RF is more or less a DC system. You have a driving system (a generator or battery) that powers a downstream load. Line losses need to be compensated at the generation end, and that’s how this system is working. I treat RF in this case the same way I would treat volt-amps or watts (watts is just the real part of VA, so if you’ve ever looked at UPS backups, you’ll see VA used in lieu of W as some manufacturers might assume no imaginary losses). If I have a load that requires X RF/t, my line consumes Y RF/t based on X, then my generation needs to produce Z=X+Y RF/t.

RF was called a push style system. That’s pretty analogous to DC systems. DC is really more of a push/pull system, but in computer terms, push only works quite well enough.

I’ve ran some calculations of my LV setup inside my base being powered by dual water wheels, and I’m within the rounding zone for RF/t required due to line loss. I have a CT set up next to my transformer input into the base, and with my two external heaters powered, the CT sees about 66 RF/t flowing through it. I calculated that I would see around 66.9 RF/t. So, assuming the code truncates the floating point part for an integer output, I’d say I’m close. This was done using some pretty basic line compensation calculations, so you can see Blu’s done a good job mimicking what I would expect. I can go further into this later if anyone really wants me to, but I’ll just leave it at “trust me, I’m an engineer” for now.

Now, I do have some suggestions to fix this LV versus MV issue. So, one complaint early on was that transformers are useless. I agree. There’s no rational reason to use LV at all. Electrum is pretty easy to come by, and let’s be honest. If you’re farming the Nether to get blaze rods, you’ve already teched past copper. The only reason to use LV is to power lanterns. At the point most people will be in game, it’s more time efficient to jump past copper LV stuff and run straight to MV for distribution. But how do you fix that? If you rebalance LV to be better than MV, then people will just run straight to LV for all their distribution needs. What would be most ideal is if you have a generator (diesel in this case) that outputs MV, and you use MV to run across your base. Once you get close to your loads, then you use a transformer to step down to an LV network to power your load. One way you can try to make this happen is force low power requirement objects to take only LV connectors. Why does an external heater need 1024 RF/t? It doesn’t. My entire LV network MAXES at 255 RF/t assuming worst case losses just before the transformer (that’s 2 external heaters, one preheater, and one crusher). Forcing players into a play style is never ideal, though, but I think it may be a necessary decision to keep LV as an option in late game usage. What I would then consider doing is reducing the loss from the LV network. Say from 5% to 3-4%. By keeping the losses above MV, MV is still the preferred medium range distribution choice and HV retains its transmission title. If LV is reintroduced as the ideal base distribution for low power equipment, then transformers automatically become useful again.

So let’s go back to using a diesel to power the base. The diesel’s output can be sent by MV lines to an area on the other side of the base and pass to a transformer’s primary. The transformer’s secondary then outputs to an LV network to power a network of machines. If you have a mix of LV and MV equipment (say running some heaters in the same room a squeezer and fermenter are in), the heaters could get LV power off the transformer while an MV relay is put just upstream of the transformer to send power to the squeezer and fermenter.

I do have some other things I could suggest, but they’re primarily quality of life changes. In an attempt to keep this ticket on target, I’ll refrain from discussing them.

TL:DR
-Power is handled fairly well in its current form. No need for additional complexity.
-Make low power equipment require LV connections
-Reduce LV loss to 3-4%
-I have some other ideas for distribution, but trying to keep this post focused and relevant.

GB-Hijacker on 20 Dec 2016

Just gonna say that the modifications had been made a while ago, the observations you have of current IE builds are reflective of what we came to agreement on.
The changes spawned from what I observed to be how HV cables ended up having significantly less effective range than mv cables and my I'll fated suggestion to resolve it.

The max RF load per line was increased to -iirc- 8 times the transfer cap per connector, so we can carry 8 MV devices at full power without burning out the cable.
All resistances were reworked though the overall linear resistance remains.
Cable burning became a thing as to prevent abuse and be a little more immersive. Resistance leads to heat, right?

IE is indeed a DC system, you could see the rabbit hole we (or should I say I) fell into trying to implement AC; that idea is on the cutting room floor.

Lv is intended, IMO, to get players off the mud like wood and stone tools in vanilla, not power utilities effectively.

You can change the resistance values of lv cable within IE's config file to fit your desires, if you wish.
Edit: autocorrect...

theunkn0wn1 on 20 Dec 2016

Was the necroposting on a almost 4 month old thread really necessary? With that novel you wrote, you might as well have opened a new one .-.

Anyways, to make the point: There is basically no way to force the use of LV connectors.
Problem is that you basically can't "detect" the type of connector that is giving you power, bar actually going "TileEntity is an LVConnector".
And if you check for LV connectors specifically, which makes IE machines completely incompatible with any other mod-added cable, which is a woefully bad idea.

So yeah, there's that.
Also, people would flip the fuck out if a connector type was forced on them. You can't pull that sort of shit when working with Flux. IC2 can do it since they have their own power system, and a separate target audience, but me, working with the Flux based systems, can't.

BluSunrize on 21 Dec 2016

Immersiveengineering: [feature request] EHV power transfer lines

Most helpful comment

All 117 comments

"WARNING: MACHINES MAY EXPLODE DUE TO THIS UPDATE, WE ADVISE THAT ALL IE CABLES IN YOUR WORLDS ARE DISCONNECTED BEFORE UPDATING"

Related issues