Handling different electric networks

[ssilk]

I think the current behavior of building networks is notable to handle separated networks.
I think I try to bring some ideas together right now.

Definitions: a network is the combination of pole and cable. A single pole is just a device. See also this:
http://en.wikipedia.org/wiki/Graph_(mathematics)
Which means, that a network is a graph, the poles are the vertices and the cables are the edges.
The problem is now, that we can have many graphs at the same place and they should not influence each other.

Some simple logic:
1. to make a network to be turned on and off we need to separate it from other networks.
2. To separate it, we need not to autoconnect it with other networks, only with the same network.
3. To see the different networks we need to see visually, how it is connected. Visually means: there is for example a number on every pole, or they have different colors.
4. To connect one network to another needs just a pole and some wires.
5. To keep networks separated, but transfer power from one network to the other needs a special device/pole/item. And only one is allowed, otherwise there is no control over it.

How to build a network:
The simplest way would be: place two poles and then draw a wire between them. With that, everything is in the hand of the player.
But this is quite uncomfortable. So i think the current way was implemented: placing a pole and it is connected to the next pole. But this doesn't work anymore, when you want to prevent to connect networks together. I suggested some month ago to press some keys, to avoid that (shift, control), but now I think that was only shifting the dead end.

Currently I think we need to rethink the whole network stuff. I think we need to think in use-cases, and not in how to built a network, because a) there is just no solution for every case of making networks with some kind of ever same operating half-automatism. b) building networks is just placing a pole and make the wiring, this is simple and the half-automatism takes away the whole magic, because of its stupidness.

Use cases:
1. I just want my devices to be connected to the next network with lowest effort.
2. I want to build a new network or divide one network in two.
3. I want to join two networks into one.
4. I want to join two networks, but keep the control of how much/when energy flows from one to the other.
5. I want to have a device connected to a network, even, when another is more near.
6. I want to connect as much devices as possible with minimal effort.
7. I want to get an overview of my different networks.


I mean with this thinking you come to completly different solutions than now. I describe now one, based on the above use cases:

case 1: you drag a wire (by dragging the base of a pole or need special tool for that) from an existing (connected) pole to the target-destination. The target can be far away! All poles inbetween are set for the minimum used resources and if they are available (ready crafted yet) while you drag it. If the target is just an empty field, an pole is automatically built there. Provides, that you have enough poles left. The poles are built when I'm at the target and I release the mouse button.
I mean it is ok, that I can draw a 200 tiles long cable without building any poles, because you can see the poles as they would be built, you can at every build it as it is now and you can right now built cables, which aren't in your reach (they must be in the reach of the poles, not yours.)
Case2: just remove a pole, so that the networks are distincted. Or place a new pole and drag a cable (see case1). A single pole is not creating a network and they should be marked in some kind.
Case3: drag a cable from a pole in network to a pole in the other.
Case4: place the device, which keeps the control over the two networks and drag a cable into it from both networks. The electrified area around the poles are ignored.
I'll call the device transformer, because its function is nearly like in real networks. From one network to another, only one transformer is allowed (maybe we have transformers which have a direction, but that is only a special case). Otherwise there will be a short and the transformers explode. The same when connecting a cable, if there is already a transformer (should be warned in some kind before doing this, like the wire you drag becomes some flashes if you go near the pole you want to connect.)
Case5: you drag a wire from the pole you want directly to the device. Like wring a pole. In this case the electrified area around a pole is ignored. I really think this new type of connection is needed, but please try top prove me wrong!
Case6: by selecting an area and dragging them to a pole (or some similar mechanism) will start a program, which uses a simple algorithm to place poles so, that the area is as far as possible fully connected. This will spare some time, but I'm not sure, if it could be that simple. But when working more or less reliable it should really help.
Case7: as said above the poles have numbers for the network they belong to, or they have some colors... Many possibilities. In the map I think a electrification mode would be good, where you see the different networks in different colors and where are the sources and destinations in more or less the same color.

I mean this is not perfect and there are many open questions, but I think this dragging of a pole was a really good idea because the problem with placing a pole and then connecting it is, that you need to know to which network. This is the showstopper for the current way of creating multiple networks and this suggestion avoids that.

[n9103]

An easy way to control the connection(s) a pole makes, is placing a dummy pole between the poles for the networks you don't want to connect to, and remove it after placing the intended pole, thus severing the connection.

For transferring power, you can use a capacitor that's in both the concerned networks, adding more in parallel to increase the throughput.
This becomes problematic if either network also has other capacitors outside of these transfer points however.


Those methods aside, both could use a better system to work with.

[ssilk]

Yes, good points.
I want to turn off a production line, some assemblies, a whole mine, or only some inserters, the complete research or every second laser. This is currently really difficult. I want to make that much easier.

[n9103]

Perhaps you'd benefit most from a better power pole layout.
Setting up power from a central trunk and running out a string to each of the places you need power, keeping branches separate for each area you want to cut off together.

[ssilk]

That provides, that you have a central trunk. But I want especially, that this isn't the case, I want to let the player freely decide how to built his network. Perhaps he came to the conclusion, that every production line needs own steam engines. Or some weeks ago I built a network only of solar cells, because it was very far outside and I didn't need a constant flow of items.
And many other things how to built it are thinkable and my suggestion is more or less only to let the players decide how to built.

[n9103]

Well, I can only offer a phrase used often in my career:
Piss poor planning leads to poor execution.
Trying to change the system to account for poor planning is a bad idea.

If someone wants to establish a separate power system for a set of machines, and doesn't provide the room to manage the power connection as a trunk, like the rest of the factory, then they failed to plan.
Should a central switching station and it's related power poles be implemented, then *some* of those situations would be remedied, but far from all.
The root cause of the poor power network control would remain.
The current power systems, although not perfect, to be sure, are far more than adequate to be left as-is until just before 1.0 (or even after really, since they do everything you should expect power lines to do).

[ssilk]

Well, I can only offer a phrase used often in my career:
Piss poor planning leads to poor execution.
Trying to change the system to account for poor planning is a bad idea.

No it's fine. You forget, that it is a game and the best way, players can learn is by own experience. If they succeeds, fine. But if not they'll search for better solutions, and will hopefully find them here or in the wiki...
What never would work is: "you have to build it like so and so. Otherwise you'll fail!" The player asks: "and why do I have the freedom to make it wrong? And even if you tell it me, I want to make it different!" And maybe some find a better solution.

If someone wants to establish a separate power system for a set of machines, and doesn't provide the room to manage the power connection as a trunk, like the rest of the factory, then they failed to plan.

I never plan my factories. I built, what it's needed and try to improve that. If I would plan it, I would fail. And I tried it many times: when I begin to plan, then I fail. My best layouts where unplanned, my most fun I had with total quirked stuff, which surprisingly works.
Efficiency is one point, yes, but the other is, how quick you can built.
Ok. I have now more experience, and know what never works. For example: When I build that many stuff I need some new steam engines; but when playing, I don't plan much. It's most times much more efficient to have some first assemblies fast and then build it in big and destroy the old. Things that must be learned, - every player might have its own favorite style and when multiplayer works, we will see.

Should a central switching station

Pardon, nothing is said about central switching. I said, that for every pair of network, only one switch/transformer is allowed, just technical thoughts.

and it's related power poles be implemented, then *some* of those situations would be remedied, but far from all.
The root cause of the poor power network control would remain.
The current power systems, although not perfect, to be sure, are far more than adequate to be left as-is until just before 1.0 (or even after really, since they do everything you should expect power lines to do).

Well, that's true, if no switch is implemented. But if so, then everything needs to be changed, because I really don't found a way, how the requirements when introducing switches could be solved with the current way of building electric networks.

[n9103]

Pardon, nothing is said about central switching. I said, that for every pair of network, only one switch/transformer is allowed, just technical thoughts.
Well, that's true, if no switch is implemented. But if so, then everything needs to be changed, because I really don't found a way, how the requirements when introducing switches could be solved with the current way of building electric networks.

My intention was to propose a simpler, more practical overall solution, not counter a specific point you had.
Using some limiter like one per network seems very arbitrary. Using more than two (or just two that are very far apart) leads to management issues.

Implementing a remote-toggling system shouldn't be particularly complicated, as the control signal for a switch could easily piggyback/branch on/from the connection checking function used to establish that X is connected to power (or to Y and Z when it comes to the logistic net), checking instead to see which, if any control station is connected to the switch.
The hardest part would be allowing specific entities to be named by the player for labeling a number of toggles at the control station.

The only alteration to the current player-side building techniques would be replacing key poles with the toggling poles, and placing a control station in the trunk of the power supply. (When I say trunk, I always refer to the part of the power net which you'd never want to turn off. Typically that's your steam until mid-end game when solar becomes primary.)
It would be reasonable to assume that shutting off a pole should shut off control of poles past that point.
Having the poles have a minor power requirement should accomplish this without any extra checks.

If you're looking to limit something, making a limit of one control station per network would be fine, and that would then (as in after one's been placed) make electrical networks branch from control stations instead of power sources.
That last implication alone would let you create inter-weaving power networks if you so desired. (And that seems to be something several people want.)

[ssilk]

nothing is said about central switching. ... for every pair of network, only one switch/transformer is allowed... everything needs to be changed, because I really don't found a way, how the requirements ... could be solved with the current way of building

My intention was to propose a simpler, more practical overall solution, not counter a specific point you had.

But that's the subject: "handling of different electric networks" and not "simpler, more practical handling of an electric network and side networks". ... that's a very special theme.
I repeat: a network consists of poles and wires and mathematically it is a graph. Now I want to connect two graphs. That either by putting a wire between them or - if you want to have more control, you need to put something else in between. In my case a transformer, which is not more than a special pole. It is logical, that connecting two networks over more than one bridge doesn't make sense.

Using some limiter like one per network seems very arbitrary. Using more than two (or just two that are very far apart) leads to management issues.

No, there is nothing said about one per network!! Read exactly! I wrote one per coupled pair of network! That is just the minimal afford.

Implementing a remote-toggling system shouldn't be particularly complicated, as the control signal for a switch could easily piggyback/branch on/from the connection checking function used to establish that X is connected to power (or to Y and Z when it comes to the logistic net), checking instead to see which, if any control station is connected to the switch.
The hardest part would be allowing specific entities to be named by the player for labeling a number of toggles at the control station.
The only alteration to the current player-side building techniques would be replacing key poles with the toggling poles, and placing a control station in the trunk of the power supply. (When I say trunk, I always refer to the part of the power net which you'd never want to turn off. Typically that's your steam until mid-end game when solar becomes primary.)
It would be reasonable to assume that shutting off a pole should shut off control of poles past that point.
Having the poles have a minor power requirement should accomplish this without any extra checks.

Ok, I take that away as your suggestion, even if it is a bit confusing. I think you have something completely different in mind. If yes, I recommend to open another thread. I'll promise to read it.

If you're looking to limit something, making a limit of one control station per network would be fine, and that would then (as in after one's been placed) make electrical networks branch from control stations instead of power sources.
That last implication alone would let you create inter-weaving power networks if you so desired. (And that seems to be something several people want.)

Well. One control station per network sound like an idea, and I already suggested it, but if the network is 400 tiles in diameter it can take minutes to walk/drive to it. I would like to have the stuff happen, where 2 networks are pulled together, not miles away, that just logical consequence...

[n9103]

The way you phrased it before, sounded like you meant that a network could only be joined to one other network.
With that in mind, take a few breaths and re-read perhaps?

As for our ideas being different, I don't think they are, at the core. We're just taking different approaches to the same idea of managing a power network.
I'm aiming for centralized control points with remote management, and you're aiming for decentralized and almost no control.

You wanted the player to be able to control when/if a specific network got power from another, correct?
Mine allows the player to do that, with it being less pre-defined triggers (though that's still an option for the idea) and more absolute control on if a junction is passing power or not.
This allows the player to change the power networks priorities on the fly, far faster than modifying individual conditional statements, and far more intuitive to set up than multiple interacting condtionals.
These points are all severely compounded by your idea that would would likely have all these actions being separated physically, and likely taking place some distances apart.

To be honest, I can't see a great deal of merit in your idea that isn't provided for in my proposal, and also aren't in some sort of unique/rare use case.
If an idea has only one use case (if that) in an average game, it seems like it would be too unitask to deserve Dev time, since there are almost always other ways to accomplish almost anything in this game. (And there are almost always better things to be created than a unitasking item.)
For most of your ideas, when contrasted with my own, I couldn't come up with more than one use case, if any.

And remember, I'm not trolling here, so don't get so works up over it buddy

[ssilk]

The way you phrased it before, sounded like you meant that a network could only be joined to one other network.
With that in mind, take a few breaths and re-read perhaps?

Hm. Maybe translation problem? In German a "pair" means both: only two and some.

We're just taking different approaches to the same idea of managing a power network.
I'm aiming for centralized control points with remote management, and you're aiming for decentralized and almost no control.

It may look so. I try to think in development steps. And the first problem is to solve the (mathematical) problem of having heterogenous networks. I mean internally a factorio-network can be seen as a list of requesting and providing devices with different priorities. More or less like the logistic network, but with wires which immediately deliver, instead of robots, which take a while.

Now the problem is, that you have some of those networks and logically some of these lists. The question is then: what is delivered to which device when coupled? You cannot just convert the lists to one big list, because then you loose the control of what flows from one network to the other.

The same problem occurs in real electric networks! If you deliver power from one network to the other and from there to a third and then back to the first, the results can't be calculated, and so it is avoided. Which leads btw. to a significant loss of energy. Those calculations can't be made in real time.

This is the problem! And it's non trivial. And so I tried to find an easier way. And the easier way is to look at only two networks, instead of all. I mean, that makes the problem solvable. And the it could be adapted for 3, 4 and endless.

How it might be implemented? Two ways. In the transformer a list is handled: at any time the supply and the demanded energy of both networks and then the energy flows from one network to the other, depending on the demand. This means also - and I think this is a bit important - that the "transformer" is maybe about one tick behind the real demand and real supply. I mean we need a buffer to store the energy for one tick. The other way to do this is taking some average from the last seconds add some bufer to that and deliver that into the other network, which means, that we deliver always too much.

This two models are also like in reality: In reality this is handled so, that they deliver always too much and the overproduction is lost and in reality a real transformer also stores energy.

Till here all is easy, but what, if all networks demand energy, how should the lack be shared?
And I'm sure, there are some other problems...

You wanted the player to be able to control when/if a specific network got power from another, correct?

I mean that was one target. The other was to show, that with multiple networks the current handling of them must change completely. All in all this thread shows more and more, that coupling of networks is very much hard work, with unknown results.

Mine allows the player to do that, with it being less pre-defined triggers (though that's still an option for the idea) and more absolute control on if a junction is passing power or not.

I try to explain: I think, what we are talking about has never been programmed anywhere before and the best choice is in that case, to make it work and see, what is missing. And the best and easiest way to do that is to let the implementation shine through into the players/users interface to give him more control about it, as he obviously needs, because only then the players will find the best usage. And if that is known sometimes, the interface can be reimplemented as the players like.

This allows the player to change the power networks priorities on the fly, far faster than modifying individual conditional statements, and far more intuitive to set up than multiple interacting conditionals.

Yes. But the way to this target is just too long, due to the reasons I tried to explain.

These points are all severely compounded by your idea that would would likely have all these actions being separated physically, and likely taking place some distances apart.

Like in reality.

To be honest, I can't see a great deal of merit in your idea that isn't provided for in my proposal, and also aren't in some sort of unique/rare use case.

That's always like this with great ideas. no, seriously: it's a basic element, like the networks. I'm not sure, maybe I tell an urban legend, but when kovarex implemented the electric network, he might have no plans for logistic bots and that he could reuse some parts for them.

If an idea has only one use case (if that) in an average game, it seems like it would be too unitask to deserve Dev time, since there are almost always other ways to accomplish almost anything in this game. (And there are almost always better things to be created than a unitasking item.)

Oh, well, I'm sure, that coupling of networks is one big task, the devs want/need to solve. Think for example to electric networks, which lose energy over distance or pipes which have some resistance. This is a problem, because I think they currently can only simulate networks, with no resistance. If yes, it could be implemented, when having a control element, which couples two networks. (Visually you don't see that of course, but internally by placing a pole, there is automatically the transformer element inserted, which simulates a resistance.)
And I'm sure, there are much more of those things, which are then possible; or in other words: switches between networks are then only how it should work and how should it look.

For most of your ideas, when contrasted with my own, I couldn't come up with more than one use case, if any.

Because I see it from the developer aspect. I like to find the edges of software. The things which improve it by 10% but make 90% of work.

And remember, I'm not trolling here, so don't get so works up over it buddy

Was only upset, because I fell, that there is some big misunderstanding.