Merge beacons (and drain power?) for electricity calculation

[Vegemeister]

So I was experimenting with various UPS optimizations for a steel smelter, and I noticed that, under output-blocked conditions, removing all but one beacon from the layout (there are 1026) reduced the electic network computation time (as measured by the show-time-usage debug info) from 30 to 19 us.

But beacons don't have load and idle power. Every beacon connected to the same electric network draws the same 480 kW all the time (or less during brownout, but still the same for every beacon). The only thing that changes the power used by beacons is placing or removing beacons. So it should be possible to merge beacons together for the electric power simulation, the same way solar panels and accumulators work already. And many factories contain thousands of beacons.

Furthermore, I think this could be extended to every entity that has a constant power drain. Keep a variable for the total drain power in each electric network. Update it whenever entities are added or removed from the network. Slightly reduce the load power of everything to keep the overall energy usage the same. Now, you have O(1) electric calculations for all idle entities (laser turrets, inserters loading ammo for gun turrets, furnaces...).

[bobingabout]

There is one other factor for determining beacon power usage. (or at least used to be the case, I've not checked recently)
If you haven't put any modules in it, or there aren't any structures within it's field (doesn't matter if they're running or not, they just have to be in the field) that make use of the bonuses, then the beacon will draw no power, and be turned off.

[Lubricus]

Beacon could have a constant electricity drain. I don't think that would be bad for the game-play.

[bobingabout]

It probably is for the best to just have it permanantly on, then treat them as a single entity on the grid with a multiplier.... like they did with solar panels, etc.

[TheOnefinn]

That does significantly increase the cost for building beacon blueprints before you have the modules available to fill them, you will immediately have to pay the energy cost for everything rather than only for the beacons that have been filled with modules

[pleegwat]

Making it dependent on module insertion should be straightforward enough since that'd trigger a power consumption change in the beacon when it's being modified anyway. Automatic turning on/off based on nearby assemblers would be more difficult.

[Vegemeister]

There is one other factor for determining beacon power usage. (or at least used to be the case, I've not checked recently)
If you haven't put any modules in it, or there aren't any structures within it's field (doesn't matter if they're running or not, they just have to be in the field) that make use of the bonuses, then the beacon will draw no power, and be turned off.

It seems that is no longer the case. Beacons with nothing in range and no modules installed animate and use power. I don't know when that changed. If they wanted to make them turn off when not providing a bonus, that would be an uncommon, transient condition, and they should optimize for the steady state. My second suggestion could actually do that, if they made the idle power 480 kW and the active power -480 kW, and considered beacons that actually apply effects to be "idle", and beacons that are waiting for modules to be "active".

Beacon could have a constant electricity drain. I don't think that would be bad for the game-play.

Argh, I was unclear. In the second suggestion, when I say, "constant power drain", I mean things like inserters that say, "Energy consumption: 46.2 kW, Drain: 500 W". The idea is to make electricity calculations for idle entities with drain O(1).

That does significantly increase the cost for building beacon blueprints before you have the modules available to fill them, you will immediately have to pay the energy cost for everything rather than only for the beacons that have been filled with modules

Beacons already use power no matter what. But your concern is fairly simple to solve. Connect the output inserter of your beacon assembler to the logistic network, and enable it when speed module 3 > 0. There'll be discrepancies due to inserter stack bonuses and robot job assignment, but it will limit beacons waiting for modules to a fairly small number.