Better Electric Circuit Management?

[jape670]

So, I just started playing the thermal update and I gotta say managing your electric circuit is really tedious and annoying. It feels really limiting to me right now rather than just being a design thing you can work around. I think there needs to be some sort of new mechanic for managing wires that allows you to get more creative because at the moment in the thermal upgrade it feels really limiting. 

[tehMugwump]

Welcome to the forums @jape670 !

[jape670]

1 minute ago, tehMugwump said:

Welcome to the forums @jape670 !

thanks

also actually for the third choice why couldn't it be that the circuit would just divide wattage depending on where it's going. Like if you split the wire into three lines. Each line would only carry the wattage needed for the circuits down its path. 

[scientas]

Maybe have the batteries pop up a list of connected machines (like the dupes in the job list) but with priority numbers and a summary of the load on the battery?

[Kasuha]

I think calculating the load properly on general circuit is way too complex and would have potential to to cause serious performance problems. Simplest reasonable solution is to track back to unrestricted wires. With 25 kg of metal per meter of wire, that's not a wire, that's a rail and it can carry a few megawatts.

Another solution would be to restrict the player to non-looped circuits for which load calculation is very simple. But that would come with a whole lot of problems in implementing the restriction.

And with calculating the load, the heavy wire should be able to take at least 10 kW, just twice the normal wire is a joke.

[Masterpintsman]

Current [TU] electricity system is an argument to not play this game. Seriously.

@Cheerio In case you don't want to listen to @Kasuha:
Calculate the actual current flow through each part of a wire, so we can branch off smaller ones from the bigger ones.

A* is a cheap algorythm when used on a wire net (as there are not that much nodes to traverse), following implementation would be feasible runtime-wise (warning, pseudo-code):

===================================================================

On network change (build / switching) calculate the graph to get three lists:
B1) nodes being the endpoints (producers, consumers, batteries)
B2) nodes being wire intersections
B3) edges being the wire connections beween nodes (keep lists of the tiles in these)
B4) endpoints in the middle of a wire split the wire into three+ edges, one (without tiles) to the building, two+ with the actual runs of wire - effectively they add an entry to B3 (with empty tile list)

On tick make a copy of these lists (or create temp lists with pointers to them, whatever is faster), iterate list from B1 it to get max supply from producers, max demand from consumers, and maximum buffer from batteries. Account the buildings with the M=maximum_transfer_capacity (being the buildings power production / min(battery_wattage,filllevel), demand / min(battery_wattage,free_capacity) while at it.

Total buffer delta D = |production-demand|, according to demand vs. consumption set the buffer direction for how to hande batteries (feed for delta<0, absorb for delta>0).

Iterate the endpoint node list randomized (so the network is loaded somewhat evenly over time), skip buffers (batteries), process each producer/consumer found (calling this X):
T1) do pathfinding (A* or something that fits the problem) along the edges toward the nearest (sum(least #of tiles) in edge list, least edges) building Y being able to satisfy X (producer: search consumer or battery on absorb / consumer: search producer or battery on feed), keep the list of edges of that path as L
T2) reduce transfer capacity MX and MY (of this and located target) by E=min(MX, MY) [E=min(MX,MY,D) and D-=E when Y=battery], E being the amount of energy transfered between these two buildings
T3) if any of the buildings exhausted his capacity (M) in T3, mark it it/them in the endpoint list copy and recursively mark orphaned edges (where the endpoint has been removed) and orphaned nodes (where only one edge is left) in B3/B2 list copy to reduce lookup times for the rest of the loop.
T4) account E (transfered energy amount) as energy flow to the edge(s) in L, signed according to flow direction through it (one direction +, the other -) as F
T5) in case this building has M left, restart the loop with the same building X

Iterate the list copy B3 of edges, look at |F| (absolute value of the flow) and apply the effect of the energy traversed through the wire tiles to them. Best plan for this would be to use a moving average per edge over the last some ticks to even out short spikes from the randomisation.

===================================================================

This algorythm won't be prohibitively expensive runtime wise. By design it'll model the effective flow through each tile of wire (flows between different building in opposit directions through the same edge would cancel themselves out) which would be a step forward compared to the current max 2KW per network, I'll uninstall it.

It won't deal with parallel wires / loops (for this the pathfinding would have to flood the whole network for each building to find all paths toward the next satisfying building, possible but will be more expensive calculation-wise, maybe doable by letting the pathfinder run some more edges to find another possible path to spread the load between them).

A possible optimisation would be to account a running average of he path length found in T1 and sort the B1 list copy on it descending (insatead of random), this would unravel the the graph faster but would lead to external producers/consumer being be prefered (and central ones starved) in case of supply/demand asymetry - so I think the random approach makes more sense to statistically distribute over all buildings in all circumstances.

/me taking a hiatus till the wire issue gets an update, as it is I hate it enough to spend my free time on another timesink.

[Vincie]

Well... Could it be just simple Kirchoff laws and Ohm law? And really, I would love both multiple wires in a single tile and fuse boxes. With levers and visible amperometers <3 Also underprosuction of energy should end in tension loss. And it would be very fun to see transformators and power inverters in game - there may be both AC and DC devices (like batteries and everything else), requireing different voltages. More cables is more fun.

And it would not be as fun as it could be without logic nodes with a set of sensors as well.

[Kasuha]

9 hours ago, Masterpintsman said:

T1) do pathfinding (A* or something that fits the problem) along the edges toward the nearest (sum(least #of tiles) in edge list, least edges) building Y being able to satisfy X

That wouldn't work right for a simple grid "battery A - wire 1- consumer X - wire 2 - battery B - wire 3 - consumer Y - wire 4 to battery A" - either wire 1/3 or wire 2/4 would get full load and the other two wires would carry nothing.

Proper implementation has to consider all paths between each two producer/consumer pairs (with batteries playing role of producer or consumer, depending on supply/demand) and balance the transfer over all of them. Considering a player can make a wire mesh in the base, that can get exponentially complex to evaluate. So I believe restricting to non-looped grids and calculating the load over them would be the simplest proper solution. We can assume dupes can't do wires right so every time they close a loop, they make a short circuit and the new connection fries.

Checking for loops can be done using simple set union algorithm.

Evaluating load on a tree is easy: first figure out supply and demand over fixed producers and consumers. Then decide if batteries work as consumers or producers now, and proportionally distribute the excess over them. Get to the situation where supply equals demand and it's decided what producers and consumers are there and how much producing/consuming each of them is.

Then scan the tree from leaf nodes inwards, adding producer/subtracting consumer values on each node and only evaluating branch nodes after all outward branches are evaluated. The trick is that the load is on connection, not on the tile - but the wire tile may fry if there's overload on either of its connections. 

[Masterpintsman]

29 minutes ago, Kasuha said:

That wouldn't work right for a simple grid "battery A - wire 1- consumer X - wire 2 - battery B - wire 3 - consumer Y - wire 4 to battery A" - either wire 1/3 or wire 2/4 would get full load and the other two wires would carry nothing.

Proper implementation has to consider all paths between each two producer/consumer pairs (with batteries playing role of producer or consumer, depending on supply/demand) and balance the transfer over all of them.

Could be solved by allowing the pathfinder to look forward another some edges to locate a few additional buildings that match, then distribute evenly among all found (or proportionally weitghted by wire length to them) - just or pick one randomly and let statistics even it out.

I would be fine with wires not behaving like in reality, we don't need a perfect realistic simulation as an approximation would do.

 

49 minutes ago, Kasuha said:

Considering a player can make a wire mesh in the base, that can get exponentially complex to evaluate. So I believe restricting to non-looped grids and calculating the load over them would be the simplest proper solution. We can assume dupes can't do wires right so every time they close a loop, they make a short circuit and the new connection fries.

Checking for loops can be done using simple set union algorithm.

That would be an additional option to force simplification of the wire network.

But for the current flow calculation such an algorythm would be needed anyway, so I would start with it (or similar) and see if it plays out good enough before letting dups become idiots when it comes to connecting wires the right way...