Factorio Forums

ssilk wrote: Sun Sep 13, 2020 11:23 pm Game does not distinct players reasons but distincts if an open switch has power on one side or not.

Between power producer and consumer can be several turned off switches. And consumer still turned off by player command, not by power network disfunction.

The only real reason to shut off power with a power switch (vs turning off input belts/inserters) is beacons - which consume gobs of power, even when no machines in their area are active. Rather than mucking about with power, reconnection computations, & etc. why not just fix the idle beacon problem? I see two potential options (though there may be more, of course):
- Give beacons an "enable" circuit condition so they can be turned off en mass.
- Make beacons auto power-down when there are no machines actively crafting in their radius.

Personally, I'd go with the "enable" circuit condition...

evandy wrote: Tue Sep 15, 2020 2:03 am The only real reason to shut off power with a power switch (vs turning off input belts/inserters) is beacons - which consume gobs of power, even when no machines in their area are active. Rather than mucking about with power, reconnection computations, & etc. why not just fix the idle beacon problem? I see two potential options (though there may be more, of course):
- Give beacons an "enable" circuit condition so they can be turned off en mass.
- Make beacons auto power-down when there are no machines actively crafting in their radius.

Personally, I'd go with the "enable" circuit condition...

The power usage depends pretty much on the scale of your base.

Even idle machines can consume power in megawatt range if there is enough of them. If all my smelters were to go idle right now, just between them and the inserters it's about 32MW of power used when idling.

I don't really think the beacons are broken, they transmit the effect even when machines around them are idle. That tech is expensive power-wise, so i only use it when i have to. Though if you were to use a switch, you could just turn them off ... :)

You could always start a thread about the beacons in the suggestions sub and see if the devs are willing, some of them might find your message here but they might not.

Sad_Brother wrote: Mon Sep 14, 2020 4:50 pm

ssilk wrote: Sun Sep 13, 2020 11:23 pm Game does not distinct players reasons but distincts if an open switch has power on one side or not.

Between power producer and consumer can be several turned off switches. And consumer still turned off by player command, not by power network disfunction.

Well, it took a while for me to understand it. I try to explain it more detailed.

Situation:
There is no power in a network.

Target:
Game needs to decide, if it should display a big blinking warning or small warning (small red light or so).

Algorithm:
- are there any power producers in my network?
- yes, but no switches -> big warning
- find all power switches in this network
- for each switch look, if the switch is closed.
- If all would be open -> big warning
- for each closed switch look if the other side (the “outside”) is a powered network (are there any producers?)
- if yes -> small warning.
- any other case -> big warning.

There is no need to recursively look, if other switches to third party networks are opened or closed, because if other switches are open, both networks are “merged”, which means if there are any power producers they should be found, even if they are connected over a dozen open switches -> Small warning. And if closed that means that the player needs to open those switches first. No producer in that network -> Big warning.

If you see that so, line 1 and 2 of the above “algorithm” is not needed. I wrote that just for simpler understanding. Implementation needs to look only for closed switches in current network, everything else is already working as expected.

Extra points: the game could look not only for producers, but if there is also available energy left. If nothing is left: big warning.

ssilk wrote: Tue Sep 15, 2020 7:28 am Algorithm:
- are there any power producers in my network?
- yes, but no switches -> big warning
- find all power switches in this network
- for each switch look, if the switch is closed.
- If all would be open -> big warning
- for each closed switch look if the other side (the “outside”) is a powered network (are there any producers?)
- if yes -> small warning.
- any other case -> big warning.

I think you have switched (pardon the pun) 'open' and 'closed'. (You close a switch to let current flow, and open it to break the flow.)

No.

If a switch is open, both networks belong together. A no-brainer: If there is then no power -> Big warning.

The interesting case is the close position: Would this network have power if I open it? If yes -> Small warning.

Shameless self-advertisement with this suggestion, that could help also address this issue :
viewtopic.php?p=506556#p506556
If I could control the entities via circuitery, the issue would solve itself without additional work (and without unpowering them).

Koub wrote: Tue Sep 15, 2020 4:01 pm Shameless self-advertisement with this suggestion, that could help also address this issue :
viewtopic.php?p=506556#p506556
If I could control the entities via circuitery, the issue would solve itself without additional work (and without unpowering them).

Yeah :)

I can see use for that in stepping up production of items in smaller increments to make JIT simpler while having extra production capacity as a backup.

That'd make the regular switch kind of obsolete i think, other than megabase UPS optimization, entity that is unpowered likely takes less CPU cycles to deal with than one that is turned off via in game logic. There are valid usage scenarios for either, i'll take them both :)

And while we at it, i'd love if some of the statistics were accessible in-game via logic circuits, something like data request combinator where i could pick a stat from a list. For example local network power usage, production statistics (guess you can get those reading belts), kill stats (for automated JIT ammo deliveries), things like that :)

ssilk wrote: Tue Sep 15, 2020 7:28 am

Sad_Brother wrote: Mon Sep 14, 2020 4:50 pm Between power producer and consumer can be several turned off switches. And consumer still turned off by player command, not by power network disfunction.

Well, it took a while for me to understand it. I try to explain it more detailed.

Thanks for your efforts. My native language is not latin based, and so my phrase design. Sorry.

ssilk wrote: Tue Sep 15, 2020 7:28 am Situation:
There is no power in a network.

Target:
Game needs to decide, if it should display a big blinking warning or small warning (small red light or so).

My algorithm:
All, the game need to detect, is "would be device have power if all switches are on?".
Let me rephrase myself.
1.Is any active energy producer in device's network? yes - no warning (powered);
2.Is any active energy producer in all network, connected by switches(in any state)? yes - small warning (turned off);
3.No power in whole network - flash the whole network by exclamation.

I think this algorithm is better. But it depends of implementation of course.

I prefer On and Off as in game. Open and Closed are misleading for me.

Koub wrote: Tue Sep 15, 2020 4:01 pm Shameless self-advertisement with this suggestion, that could help also address this issue :
viewtopic.php?p=506556#p506556
If I could control the entities via circuitery, the issue would solve itself without additional work (and without unpowering them).

Would not solve itself.
Do you want to remove switch from game?
Do you want to force players to use logic cables everywhere they want to control power?

DingoPD wrote: Tue Sep 15, 2020 4:24 pm That'd make the regular switch kind of obsolete i think, other than megabase UPS optimization, entity that is unpowered likely takes less CPU cycles to deal with than one that is turned off via in game logic. There are valid usage scenarios for either, i'll take them both

Actually unpowered entities (whether by absence of power poles or opened power switch) use more CPU power than those gone asleep (because output backed up or input starved). At least it worked that way not so long ago. If I'm not mistaken, the devs explained that in case of lack of power, the entity never really goes to sleep, which is less efficient than sleeping entity waiting to be awaken.

Sad_Brother wrote: Tue Sep 15, 2020 4:33 pm Would not solve itself.
Do you want to remove switch from game?
Do you want to force players to use logic cables everywhere they want to control power?

I'm not specifically after the power switch's skin. However, the existence of the power switch that has some uses should not prevent us (or the devs) from trying to imagine a better solution, even if the said solution eventually makes the power switch obsolete. There have been some such changes in Factorio's history. Example :
- Before 0.13, the basic chests couldn't be connected to the circuit network. One needed a smart chest (built from a steel chest) or a logistic chest (built from the smart chest) to be read by circuitery. Then with 0.13, smart chest was removed, and all the chests became circuit readable.
- With 0.13 again, all inserters became circuit connectable (before that, up to fast inserters were not). The smart inserter was removed, because it became redundant (or was transformed into filter inserter).

I'm sure there are other examples, but you get the idea.

Koub wrote: Tue Sep 15, 2020 7:27 pmActually unpowered entities (whether by absence of power poles or opened power switch) use more CPU power than those gone asleep (because output backed up or input starved). At least it worked that way not so long ago. If I'm not mistaken, the devs explained that in case of lack of power, the entity never really goes to sleep, which is less efficient than sleeping entity waiting to be awaken.

I remember reading patch notes about them fixing this. I think it was somewhere in the 0.17 series.

Theikkru wrote: Tue Sep 15, 2020 7:55 pm

Koub wrote: Tue Sep 15, 2020 7:27 pmActually unpowered entities (whether by absence of power poles or opened power switch) use more CPU power than those gone asleep (because output backed up or input starved). At least it worked that way not so long ago. If I'm not mistaken, the devs explained that in case of lack of power, the entity never really goes to sleep, which is less efficient than sleeping entity waiting to be awaken.

I remember reading patch notes about them fixing this. I think it was somewhere in the 0.17 series.

I reckon we're getting slightly off topic, but I'd be very interested by the source (couldn't find it).

Koub wrote: Tue Sep 15, 2020 8:19 pm I reckon we're getting slightly off topic, but I'd be very interested by the source (couldn't find it).

Problem is I can't remember where I read it. Yesterday I was also failing to find the patch notes where they made underground pipes have the same flow as regular pipes. If only the forum search function weren't so garbage...

Sad_Brother wrote: Tue Sep 15, 2020 4:33 pm My algorithm:
All, the game need to detect, is "would be device have power if all switches are on?".
Let me rephrase myself.
1.Is any active energy producer in device's network? yes - no warning (powered);
2.Is any active energy producer in all network, connected by switches(in any state)? yes - small warning (turned off);
3.No power in whole network - flash the whole network by exclamation.

I think this algorithm is better. But it depends of implementation of course.

Yes, both simpler and better. If a power consumer is separated from the nearest source by two or more layers of switch, all deliberately off, you don't want a big warning about the absence of power any more than if the separation is only by one switch.

Sad_Brother wrote: Tue Sep 15, 2020 4:33 pm I prefer On and Off as in game. Open and Closed are misleading for me.

And apparently for ssilk. Since my earlier attempt at clarification failed, I'll try once more. An electrical switch is on when it is closed and off when it is open. (It does not control the flow of current the way a valve controls the flow of fluid.)

@koub: your suggestion would make many things easier. I don’t know if I like that.

To be honest: I would like it. Somehow. But I think the switch makes a lot of sense.

The switch was introduced to separate power producers when you have solar or more kinds of energy production. This mini game “use solar/accu, even at night. Steam engines should turn off then“.

This very simple usage (just add a switch, connect with accumulator and ready) cannot be beaten by your suggestion. And this shows also to the weak point in that suggestion: you need to connect every device “by hand” with red or green wire. I can think of tools, that can make this simpler, but the wire clutter keeps.

So I think this is interesting and it looks like a solution, and at the same time it is not handy.

Sad_Brother wrote: Tue Sep 15, 2020 4:33 pm

ssilk wrote: Tue Sep 15, 2020 7:28 am

Sad_Brother wrote: Mon Sep 14, 2020 4:50 pm Between power producer and consumer can be several turned off switches. And consumer still turned off by player command, not by power network disfunction.

Well, it took a while for me to understand it. I try to explain it more detailed.

Thanks for your efforts. My native language is not latin based, and so my phrase design. Sorry.

ssilk wrote: Tue Sep 15, 2020 7:28 am Situation:
There is no power in a network.

Target:
Game needs to decide, if it should display a big blinking warning or small warning (small red light or so).

My algorithm:
All, the game need to detect, is "would be device have power if all switches are on?".
Let me rephrase myself.
1.Is any active energy producer in device's network? yes - no warning (powered);
2.Is any active energy producer in all network, connected by switches(in any state)? yes - small warning (turned off);
3.No power in whole network - flash the whole network by exclamation.

I think this algorithm is better. But it depends of implementation of course.

I prefer On and Off as in game. Open and Closed are misleading for me.

Ok. Let’s try again.

If you have several switches and all are on (I used “open“, which is indeed irritating) then the game behaves like that there is just one big network. All sub networks are joined together. All producers and consumers are like that they are in one big pair of lists.

This case is not interesting for the decision if there should be small or big warning, because the game can behave as it behaves yet.

The things gets interesting, if there is are switches turned off (I called them closed). Now when you keep in mind, that united networks behave like one big network, and you don’t find any producers in it, you need to look at the off-switches and look, if there is any producer on the “other side”.

It doesn’t matter, if there are more switches on the other side: if the switches are on, then the networks (and with them the producers) are united and you will see the producers. So the rule from above keeps the same: if there are producers at the outside of the switch -> small warning. If there are still no producers it makes no sense to show a small warning: there are two switches that block that there is power in the current network -> big warning.

This avoids also if you have made strange circles in your network, and to look over all networks recursively, which are all potential performance holes. And it is really simple to implement.

ssilk wrote: Wed Sep 16, 2020 5:21 am The things gets interesting, if there is are switches turned off (I called them closed). Now when you keep in mind, that united networks behave like one big network, and you don’t find any producers in it, you need to look at the off-switches and look, if there is any producer on the “other side”.

It doesn’t matter, if there are more switches on the other side: if the switches are on, then the networks (and with them the producers) are united and you will see the producers. So the rule from above keeps the same: if there are producers at the outside of the switch -> small warning. If there are still no producers it makes no sense to show a small warning: there are two switches that block that there is power in the current network -> big warning.

Say I have three networks, connected by two switches: a high-priority network containing all the power sources and those consumers that should never be switched off is connected by switch #1 to a medium-priority network that can occasionally be switched off, which is in turn connected by switch #2 to a low-priority network that is often switched off.

If #1 is on and #2 is off, so that the low-priority users are powered down, the game currently flashes an annoying warning. Under both ssilk's algorithm and Sad_Brother's this flashing would be prevented.

If #1 is now also turned off, the game currently flashes over both powered-down areas; Sad_Brother's algorithm would prevent both; ssilk's algorithm would now prevent the medium-priority network flashing, but start the low-priority area flashing. Why would I want to be warned about the low-priority area lacking power, when I have explicitly turned off both switches?

A strong warning is wanted only if there would be no power even with all switches on.

Sorry about the wall of text, again :)

I've been following you guys convo for couple of days now, i think i get it now. Sometimes it ain't easy when everyone involved uses a secondary language to communicate. :)

If i understood it right, it's about nested switches, specifically if nested switches should be detected and what to do about them.

For example, a manual main power switch to just kill the whole sub grid, and then several automated ones for turning off segments of the same grid when needed - i use this a lot for remote outposts where power is limited and i want all available power for defense when I'm not there. So i wire defense directly to power source and then everything else behind a switch.

I think that nesting should be detected and still show small indicator instead of no_power_warning icons.

The trick comes with handling it without causing a performance hit. Recursion would be the immediate easy way to deal with it, but that can be quite wasteful on CPU cycles, especially if it runs every tick. I'm still trying to figure out a good way of doing it.

The best i come up with so far, would be to set a 'parent' on the switch, then on tick updates check if the parent has power, if yes, display small indicator, if not, display no_power_warning. So recursion to find a parent runs only the first time and then when the parent network changes.

In scenario like this: I think that Network B could be set as a parent for Switch 2. Then, instead of doing full recursion on every update, just checking the parent for power will give the answer i seek.

But what happens if the connection between Power 2 and Network B is severed, and Switch 1 is off ?

Connection is severed, Network B would is flagged as modified.
On Switch 2 update, modified parent status is noted, recursion runs to find new parent for Switch 2.
Network A becomes parent for Switch 2.

I guess what i'm trying to say is: When doing it this way, intermediate switches can be ignored, because turning them on or off will not change the status between small indicator and no_power warning.

This way everything can be done in small segments when the events are raised, without big recursions, and in order the events come in.

I hope i'm making sense to you guys.

EDIT: Forgot to mention, if you want to visually differentiate that there are open nested switches present, just count the number of switches when finding a parent and change the color of small indicator or make it flash once in a while, if nested.

Khagan wrote: Wed Sep 16, 2020 6:09 am ssilk's algorithm would now prevent the medium-priority network flashing, but start the low-priority area flashing. Why would I want to be warned about the low-priority area lacking power, when I have explicitly turned off both switches?

A strong warning is wanted only if there would be no power even with all switches on.

This depends on standpoint. The game cannot know if you accidentally forgot to open the switch. And you as player can avoid that warning, if you turn #2 on in that case.

Other example, with similar network layout.

But in the “middle” network you placed now solar panels.

Now it’s night, all accumulator power has gone. But you closed #1 (where your nuclear power is) due to some wrong programming. Or a biter has eaten the combinator that decides switching. Now it would be correct to show big warning in the network behind switch #2.

Right?

ssilk wrote: Thu Sep 17, 2020 7:00 am The game cannot know if you accidentally forgot to open the switch.

No it can't. Not now, not ever, never. But that applies just as much to a single switch as to a chain of two or more. Right now the game treats all 'off' switches as errors, which is silly; the only other consistent and practicable behaviour is to treat them all as intended.

ssilk wrote: Thu Sep 17, 2020 7:00 am But you closed #1 (where your nuclear power is) due to some wrong programming. Or a biter has eaten the combinator that decides switching. Now it would be correct to show big warning in the network behind switch #2.

These are both switching errors, so (as I agreed with you just above) the game cannot know that they are errors. The big warning should be for hard-wired electric network faults, which the game can identify. And if a biter has eaten your homework combinator, it will presumably eat the switch shortly afterwards, at which point we do have a network fault! (More seriously, there is already a big warning for destroyed objects anyway.)

Khagan wrote: Thu Sep 17, 2020 7:28 am[...]And if a biter has eaten your homework[...]

Someone has to use Factorio in a Computer Science class and make this happen. Don't let your memes just be dreams.