All the different ways to increase the efficiency of a nuclear power plant

[mmmPI]

Well, the previous comments about timing where about setting a delay. I read it as you set one in e.g. a constant combinator and then you get a fuel cell every 362s or whatever value you set.

yes this still hold true, reading a % of max troughput on the power graph is the same as reading the % of timer you need to add except inverted ( 1/x).
If you put timer at 362 sec for a 480MW plant that would max out with timer of 200s, this means you plan for 265 MW. (1/[362/200])x480.

362 /200= 1.81 , that would make 2 for timer of 400 sec, this means when you use 1/2 power, timer are x2 make sense intuitively right ?, then you get 1/1.81, this is 0.55245... this is the ratio compared to max power 55.25%. If you do 0.55245x480 MW, you get the 265MW.

Really in the game though you do it the other way around when using the clock thing. You red you energy consumption as say an average of 120MW after an hour. This means it was 120/480= 0.25 times the max. or 25% capacity. 1/4=120/480. So then you take (1/X), wich is 4. and multiply by the 200 base fuel, for 800 timer.

You picture a blackbox that start with unknown quantity or energy after you initialized it, you measure what leaves it during 1 initial cycle of arbitrary amount of time, then next arbitrary amount of time you refill exactly as much while also measuring the consumption of that 2nd interval. At the end of 2nd interval, you "set timer" based on consmption during the 1st interval.

That's something you CAN do, you can also don't check every interval because you could know the consumption, if it's your base and everything is stopped, or if you just take 12 stack of blue belt in the mall you may have an easy way to predict the future consumption, as long as you do so you don't even need to worry about changing the timer.
Or if it's an ON/OFF power plant that activate in time of emergency when your solar need to be extended for example.

But really you don't want to measure consumption. At best it's a prediction of the future from past events. Maybe the next second aliens will attack and power consumption with increase 10 fold. You can't know.

you don't have to measure you just have to click a power power .

How does automated power plant react during the 2nd alien wave ? just feed max fuel.
How should you set timer if uncommonly big 2nd wave occur ? just set them to minimum.

You can't know what WILL happen, but neither can an automated plant, you can always humanly react the same way as the automatic plant would react when you see the wave or plan on making more land available for your factory haha. Think about it, you can even have a little lamp indicator that turns red when timer are minimum, to set the mood for when you make a new artillery outpost.

It's not prediction of the future, only reaction to present. The reactivity from an automated power plant comes partly from the fact that production increase immediatly, that's due to the inherent nature of the steam turbine & heat exhanger function. This also goes true for a clocked design, you start consuming your buffer faster immediatly, you handle the early phase of the spike. Then automated react by changing timer for the current cycle making it shorter when noticing no energy is left in the buffer. You can quickly have a look on map view if the pipe are still glowing strong or not. see the temperature of the system, if it can absorb the spike when you see it or not.

Again this stress out the importance of buffer for those design, if you store 20 cycle of fuel, you can decide wether to refuel faster or not due to the unusual spike much later than if you were to only store 1 cycle or 2.

With this kind of design you don't refill when the buffer is empty by default, so you don't run the same risk of black out caused by a spike happening like 30 sec before the planned refuel. automated power plant ,adapt by skipping those 30 second of waiting time because it measure the buffer empty or closed to be. With a clock design instead the average temperature of the system is lowered a bit but it doesn't necessarily cause shortage as it would have with the other.

Again that's completly unecessary if you use the power plant for rocket launching or science or their mining outposts, since the consumption in those case would average easily despite the periodic spike and valley.

I'm just saying it functions if you do it properly, not that it's what everyone should do, this is "all the different ways to increase efficiency", you can call it the manually-controlled power plant that still could be an efficient power plant. Wether or not YOU want to measure consumption is your own personnal liking

You can measure the throughput of the steam with some clever tank and pump tricks. That is the only practical way to actually measure how much energy you consume anywhere realtime.

That' still a 1 cycle delay somewhat . What you are measuring when you measure steamflow is how fast your buffered energy is consumed. Wether the buffered energy is under the form of heat/steam/already-inserted-fuel-cell doesn't matter. Then when all/most of it is consumed, the refuel happens. You measure "actual" consumption but it is only updated when the energy is all gone, after 1 cycle of measuring/consumption on the previous fuel.

So the better use of the measurement is to determine when it is safe to put in another fuel cell. Only use the measure of how much additional energy you can buffer right now. If that is less than 1 fuel cell generates then throw in one fuel cell. Most of the designs shown so far use that method. If you predict power usage you can potentially insert fuel cells earlier (or later) and use fewer steam tanks or accumulators. But if you guess wrong you either waste fuel or have a brownout. And steam tanks are cheap and you only need like 2 tanks to be on the safe side.

that's the same thing as measuring the amount of water in the glass or the amount of non-water

In order to know if it's safe to insert a new fuel cell you need to know how much energy you can buffer, which is the same amount as the amount of energy you have consumed since the previous refuel.

But you are correct saying a wrong prediction can lead to brown-out or black out, that's if when refilling the amount of energy lost in previous cycle you run out of buffer, like running out of memory to write the debt of energy from one cycle to another. In practice though you just need a few accumulator ringing and alarm when not 100%. They would make you notice if the timer need to be reduced if you don't check it as accuratly as the manual recommend. Depending on how you implement your clock the inserter could be instant inserting fuel when you reduce time to a smaller duration than the one already passed since previous refuel, that's something i'll consider

Well, if you really do want to buffer 20 cycles of fuel.... Normal design shown so far buffer 1-2 cycles only. Mine (1 tank per reactor) doesn't even buffer 1 cycle because I assume a base load on the reactor that consumes the rest.

And there you go again saying "if you put the timer to 400 sec". Me? I don't want to put anything. The reactor should run itself. Or do you mean have some combinator construct that calculates the time to 400 sec? Please be precise.

I try to make sure what i want is my concern hehe, i'm saying you CAN buffer 20 cycle of fuel . Your idea of assuming a base load on a reactor to spare some buffer is something i understand that's assuming a certain set of conditions which then lead to design neglecting some factors.

my reflexion is just saying that you could designs mechanism to be efficient with others sets of conditions making them very viable where they would be bad with some others set of conditions.

you could use anymeans to change the timers :

Time and manual human intervention, where you hard code the number of tick for refuel everytime.

Time and manual human intervention, where you slide a slider on a combinator that is just the % of max energy you used last hour because you can buffer more than 20 fuel cycle and you made a contraption that auto-calculate the timer from the value you set in the slider.

You could also imagine reading that some science is going on a belt as the condition to trigger an ON/OFF power plant with preset timer of 362 second that only powers some beacons to speed up science when some of it is already running on the belt.

Note: If you have 20 cycles buffer then you can just throw in a fuel cell whenever the buffer is below 15 cycles. At most 5 fuel cells get inserted so even if consumption stops the most you reach is full buffers. No need to measure times and estimate consumption. Just set the inserters to "steam < 15 cycles". No combinators needed, which safes energy and therefore is more efficient.

The thing though is that using heat pipes you can't read precisely the amount of buffer you infer it due to consolidated previous value. which could require correction once in a while, setting the timer lower than usually to lower the buffer during a cycle or higher than usually to refill the buffer.

what you describe is how classic power plant would function if designed with gigantic buffer to make up for the quantity inserted when using max stack size, using heat pipes only without measuring steam is a "different way to increase the efficiency of a nuclear power plant". The combinators is you ! You push the buttons ! ( not in the case of on/off plant that powers beacon only functionning when science is running, then no button )

You are forgetting that inserters drain energy while idle. If you have 1000 reactors or 2000 reactors the power per swing basically doubles. The cost of the swing doubles. But at the 480MW consumption rate the time between refuels basically doubles. So that balances out. The tiny bit more is near 0. It's there but near 0. The time of the swing compared to time between swings is, well, rounding error . So you have double the number of inserters and twice the time they are idle. That means the inserters consume 4 times as much power per cycle.

It's easier if you do the math with a fixed fuel cells per second value. Then 2x2N reactor will swing half as often as a 2xN reactor. Keeps the numbers simpler. Don't compare cycles as the fuel input per cycle isn't constant. Twice the number of inserters means double the power drain if you ignore the swing. The problem is that "a tiny bit more than doubled" has to make up for the double power drain of the inserters. That works going from 4 to 8 reactors. I don't know where it stops working but I suspect 1000 to 2000 won't make up the increased drain.

Earlier someone suggested using burner inserter and showed the math how much energy the inserters consume and how much burner inserter would safe. So my suggestion would be to scroll back to that and use that math.

Note: If you use burner inserter then there is no drain, only the swing. All the above is for electrical inserters. With burner inserters the bigger the better unless you have a combinator per reactor or other drain.

I was forgetting the drain, i admit. but look i think that's the post you mentionned :

Because of you I was playing around with trying to use 3 burner inserter, one for fuel injection one for fuel ejection, and another one to fuel the 2nd. If you put nuclear fuel, because that's what is done in nuke plant, you have 1210000kJ/70kJ=17285.7143 swing per nuclear fuel. Counting for fuel ejection and fuel injection every 200 second, that means 1 nuclear fuel would last 3457142.86 second in those 2, ( around 40 days ).

Which means the burner inserter that refuel the ejection inserter will do a swing every 40 days, which means it will need to confiscate one fuel to refuel itself every:

17 285.7143 x 3 457 142.86= 59 759 183 772.245 sec, 5.9E10 sec, that's 691 657 days, or 1894 years.

Is it bad that I feel no guilt?

If you keep your power consumption in a 1GW range you can have just one steerable 1GW reactor, everything else always-on. Gut check says very, very few bases have to worry about long-term power cycling in excess of 1GW, am I just too pedestrian here?

That means for almost all your power generation you can use stacked load/unload, one loading swing every 600s, with a loading inserter wired read-hold to the power switch on the unload circuit. Use fast inserters for unload, they can take 3 spent cells in the half-swing the power switch is closed, and you get ten minutes per swing, basically zero power consumption for the unload, 17285 swings is 120 *days* per fuel cell. One in the tank, one in the buffer, that's 240 days. Or I suppose it would be even cheaper to use just one burner for one reactor's reload, and use fast-inserters-powered-for-46-ticks-every-ten-minutes for all the rest.

At that point, you might as well just not bother with a refueling supply, your solstice festival can include a reactor-service-inserter-refueling celebratory ritual with lots of pomp and circumstance, maybe even an inserter dance!

With those ideas you don't have drains. Since the only inserter that stay awake for logic is a burner inserter who has no drain. The ejecting inserter is only consuming energy for a fix amount of ticks the strict minium which is then constant, and not doubling over time as drain. "Rounding errors" you said, but if we were to be super precise, even those little ticks wouldn't count.

if you take 1 reactor and 1 inserter. The ratio [cost of inserting the fuel/energy worth of 1 swing] is biggest.
if you take 2 reactor and 2 inserter. The [cost of inserting the fuel] has doubled, [the energy worth of 1 swing] a bit more than doubled.
if you take 4 reactor and 4 inserter. The [cost of inserting the fuel] has doubled, [the energy worth of 1 swing] a tiny bit more than doubled.

This means If you remove drain from the equation it holds true no ?

Also this is another consideration, this is also about the inner solar grid to try and immunize the inserters and their logic from power shortages.

If we consider the most efficient power plant, it would be a solar field, with a little nuke power plant somewhere haha. but staying at the scale at which we wouldn't consider it a solar plant, when the solar pannel is embedded in a tilable design for example, the implementations details becomes what could makes the difference between an optimal existing or the biggest the best.

using only burner inserter is similar to using solar as you rely on energy from outside the nuclear plant to remove the energy cost of some part of the process.

as you said i agree combinators act like drain.

[xaetral]

i understand that you remove the 1GJ of potential energy storage under the form of steam stored in turbines or heat exchanger and pipes to the 39 GJ of your total energy storage capacity. This makes it 38GJ you can store under the form of heat, temperature rising after the steam is backed up.
Out of this 38GJ storage capacity you will use 32GJ, or 80%, so you calculate the temperature will rise to 80% of what it can reach. Since the range of temperature used to calculate the 38GJ is from 500° to 1000°, it gives 400° if we take 80% of that range away you're left with 100°.

at this point tough i'm not sure how/why you conclude that the 100° left are the difference between the coldest and hottest point.

I would say your math meant that 100° is what you have left on average on each heat storing component before it reaches the upper bound of the range which is 1000°. Meaning that your system will be around 900° on average after it absord a full fuel cycle while not producing anypower starting from a situation where it was at 500° on average.

When you say "coldest and hottest point" you mean over time right ? not at a particular moment the "coldest and hottest point of the system" right ?

No I count 31/38, not 32/38.
The point is to get how much the heat capacity I have to spare (because the steam capacity won't lower till the heat capacity is reduced to zero).
The thing is, there's a difference between your reactor temperature (what I called the hottest point) and your coldest heat exchanger (the furthest from the reactor) and I wanted to compute how much temperature difference I use vs how much is left for that hot/cold temperature difference (again, it's a spatial hot/cold, not a time hot/cold).
So since I only use 80% of the heat capacity, that means both the (spatial) hot and cold points will (time-wise) heat up / cool down with a 400°C vairation (80% of the 500°C working range), which leaves 100°C for the temperature difference between the (spatial) hottest and coldest points.
For example you can have your reactor going 600~1000°C and your coldest heat exchanger 500~900°C

Hope it's a bit clearer now.

edit: also note that that 100°C difference is a maximum, we could have a 400°C time variation with a 50°C spatial variation: for example if the reactor goes 550~950°C and the coldest heat exchanger 500~900°C, that would leave 50°C of unused heat capacity, which is fine.

[mrvn]

Well, the previous comments about timing where about setting a delay. I read it as you set one in e.g. a constant combinator and then you get a fuel cell every 362s or whatever value you set.

yes this still hold true, reading a % of max troughput on the power graph is the same as reading the % of timer you need to add except inverted ( 1/x).
If you put timer at 362 sec for a 480MW plant that would max out with timer of 200s, this means you plan for 265 MW. (1/[362/200])x480.

And that is really not what you want to do in a game unless you finished playing and just want to let it run static for the hell of it.

In a real game things change, power consumption changes. If you have to go back every hour and adjust the constant combinator to new power needs then that is crap. That's my point. Automate.

But really you don't want to measure consumption. At best it's a prediction of the future from past events. Maybe the next second aliens will attack and power consumption with increase 10 fold. You can't know.

you don't have to measure you just have to click a power power .

How does automated power plant react during the 2nd alien wave ? just feed max fuel.
How should you set timer if uncommonly big 2nd wave occur ? just set them to minimum.

You can't know what WILL happen, but neither can an automated plant, you can always humanly react the same way as the automatic plant would react when you see the wave or plan on making more land available for your factory haha. Think about it, you can even have a little lamp indicator that turns red when timer are minimum, to set the mood for when you make a new artillery outpost.

It's not prediction of the future, only reaction to present. The reactivity from an automated power plant comes partly from the fact that production increase immediatly, that's due to the inherent nature of the steam turbine & heat exhanger function. This also goes true for a clocked design, you start consuming your buffer faster immediatly, you handle the early phase of the spike. Then automated react by changing timer for the current cycle making it shorter when noticing no energy is left in the buffer. You can quickly have a look on map view if the pipe are still glowing strong or not. see the temperature of the system, if it can absorb the spike when you see it or not.

Again this stress out the importance of buffer for those design, if you store 20 cycle of fuel, you can decide wether to refuel faster or not due to the unusual spike much later than if you were to only store 1 cycle or 2.

If you set the timer based on current consumption then that is a prediction that future consumption will be the same as now. If your prediction is perfect you wouldn't need any buffer at all. But because future consumption differs from current consumption you need the buffer to make up the difference eigther way.

That you feel you need 20 cycles worth of buffer just tells me how bad your prediction is and how slow your reaction to that fact.

As said just set the inserter to throw in fuel cells when the buffer is below 15. It will never overflow and only empty if you consume more than max power, in which case nothing can be done.

With this kind of design you don't refill when the buffer is empty by default, so you don't run the same risk of black out caused by a spike happening like 30 sec before the planned refuel. automated power plant ,adapt by skipping those 30 second of waiting time because it measure the buffer empty or closed to be. With a clock design instead the average temperature of the system is lowered a bit but it doesn't necessarily cause shortage as it would have with the other.

Huh? I think you have that backward. If you refuel by time and suddenly consumption goes way up then your buffer gets drained. If you don't refuel earlier than the timer says you should then you eventually run into a brownout and blackout. You just hope the buffer is big enough to outlast the timer.

The non timer designs though react instantly to the buffer drain and refill the buffer. No brownout/blackout risk there given minimal buffer to allow the plant to get up to working temperature again.

It's true a timer design can keep the reactor always at working temperature while the non-timer designs always have the reactor cool down and heat back up. But the timer design does not prevent the reactor from cooling too much in a power spike. That's why you need those big buffers.

Again that's completly unecessary if you use the power plant for rocket launching or science or their mining outposts, since the consumption in those case would average easily despite the periodic spike and valley.

I'm just saying it functions if you do it properly, not that it's what everyone should do, this is "all the different ways to increase efficiency", you can call it the manually-controlled power plant that still could be an efficient power plant. Wether or not YOU want to measure consumption is your own personnal liking

It functions in some narrow controlled circumstances while the other methods always work. And if you know your power needs that well then just build the reactor to match and run a 100% duty cycle. The difference between 1000 reactors running 100% and 2000 reactors running 50% is not worth the complexity and UPS cost in a megabase.

You can measure the throughput of the steam with some clever tank and pump tricks. That is the only practical way to actually measure how much energy you consume anywhere realtime.

That' still a 1 cycle delay somewhat . What you are measuring when you measure steamflow is how fast your buffered energy is consumed. Wether the buffered energy is under the form of heat/steam/already-inserted-fuel-cell doesn't matter. Then when all/most of it is consumed, the refuel happens. You measure "actual" consumption but it is only updated when the energy is all gone, after 1 cycle of measuring/consumption on the previous fuel.

If by cycle you mean fuel cell cycle then no. You can measure the steam flow tick by tick. So you can see an alien attack basically a tick after the laser turrets start to fire. Give is a second for them to really get up to draining power. And then you can throw fuel in the reactor knowing a new alien wave is going to massively drain your power reserves. So it doesn't have to be a 1 cycle delay. That's the predictive part coming into play.

Obviously if you predict wrong and it was only 10 biters attacking the wall and not a full wave then you can overheat the reactor (but then your big buffers save the day).

So the better use of the measurement is to determine when it is safe to put in another fuel cell. Only use the measure of how much additional energy you can buffer right now. If that is less than 1 fuel cell generates then throw in one fuel cell. Most of the designs shown so far use that method. If you predict power usage you can potentially insert fuel cells earlier (or later) and use fewer steam tanks or accumulators. But if you guess wrong you either waste fuel or have a brownout. And steam tanks are cheap and you only need like 2 tanks to be on the safe side.

that's the same thing as measuring the amount of water in the glass or the amount of non-water

In order to know if it's safe to insert a new fuel cell you need to know how much energy you can buffer, which is the same amount as the amount of energy you have consumed since the previous refuel.

But you are correct saying a wrong prediction can lead to brown-out or black out, that's if when refilling the amount of energy lost in previous cycle you run out of buffer, like running out of memory to write the debt of energy from one cycle to another. In practice though you just need a few accumulator ringing and alarm when not 100%. They would make you notice if the timer need to be reduced if you don't check it as accuratly as the manual recommend. Depending on how you implement your clock the inserter could be instant inserting fuel when you reduce time to a smaller duration than the one already passed since previous refuel, that's something i'll consider

You still aren't seeing the predictive part, where you don't have that 1 cycle delay. If all you do is look at the amount of free buffer then just insert the cell when the buffer is free. No timer needed. The only advantage of a timer would be to predict the power consumption to know how much of the fuel cell will be consumed and how much you need to buffer in the time the fuel cell burns. You predict the future so you can insert the fuel earlier than the buffer would allow. That way you need less buffer. Make a good prediction and you don't need steam tanks at all, just the heat pipes buffer enough.

You are forgetting that inserters drain energy while idle. If you have 1000 reactors or 2000 reactors the power per swing basically doubles. The cost of the swing doubles. But at the 480MW consumption rate the time between refuels basically doubles. So that balances out. The tiny bit more is near 0. It's there but near 0. The time of the swing compared to time between swings is, well, rounding error . So you have double the number of inserters and twice the time they are idle. That means the inserters consume 4 times as much power per cycle.

It's easier if you do the math with a fixed fuel cells per second value. Then 2x2N reactor will swing half as often as a 2xN reactor. Keeps the numbers simpler. Don't compare cycles as the fuel input per cycle isn't constant. Twice the number of inserters means double the power drain if you ignore the swing. The problem is that "a tiny bit more than doubled" has to make up for the double power drain of the inserters. That works going from 4 to 8 reactors. I don't know where it stops working but I suspect 1000 to 2000 won't make up the increased drain.

Earlier someone suggested using burner inserter and showed the math how much energy the inserters consume and how much burner inserter would safe. So my suggestion would be to scroll back to that and use that math.

Note: If you use burner inserter then there is no drain, only the swing. All the above is for electrical inserters. With burner inserters the bigger the better unless you have a combinator per reactor or other drain.

I was forgetting the drain, i admit. but look i think that's the post you mentionned :

Because of you I was playing around with trying to use 3 burner inserter, one for fuel injection one for fuel ejection, and another one to fuel the 2nd. If you put nuclear fuel, because that's what is done in nuke plant, you have 1210000kJ/70kJ=17285.7143 swing per nuclear fuel. Counting for fuel ejection and fuel injection every 200 second, that means 1 nuclear fuel would last 3457142.86 second in those 2, ( around 40 days ).

Which means the burner inserter that refuel the ejection inserter will do a swing every 40 days, which means it will need to confiscate one fuel to refuel itself every:

17 285.7143 x 3 457 142.86= 59 759 183 772.245 sec, 5.9E10 sec, that's 691 657 days, or 1894 years.

Is it bad that I feel no guilt?

If you keep your power consumption in a 1GW range you can have just one steerable 1GW reactor, everything else always-on. Gut check says very, very few bases have to worry about long-term power cycling in excess of 1GW, am I just too pedestrian here?

That means for almost all your power generation you can use stacked load/unload, one loading swing every 600s, with a loading inserter wired read-hold to the power switch on the unload circuit. Use fast inserters for unload, they can take 3 spent cells in the half-swing the power switch is closed, and you get ten minutes per swing, basically zero power consumption for the unload, 17285 swings is 120 *days* per fuel cell. One in the tank, one in the buffer, that's 240 days. Or I suppose it would be even cheaper to use just one burner for one reactor's reload, and use fast-inserters-powered-for-46-ticks-every-ten-minutes for all the rest.

At that point, you might as well just not bother with a refueling supply, your solstice festival can include a reactor-service-inserter-refueling celebratory ritual with lots of pomp and circumstance, maybe even an inserter dance!

With those ideas you don't have drains. Since the only inserter that stay awake for logic is a burner inserter who has no drain. The ejecting inserter is only consuming energy for a fix amount of ticks the strict minium which is then constant, and not doubling over time as drain. "Rounding errors" you said, but if we were to be super precise, even those little ticks wouldn't count.

if you take 1 reactor and 1 inserter. The ratio [cost of inserting the fuel/energy worth of 1 swing] is biggest.
if you take 2 reactor and 2 inserter. The [cost of inserting the fuel] has doubled, [the energy worth of 1 swing] a bit more than doubled.
if you take 4 reactor and 4 inserter. The [cost of inserting the fuel] has doubled, [the energy worth of 1 swing] a tiny bit more than doubled.

This means If you remove drain from the equation it holds true no ?

Also this is another consideration, this is also about the inner solar grid to try and immunize the inserters and their logic from power shortages.

If we consider the most efficient power plant, it would be a solar field, with a little nuke power plant somewhere haha. but staying at the scale at which we wouldn't consider it a solar plant, when the solar pannel is embedded in a tilable design for example, the implementations details becomes what could makes the difference between an optimal existing or the biggest the best.

using only burner inserter is similar to using solar as you rely on energy from outside the nuclear plant to remove the energy cost of some part of the process.

as you said i agree combinators act like drain.

Yes, if you eliminate the drain then I believe more reactors will always gain you a little. At some point (quite early) the extra gain won't be enough to turn on a lamp but at the accuracy of floats I don't think you can get the gain to 0.

The difference between 2x2N and 2 2xN reactors becomes practically irrelevant for something like N=16. But the difference between finding a lake to build a 2x32 reactor or two 2x16 reactors is huge. If you have to travel a million miles to the reactor then your trains transporting the fuel will eat a lot of energy. Even lots of 2x4 reactors might be more efficient overall. Then again there are waterfill mods. Makes reactor building so much easier.

[mmmPI]

Huh? I think you have that backward. If you refuel by time and suddenly consumption goes way up then your buffer gets drained. If you don't refuel earlier than the timer says you should then you eventually run into a brownout and blackout. You just hope the buffer is big enough to outlast the timer.

you mean if your 100 science assembly suddenly start consuming more power than their maximum consumption ? or also if your 1000 miners decide to go on strike to ask for a better electricity paiment ? Or if your rocket silo start shooting rockets 2 by 2 sometimes by accident?

when would your consumption go way up exactly if you set up your system properly ?

because you said it need to be automated, then i gave examples of situations in which you could automate, then you said it should be automated again. If you measure your energy consumption to adapt your timers by reading item on a belt ? you count how many were produced, you have the amount of energy "in real time", that's one example but i made several already and you seem to ignore them to always repeat the same things.

if you design messy and chaotic system, then of course it's easy to say "but when i play i can never predict the consumption because i always make 1 power plant for the whole base using always the exact same mechanisms."

The non timer designs though react instantly to the buffer drain and refill the buffer. No brownout/blackout risk there given minimal buffer to allow the plant to get up to working temperature again.

there are many different non-timer design some of which have a stupid fuel check that can cause black out if you don't have enough fuel to power all the core.

It doesn't mean "non-timer design" doesn't work, that's just one case of poor implementation.

I feel that's what you are doing, pickip up poor implementation example everytime purposedly or not i do not know.

[mmmPI]

The thing is, there's a difference between your reactor temperature (what I called the hottest point) and your coldest heat exchanger (the furthest from the reactor) and I wanted to compute how much temperature difference I use vs how much is left for that hot/cold temperature difference (again, it's a spatial hot/cold, not a time hot/cold).
So since I only use 80% of the heat capacity, that means both the (spatial) hot and cold points will (time-wise) heat up / cool down with a 400°C vairation (80% of the 500°C working range), which leaves 100°C for the temperature difference between the (spatial) hottest and coldest points.
For example you can have your reactor going 600~1000°C and your coldest heat exchanger 500~900°C

Hope it's a bit clearer now.

yes it is (I think) . (i think) the 100° for working range is a bit low, in my design the reactors were 750° when the furthest exchanger was 510° when under full load for long time, i'm not sure the reactor wouldn't have reached 1000° before the exchanger reached 800° for example.

but maybe it's because my heatpipes are too thin and extended, they do not convey heat properly, otherwise maybe my reactors would only be 600° and then i would have this 400° range available .i could know the range should be 400° given the amount of heatpipes i've layed out already using your reasonning.

Given that my reactor was 750° following your reasonning i could reduce some of the GJ counted for storage and re-asses the capacity of my heat buffer deducting the energy stored as temperature i can read when the plant is functionning and maybe fix my thing so the heat is better conveyed.

the "how much i use" is how much margin you have when designing a plant between the hot and cold point (spatially) for the hot spatial point not to reach 1000° when it's also the hottest time-wise moment.

[mrvn]

Huh? I think you have that backward. If you refuel by time and suddenly consumption goes way up then your buffer gets drained. If you don't refuel earlier than the timer says you should then you eventually run into a brownout and blackout. You just hope the buffer is big enough to outlast the timer.

you mean if your 100 science assembly suddenly start consuming more power than their maximum consumption ? or also if your 1000 miners decide to go on strike to ask for a better electricity paiment ? Or if your rocket silo start shooting rockets 2 by 2 sometimes by accident?

when would your consumption go way up exactly if you set up your system properly ?

When you blueprint the next 100 science assembly or the next rocket silo. Normally in game you are always expanding. Most people don't just build a fixed number of rocket silos and then let it run for a year.

because you said it need to be automated, then i gave examples of situations in which you could automate, then you said it should be automated again. If you measure your energy consumption to adapt your timers by reading item on a belt ? you count how many were produced, you have the amount of energy "in real time", that's one example but i made several already and you seem to ignore them to always repeat the same things.

if you design messy and chaotic system, then of course it's easy to say "but when i play i can never predict the consumption because i always make 1 power plant for the whole base using always the exact same mechanisms."

The game is pretty chaotic. You never know where you find the next aliens and get attacked. Or where you find the next ore field and add 200 miners.

And I never said I make just 1 power plant or that that would be the reason consumption can't be predicted. That isn't even true.

The non timer designs though react instantly to the buffer drain and refill the buffer. No brownout/blackout risk there given minimal buffer to allow the plant to get up to working temperature again.

there are many different non-timer design some of which have a stupid fuel check that can cause black out if you don't have enough fuel to power all the core.

It doesn't mean "non-timer design" doesn't work, that's just one case of poor implementation.

I feel that's what you are doing, pickip up poor implementation example everytime purposedly or not i do not know.

Weather a fuel check is a poor implementation or not is an opinion. But that is a totally different argument. You can do fuel checking in a timer design just as in a buffer design. They are totally independent. You layer one above the other. Fact is that if you don't have enough fuel you get power problems. The fuel check just changes how that manifests and how the reactor recovers from it if at all.

All the non-timer design have in common that they will insert fuel when they believe the resulting heat/steam can be buffered. They may or may not have an additional check like the fuel check. I haven't picked any of them and there is no need. My argument is about any of them vs. your timer based system. Outside external factors like no fuel coming in the buffer system will never blackout. So I don't know where you get the opinion they are poor implementations.

[gGeorg]

how much temperature difference I use vs how much is left for that hot/cold temperature difference
For example you can have your reactor going 600~1000°C and your coldest heat exchanger 500~900°C

in my design the reactors were 750° when the furthest exchanger was 510° when under full load for long time, i'm not sure the reactor wouldn't have reached 1000° before the exchanger reached 800° for example.

Here is a thing I noticed in my last design itteration.
1. The coldest heat exchanger have to be 501C in stable production. (full consumption) For simple reason, if it goes higher it means there was not enough heat consumption. e.g. not enough water or not enough heat exchangers. In my case fourleaf, with very short heat-pipes, core is about 545C then furthest piece of heatpipe 501C. e.g. every unit of heat available is changed to steam and then to power. Temperature can not rise over the lowest limit. Temperature can rise up only in case of low power consumption or grid disconnection due to high battery level.
2. Make plant wastelest and loosels is relatively easy. More challenging is make it brownout durable. In testing I noticed that my plant can hit full power output in about 90s. That is suprise to me. Heatpipes are VERY SLOW. I am not sure if it is a "new" feature or it was always like that. Anyway it means, I have to do some math, to design it so, I have enough heat in reserve for 90 seconds. ( The heating up interval for 2N where heatpipes are about 3 times longer than mine are going to be insteresting)
I want my plant To be prepared for the worst case: 300MW output, insert of next fuell cell is delayed > heat is consumed up to a safe level > now new cell is inserted and consumption rise to 480MW at the same moment. (laser fence) . In this moment, brownout could happen because my plant has heat reserve for about 15s of full run. In 16th second new cell gives about 25% power output.

I can understand xaetral, why you need (compute) amount of heat actually stored. It is a bit of brain teaser.

[mmmPI]

Weather a fuel check is a poor implementation or not is an opinion. But that is a totally different argument.

yes you get my point exactly.

wether you like the system or you consider it not automated enough for your taste with your own personnal experience of average game is also an opinion.

now in theory and in practice it functions,unless you poorly implement the fuel check, unless you poorly implement your timers.

[mrvn]

how much temperature difference I use vs how much is left for that hot/cold temperature difference
For example you can have your reactor going 600~1000°C and your coldest heat exchanger 500~900°C

in my design the reactors were 750° when the furthest exchanger was 510° when under full load for long time, i'm not sure the reactor wouldn't have reached 1000° before the exchanger reached 800° for example.

Here is a thing I noticed in my last design itteration.
1. The coldest heat exchanger have to be 501C in stable production. (full consumption) For simple reason, if it goes higher it means there was not enough heat consumption. e.g. not enough water or not enough heat exchangers. In my case fourleaf, with very short heat-pipes, core is about 545C then furthest piece of heatpipe 501C. e.g. every unit of heat available is changed to steam and then to power. Temperature can not rise over the lowest limit. Temperature can rise up only in case of low power consumption or grid disconnection due to high battery level.
2. Make plant wastelest and loosels is relatively easy. More challenging is make it brownout durable. In testing I noticed that my plant can hit full power output in about 90s. That is suprise to me. Heatpipes are VERY SLOW. I am not sure if it is a "new" feature or it was always like that. Anyway it means, I have to do some math, to design it so, I have enough heat in reserve for 90 seconds. ( The heating up interval for 2N where heatpipes are about 3 times longer than mine are going to be insteresting)
I want my plant To be prepared for the worst case: 300MW output, insert of next fuell cell is delayed > heat is consumed up to a safe level > now new cell is inserted and consumption rise to 480MW at the same moment. (laser fence) . In this moment, brownout could happen because my plant has heat reserve for about 15s of full run. In 16th second new cell gives about 25% power output.

I can understand xaetral, why you need (compute) amount of heat actually stored. It is a bit of brain teaser.

The reactor can get cooler than your 545°C. Say you are only drawing 1MW of power from the reactor. Then even the closest heat exchanger to the reactor is sufficient on it's own to produce all the needed steam. So your steam tank will remain full until the closest heat exchanger drops below 501°C. At which point your reactor might be at 505°C or so. It then has to heat up to 545°C and heat up all the heat pipes and heat exchangers till it reaches the furtest. Meanwhile the nearer heat exchangers will drain heat by producing some steam.

So if you do calculate the heat capacity and time till full production better start of with everything at 500°C to be on the safe side. Also note that while getting up to full speed some steam is produced. So you don't have to buffer all the steam for full power over the full duration of heating back up. You can factor in the generated steam into the equations.

Personally I would measure it experimentally in factorio or at least by simulation. The math gets rather complex with the heat exchangers cutting in one by one if you want a formula that tells you the number of ticks till full steam production.

You also need to consider that right when you insert fuel power consumption could become 0. Then all the generated steam remains and fills up the steam tanks. And then the reactor can heat up to 1000°C and heatpipes to 1000°C - distance (starting at 1). For your above example that would be an increase of 1000 - 545 = 455°C for every reactor and heat pipe. That's your thermal buffer. Your steam buffer - level at which you insert fuel + thermal buffer must be larger than the energy produced by one fuel cycle to be safe from overheating.

[mmmPI]

All the non-timer design have in common that they will insert fuel when they believe the resulting heat/steam can be buffered.

The non timer designs though react instantly to the buffer drain and refill the buffer. No brownout/blackout risk there given minimal buffer to allow the plant to get up to working temperature again.

The reactor can get cooler than your 545°C. Say you are only drawing 1MW of power from the reactor. Then even the closest heat exchanger to the reactor is sufficient on it's own to produce all the needed steam. So your steam tank will remain full until the closest heat exchanger drops below 501°C.

Does that mean some non-timer design actually do not refuel when they believe the resuting heat can be buffered ? but only later ,sometimes much later ? when the buffer is almost empty and even worse case completly empty ? definitly not refilling instantly the buffer, totally having brownout risk here.

Otherwise the reactor would never be that cold right ? because that means a lot more energy can be buffered ? so the fuel wasn't inserted when the buffer was just enough to handle the capacity.

this is exactly the risk i described. I know the logic is working and it's an implementation detail. but you said the other method always work:

It functions in some narrow controlled circumstances while the other methods always work. And if you know your power needs that well then just build the reactor to match and run a 100% duty cycle. The difference between 1000 reactors running 100% and 2000 reactors running 50% is not worth the complexity and UPS cost in a megabase.

no the other methods don't always work, they also need to be implemented correctly.

Yes exactly build a reactor that match your need an run it 100%, or 50% if you make it twice as big, or 10% if you make it 10x as big, maybe also a set-up to shut it down completly. that's it you have an efficient clock-design ! congrats you finally understood one use case !

Instead of "your need" you can read "your uranium production" or "sulfuric acid production". it's fairly easy to count how many miners you have, but you can also select them with the copy paste function.

Also i thought megabase use solar but you seem to already have an opinion on what is worth or not in case of nuclear megabase so no need to discuss that i guess.

When you blueprint the next 100 science assembly or the next rocket silo. Normally in game you are always expanding. Most people don't just build a fixed number of rocket silos and then let it run for a year.

ahahahah, that one is funny seriously, "when you blueprint the next 100 science" your electric consumption will unexpectedly rise ? that's stupid, no matter how you plan to power your thing you need to be aware of how much it will consume and if you have enough electricity production to handle it before you plop the blueprint. If you don't nothing will save your power that's just a newbie mistake. Especially if you "blueprint" something lol, the maximum consumption you can easily compute. most people use their brain when playing the game they do not go like hohoho i plop 200 miners and see afterward if my power shut down or not.

Therefore adapting the timer is trivial, and if you say "but i don't want to move to change a combinator" that's fine you can use a train for the clock and change time from far away, they are drain-free, so they are more efficient than combinators usually used for regulation mechanism.

Or even better because it need to be automated, you plop down the blueprint, your science start flowing on a belt, your power plant measure the flow of science and count that there are 3 blueprints running now instead of the 2 that were running earlier, it automatically change timer from 50% to 75% and make a little lamp 3/4 glow so you know you can plop down another of your science blueprint and that it would just just reach 95% of the power plant total theoric production, because you computed it and therefore the timers will be on-point to avoid fuel waste and be efficient. They should also be reduced automatically if one of your science module would stop running due to reading on the belt less science per minutes. (you know in case one of your outpost get attacked by biters and they eat the rails )

The game is pretty chaotic. You never know where you find the next aliens and get attacked. Or where you find the next ore field and add 200 miners.

And I never said I make just 1 power plant or that that would be the reason consumption can't be predicted. That isn't even true.

Your argument really imply you do have only 1 plant, because if you have 2 separate grid, one for science one for defense perimeter then you would know the science grid is not chaotic. you know when you get an amount of SPM, you try to have it average, you don't have 12 SPM for 10 minutes, then 50 SPM for 10 minutes then 15 SPM for 10 minutes.

also you don't happen to chaoticly place 200 miners without having any clue that power consumption will increase. If you can't predict that after placing 200 miners the consumption will increase, i agree you shouldn't use timer, you shouldn't probably use electric devices altogether x).

[foamy]

how much temperature difference I use vs how much is left for that hot/cold temperature difference
For example you can have your reactor going 600~1000°C and your coldest heat exchanger 500~900°C

in my design the reactors were 750° when the furthest exchanger was 510° when under full load for long time, i'm not sure the reactor wouldn't have reached 1000° before the exchanger reached 800° for example.

Here is a thing I noticed in my last design itteration.
1. The coldest heat exchanger have to be 501C in stable production. (full consumption) For simple reason, if it goes higher it means there was not enough heat consumption. e.g. not enough water or not enough heat exchangers. In my case fourleaf, with very short heat-pipes, core is about 545C then furthest piece of heatpipe 501C. e.g. every unit of heat available is changed to steam and then to power. Temperature can not rise over the lowest limit. Temperature can rise up only in case of low power consumption or grid disconnection due to high battery level.
2. Make plant wastelest and loosels is relatively easy. More challenging is make it brownout durable. In testing I noticed that my plant can hit full power output in about 90s. That is suprise to me. Heatpipes are VERY SLOW. I am not sure if it is a "new" feature or it was always like that. Anyway it means, I have to do some math, to design it so, I have enough heat in reserve for 90 seconds. ( The heating up interval for 2N where heatpipes are about 3 times longer than mine are going to be insteresting)
I want my plant To be prepared for the worst case: 300MW output, insert of next fuell cell is delayed > heat is consumed up to a safe level > now new cell is inserted and consumption rise to 480MW at the same moment. (laser fence) . In this moment, brownout could happen because my plant has heat reserve for about 15s of full run. In 16th second new cell gives about 25% power output.

I can understand xaetral, why you need (compute) amount of heat actually stored. It is a bit of brain teaser.

The reactor can get cooler than your 545°C. Say you are only drawing 1MW of power from the reactor. Then even the closest heat exchanger to the reactor is sufficient on it's own to produce all the needed steam. So your steam tank will remain full until the closest heat exchanger drops below 501°C. At which point your reactor might be at 505°C or so. It then has to heat up to 545°C and heat up all the heat pipes and heat exchangers till it reaches the furtest. Meanwhile the nearer heat exchangers will drain heat by producing some steam.

So if you do calculate the heat capacity and time till full production better start of with everything at 500°C to be on the safe side. Also note that while getting up to full speed some steam is produced. So you don't have to buffer all the steam for full power over the full duration of heating back up. You can factor in the generated steam into the equations.

Personally I would measure it experimentally in factorio or at least by simulation. The math gets rather complex with the heat exchangers cutting in one by one if you want a formula that tells you the number of ticks till full steam production.

You also need to consider that right when you insert fuel power consumption could become 0. Then all the generated steam remains and fills up the steam tanks. And then the reactor can heat up to 1000°C and heatpipes to 1000°C - distance (starting at 1). For your above example that would be an increase of 1000 - 545 = 455°C for every reactor and heat pipe. That's your thermal buffer. Your steam buffer - level at which you insert fuel + thermal buffer must be larger than the energy produced by one fuel cycle to be safe from overheating.

This is why a consumption tracker can be better. However, it suffers from an issue of a buffer potentially not holding a full cycle's generation, which can throw the calculations out. Correcting for this precisely is complex.

[SoShootMe]

Does that mean some non-timer design actually do not refuel when they believe the resuting heat can be buffered ? but only later ,sometimes much later ? when the buffer is almost empty and even worse case completly empty ? definitly not refilling instantly the buffer, totally having brownout risk here.

Minimising buffered energy is a natural design goal, but that does not mean (deliberately) going so far that brownouts may occur. Combined with the goal of maximising efficiency, that mean inserting fresh cells into reactors as late as possible, when any later would cause a brownout, not as early as possible, when any earlier would cause reactors to reach 1000C.

It functions in some narrow controlled circumstances while the other methods always work.

no the other methods don't always work, they also need to be implemented correctly.

You can correctly implement a nuclear plant with dynamic control (eg using steam buffer monitoring) that will "always work" in that it will never waste cells and (assuming sufficient supply of cells) is always able to provide the required power, within some limits. Equally, you can correctly implement a plant with static control (a preset timer) that will always work, but only in the narrow case that (average) power consumption is known.

In practice, power consumption is not known precisely so static control implies an ongoing need to adjust the timer, in order to avoid wasting cells or having brownouts/blackouts. That ongoing adjustment need not be onerous (with sufficient buffer) but I think it is fair to say that it means static control does not always work.

[mmmPI]

Minimising buffered energy is a natural design goal, but that does not mean (deliberately) going so far that brownouts may occur. Combined with the goal of maximising efficiency, that mean inserting fresh cells into reactors as late as possible, when any later would cause a brownout, not as early as possible, when any earlier would cause reactors to reach 1000C.

That was exactly my point. You want to refill as late as possible to reduce the amount of buffer required for those design. You do not plan to refill as soon as you can buffer things.

Although this is very similar when you try to minimize the buffer, identical maybe in therory, it's different when you plan to have several fuel cycle of buffer. You then do not plan to refill "as soon as energy storage is available", nor do you plan to refuel " at the last moment possible to minimize buffer without cutting sypply of power".

The risk of accidently of having your timers off cascading into brown/black out is that much attenuated by your amount of buffer and the margin you have on either extreme.

The timers being off will deviate the heat equilibrium over one end, too hot and wastefull, too cold and alarm ringing, over periods of time that you can configure.

This is not really something you have to take in consideration when designing something different than with timers.

You can correctly implement a nuclear plant with dynamic control (eg using steam buffer monitoring) that will "always work" in that it will never waste cells and (assuming sufficient supply of cells) is always able to provide the required power, within some limits. Equally, you can correctly implement a plant with static control (a preset timer) that will always work, but only in the narrow case that (average) power consumption is known.

In practice, power consumption is not known precisely so static control implies an ongoing need to adjust the timer, in order to avoid wasting cells or having brownouts/blackouts. That ongoing adjustment need not be onerous (with sufficient buffer) but I think it is fair to say that it means static control does not always work.

i think saying "always work" and "do not work" is not very helpful describing the mechanism.

Listing the conditions for it to work and the consequences of them being met or not i think is more helpful and the purpose of discussion.

also comparing their relative efficiency seems to be the aim of the topic, maximizing efficiency.

dynamic control, if you go reallllly into the nit-picks, are unecessary consumption of energy in some cases, you can do a 200 second loop belt that trigger both refuel and ejection at the same time without any drain and combinator. That's doesn't work if your consumption is not constant and the maximum.

You can have a dynamicly set timer, does that fall into the category of the "static control" "non-timer" "self regulated" "automated" ?

the case where you read the amount of science on the belt, or the amount of ore at railstation, if you read X amount of material, you can know you have consumed X amount of energy and change the timer to match consumption. Doing so you have something that " always work" but "not with everything" ?



[ Edit] Also one other point that i think you are missing when you say in practice consumption is not known precisely. If you consider you buffer has a capacity of a 10 you put 5 in it.
let say 10 and 5 are the equivalent of 10 and 5 hour of energy for full power production. ( that's a lot but for the sake of the example ).

After 1 hour you read your consumption clicking on a power pole. You read 0.6. What you do the next hour ? you produce 0.6.
the next hour you read 0. what you do next hour ? you produce 0.
the next hour you read 0.9. what you do next hout ? you produce 0.9?

0.6 is 60% of the max capacity of the plant.
0.9 is 90% capacity of the plant.

the buffer lag behind with 1 cycle delay. It's also considered reading in real time, where time is discretized with units of 1 hour.

If you think about the numbers you don't even need those 10 and 5, maybe 3 and 1 would be enough. But it's up to you to plan for more to give you more time to click , or more time for the situation to average. You know the number at each cycle cannot be more than 1 several time in a row, that's just impossible that you read more consumption after 1hour than the maximum production from your power plant several cycle in a row.

This is only the tortuous way to help you set-up the timers manually if you don't want to use a timer that is automatically set-up based on other value you can read from circuit. If you want to be very-nitpicky and say "it can always work if you use it properly". Or maybe more helpful, explainning how you can use it if you want to, not trying to sell my crap.

[gGeorg]

Loading more than one cell at time for sake of "save_energy_of_swing" is false design branch. This idea creates GIANORMOUS needs of heat buffering to reach lossless requirement.

Build cost and UPS cost and power per tile (power density) says clear NO to this design idea.

[mrvn]

All the non-timer design have in common that they will insert fuel when they believe the resulting heat/steam can be buffered.

The non timer designs though react instantly to the buffer drain and refill the buffer. No brownout/blackout risk there given minimal buffer to allow the plant to get up to working temperature again.

The reactor can get cooler than your 545°C. Say you are only drawing 1MW of power from the reactor. Then even the closest heat exchanger to the reactor is sufficient on it's own to produce all the needed steam. So your steam tank will remain full until the closest heat exchanger drops below 501°C.

Does that mean some non-timer design actually do not refuel when they believe the resuting heat can be buffered ? but only later ,sometimes much later ? when the buffer is almost empty and even worse case completly empty ? definitly not refilling instantly the buffer, totally having brownout risk here.

Otherwise the reactor would never be that cold right ? because that means a lot more energy can be buffered ? so the fuel wasn't inserted when the buffer was just enough to handle the capacity.

No, that's not what it means.

The trigger is the steam level. As long as steam production > steam consumption the steam level in the buffer will not fall. (Assuming the steam from a row of heat exchangers is collected and not buffered separately.) And the lower power consumption is the fewer heat exchangers need to be working to produce enough steam.

It's rather unlikely that a 1TW power plant only has a few MW power drain. Even with for solar power you would have more drain on it every night and a few MW drain over the time of a day wouldn't cool the reactor much.

this is exactly the risk i described. I know the logic is working and it's an implementation detail. but you said the other method always work:

It functions in some narrow controlled circumstances while the other methods always work. And if you know your power needs that well then just build the reactor to match and run a 100% duty cycle. The difference between 1000 reactors running 100% and 2000 reactors running 50% is not worth the complexity and UPS cost in a megabase.

no the other methods don't always work, they also need to be implemented correctly.

Yes exactly build a reactor that match your need an run it 100%, or 50% if you make it twice as big, or 10% if you make it 10x as big, maybe also a set-up to shut it down completly. that's it you have an efficient clock-design ! congrats you finally understood one use case !

Instead of "your need" you can read "your uranium production" or "sulfuric acid production". it's fairly easy to count how many miners you have, but you can also select them with the copy paste function.

Also i thought megabase use solar but you seem to already have an opinion on what is worth or not in case of nuclear megabase so no need to discuss that i guess.

Obviously everything needs to be implemented correctly.

The problem I have with your timer design you described is that it has either a very narrow use case (a static mega base that never changes) or with automatic timer setting it reacts very slowly to change and that puts it in danger of running out of buffered energy. You were talking about measuring power consumption over hours. The non-timer designs react in ticks to power demands and then minutes (90s for the one person that measured it) to get to full power generation. Minutes you can cover with 2-4 tanks per reactor. Hours not so much.

When you blueprint the next 100 science assembly or the next rocket silo. Normally in game you are always expanding. Most people don't just build a fixed number of rocket silos and then let it run for a year.

ahahahah, that one is funny seriously, "when you blueprint the next 100 science" your electric consumption will unexpectedly rise ? that's stupid, no matter how you plan to power your thing you need to be aware of how much it will consume and if you have enough electricity production to handle it before you plop the blueprint. If you don't nothing will save your power that's just a newbie mistake. Especially if you "blueprint" something lol, the maximum consumption you can easily compute. most people use their brain when playing the game they do not go like hohoho i plop 200 miners and see afterward if my power shut down or not.

Therefore adapting the timer is trivial, and if you say "but i don't want to move to change a combinator" that's fine you can use a train for the clock and change time from far away, they are drain-free, so they are more efficient than combinators usually used for regulation mechanism.

Or even better because it need to be automated, you plop down the blueprint, your science start flowing on a belt, your power plant measure the flow of science and count that there are 3 blueprints running now instead of the 2 that were running earlier, it automatically change timer from 50% to 75% and make a little lamp 3/4 glow so you know you can plop down another of your science blueprint and that it would just just reach 95% of the power plant total theoric production, because you computed it and therefore the timers will be on-point to avoid fuel waste and be efficient. They should also be reduced automatically if one of your science module would stop running due to reading on the belt less science per minutes. (you know in case one of your outpost get attacked by biters and they eat the rails )

It's not exactly unexpected. I expect changes in power consumption very much. That's my point actually. power consumtion is never a constant in a game that's still
being played and not just watched.

I only consider the last a viable design. Anything that needs a player to adjust something will quickly fail. Even in single player games people forget. In multiplayer games to many changes happen at once and coordinating the power increase for every single change would be a nightmare.

But look at your design description. You talk about measuring power consumption over hours. Say your reactor is running at 50% before you blueprint. How long does it take your clock design to adjust the clock to 75% then? As I understood you run down the timer to 0 and refuel. And then you set the new timer to the new consumption rate you measured. So until the last timer reached 0 your reactor still runs as if it only had 50% power consumption. You will refuel far too late and probably get a blackout.

That was my point. The timer is a prediction of when you need to refuel. If you don't adjust it while it's counting down to changes in demand then BOOM. There is a one cycle delay to adjust the timer to the new setting.

The buffer design on the other hand watched consumption and reacts without that 1 cycle delay to the stored stream being used to make up lack of heat. That difference of 1 cycles is why I think the timer design is bad.

The game is pretty chaotic. You never know where you find the next aliens and get attacked. Or where you find the next ore field and add 200 miners.

And I never said I make just 1 power plant or that that would be the reason consumption can't be predicted. That isn't even true.

Your argument really imply you do have only 1 plant, because if you have 2 separate grid, one for science one for defense perimeter then you would know the science grid is not chaotic. you know when you get an amount of SPM, you try to have it average, you don't have 12 SPM for 10 minutes, then 50 SPM for 10 minutes then 15 SPM for 10 minutes.

also you don't happen to chaoticly place 200 miners without having any clue that power consumption will increase. If you can't predict that after placing 200 miners the consumption will increase, i agree you shouldn't use timer, you shouldn't probably use electric devices altogether x).

Now you jump from multiple plants to multiple grids. Given how easy it is for grids to accidentally get connected I've never seen that being used in a multiplayer game. It never lasts long. So I put that example into a special use case too.

[mmmPI]

It's rather unlikely that a 1TW power plant only has a few MW power drain. Even with for solar power you would have more drain on it every night and a few MW drain over the time of a day wouldn't cool the reactor much.

I'm not seing your point here

Obviously everything needs to be implemented correctly.

The problem I have with your timer design you described is that it has either a very narrow use case (a static mega base that never changes) or with automatic timer setting it reacts very slowly to change and that puts it in danger of running out of buffered energy. You were talking about measuring power consumption over hours. The non-timer designs react in ticks to power demands and then minutes (90s for the one person that measured it) to get to full power generation. Minutes you can cover with 2-4 tanks per reactor. Hours not so much.

I do understand you have a problem with the design. I think you do not picture how to implement it correctly, then you point out problematic things that could happen due to a poor implementation and say using them that the logic doesn't work. Or that it's slow, or that you risk blackout.

It's not exactly unexpected. I expect changes in power consumption very much. That's my point actually. power consumtion is never a constant in a game that's still
being played and not just watched.

You keep saying constant i don't know if i should try to explain to you again that it's "average" not constant

It can be average with many change. And no matter what happens you can always calculate the average of the last hour right ?, like in theory, indirectly, or just click a power pole. And this doesn't require anything "constant", just you reason with interval of time during which you calculate average consumption.

I only consider the last a viable design. Anything that needs a player to adjust something will quickly fail. Even in single player games people forget. In multiplayer games to many changes happen at once and coordinating the power increase for every single change would be a nightmare.

that's an opinion, you choose to count some design as ok and some others, based on arbitrary reasons that are your own choice ( perhaps also because i couldn,'t explain clearly why what you see as limitations are sometimes just inadapted implementation), as not viable. Fine if you don't think it's the right call to use something finicky, don't use it. It's not like i didn't mentionned it at least 5 times in the thread that i wasn't advising it for multiplayer or even at all but it was still something that existed.

But look at your design description. You talk about measuring power consumption over hours. Say your reactor is running at 50% before you blueprint. How long does it take your clock design to adjust the clock to 75% then? As I understood you run down the timer to 0 and refuel. And then you set the new timer to the new consumption rate you measured. So until the last timer reached 0 your reactor still runs as if it only had 50% power consumption. You will refuel far too late and probably get a blackout.

Olololo, the design i posted has a fuel capacity under 3 cycle, less than 10 minutes.

The others figures i used are just things to illustrate the logic it's made up numbers with very large order of magnitude so it's easier to picture the relation between them.

If you use belt load of item to trigger different % of charge on the power plant, the adaptation is not slower than with your regular steam reading power plant.

You didn't understood "run down the timer to 0 and refuel". I didn't meant to describe how timer design function but how every nuclear power plant function. When some fuel is already being burnt for example, and the power consumption increase, the steam flow increases, the power plant read it instantly, yet, in practice nothing will happen until the fuel is burnt completly, there's nothing else to do to adapt to the spike that adding fuel and fuel is already there being burnt. Therefore yes you can read consumption in real time, both couting item or reading steam flow, thing is you can only react every 200 sec or so. It's more complicated in detail, but you can't put more fuel than every 200 sec on average. ( not counting loading stack of 3 and buffering lol).

No matter how precise and fast is your acknowledgment of the consumption spike, the answer you can give doesn't have the same wide range of precision.
In practice in steamflow regulated design what will happen is that you will read earlier than usually that the steam tank is empty or almost empty, and accelerate refuel, what i called "skip the 30 sec of waiting". And then if the consumption drops ,you adapt by doing nothing. so again no need to hurry.

what i meant is how to implement the timer. It shouldn't be a run down, the opposite actually, this way whenever you change the timer, if the new value happen to be lower than the time passed since last refuel, the refuel would be instant. ( say 600 second had passed since last refuel that was planned every 800 second and you click to have now timer every 500 second instead of 800, well then 600>500= instant refuel and then count again up to 500). This was a way to explain to you that reaction can also be "instant" on a manually setup thing.

That was my point. The timer is a prediction of when you need to refuel. If you don't adjust it while it's counting down to changes in demand then BOOM. There is a one cycle delay to adjust the timer to the new setting.

The buffer design on the other hand watched consumption and reacts without that 1 cycle delay to the stored stream being used to make up lack of heat. That difference of 1 cycles is why I think the timer design is bad.

Are you saying the buffer design is faster than the non-buffer design and that's why you dislike it ? buffer design the the clock timer ?

i assumed you used wrong word here. You meant the other way around ?

just in case i'm repasting this because it's not the first time you say it need prediction while it's not true, i thought you were trolling me but maybe i'm just that bad at explaining things x).

[ Edit] Also one other point that i think you are missing when you say in practice consumption is not known precisely. If you consider you buffer has a capacity of a 10 you put 5 in it.
let say 10 and 5 are the equivalent of 10 and 5 hour of energy for full power production. ( that's a lot but for the sake of the example ).

After 1 hour you read your consumption clicking on a power pole. You read 0.6. What you do the next hour ? you produce 0.6.
the next hour you read 0. what you do next hour ? you produce 0.
the next hour you read 0.9. what you do next hout ? you produce 0.9?

0.6 is 60% of the max capacity of the plant.
0.9 is 90% capacity of the plant.

You do not predict, you do not need constant consumption. You can buffer enough to make sure you have no risk no matter the situation and then adapt your production to your consumption over the timespan that you have availble thanks to you buffer.

i'm detailing again but that's probably the last time.

T0, you have 5 hours of full power under the form of heat stored.
from T0 to T1 you consume amount of energy.
T1, you read you last hourly consumption : 240 MW. You have a 480MW power plant, you know then that your buffer has 4.5 hours left of energy instead of 5. due to running 30 minutes at 50% and having 5H worth of buffer initially.
You set your timer to 50%, this way from T1 to T2 you will refill the energy dissipated between T0 and T1.
from T1 to T2 you consume amount of energy. And you produce enough for 0.5 hours worth of full power.
T2, you read your last hourly consumption : 120 MW. This means 25% capacity your buffer is 5-0.5+0.5-0.25.that's the 5 initial minus 1rst interval consumption + 2 interval production, (those 2 canceling out). You are left with initial buffer -0.25, and you just read 25% capacity over last our. You just set up timer to 25%
from T2 to T3 you consume amount of energy, and you produce enough for 0.25 hours to refill consumption between T1 and T2.
you read at T3 consumption is 480MW. Whaow much spike, still laughable , because no risk of brownout or black out. instead buffer is just 4 hours worth of energy.


See my point ? no need to predict ? It's like reading in real time, but with time discretized in interval of a duration you can increase by having lots of heat pipes, the bigger buffer the more flexibility to react. It's not slow it's synchronized with your buffer. The more buffer you have like 20 cycle of fuel doesn't make it slow to the point of there would be a risk if you plan accordingly. It takes 20 cycle of fuel time to adapt ? mmm yes , this means what you call spike is just a mere fluctuation of rounding error.

Now you jump from multiple plants to multiple grids. Given how easy it is for grids to accidentally get connected I've never seen that being used in a multiplayer game. It never lasts long. So I put that example into a special use case too.

you didn't understood i was meaning multiple grids when i said multiple plants,that's clearly my bad, but i'm not jumping, it's you who now understand what i meant. Over which you emit an opinion. The facts i was mentionning is that you can take measure to reduce and even nullify what you call chaotic consumption. i understand you discard it with an opinion saying it's a special use case, it happens to accidentaly to connect thing in multiplayer and so on, that fine.

[mrvn]

It's rather unlikely that a 1TW power plant only has a few MW power drain. Even with for solar power you would have more drain on it every night and a few MW drain over the time of a day wouldn't cool the reactor much.

I'm not seing your point here

Just pointing out the unlikelyhood of getting the reactor cooled down to 500°C. It can only happen if you draw less power than one head exchanger produces. The more power you draw the hotter the reactor is before the steam tanks are starting to empty.

Obviously everything needs to be implemented correctly.

The problem I have with your timer design you described is that it has either a very narrow use case (a static mega base that never changes) or with automatic timer setting it reacts very slowly to change and that puts it in danger of running out of buffered energy. You were talking about measuring power consumption over hours. The non-timer designs react in ticks to power demands and then minutes (90s for the one person that measured it) to get to full power generation. Minutes you can cover with 2-4 tanks per reactor. Hours not so much.

I do understand you have a problem with the design. I think you do not picture how to implement it correctly, then you point out problematic things that could happen due to a poor implementation and say using them that the logic doesn't work. Or that it's slow, or that you risk blackout.

No, I never reasoned using a poor implementation. I reasoned by poor design. I'm also not saying the logic doesn't work, just that it doesn't work fast enough.

Which lead to you adding the 20 fuel cycles buffer to fix. But that fix makes the whole design pointless because any buffer above 5 cycles doesn't need to insert one fuel cell at a time. It can just insert 5 with a stack inserter any time the buffer is near empty.

It's not exactly unexpected. I expect changes in power consumption very much. That's my point actually. power consumtion is never a constant in a game that's still
being played and not just watched.

You keep saying constant i don't know if i should try to explain to you again that it's "average" not constant

It can be average with many change. And no matter what happens you can always calculate the average of the last hour right ?, like in theory, indirectly, or just click a power pole. And this doesn't require anything "constant", just you reason with interval of time during which you calculate average consumption.

I only consider the last a viable design. Anything that needs a player to adjust something will quickly fail. Even in single player games people forget. In multiplayer games to many changes happen at once and coordinating the power increase for every single change would be a nightmare.

that's an opinion, you choose to count some design as ok and some others, based on arbitrary reasons that are your own choice ( perhaps also because i couldn,'t explain clearly why what you see as limitations are sometimes just inadapted implementation), as not viable. Fine if you don't think it's the right call to use something finicky, don't use it. It's not like i didn't mentionned it at least 5 times in the thread that i wasn't advising it for multiplayer or even at all but it was still something that existed.

But look at your design description. You talk about measuring power consumption over hours. Say your reactor is running at 50% before you blueprint. How long does it take your clock design to adjust the clock to 75% then? As I understood you run down the timer to 0 and refuel. And then you set the new timer to the new consumption rate you measured. So until the last timer reached 0 your reactor still runs as if it only had 50% power consumption. You will refuel far too late and probably get a blackout.

Olololo, the design i posted has a fuel capacity under 3 cycle, less than 10 minutes.

The others figures i used are just things to illustrate the logic it's made up numbers with very large order of magnitude so it's easier to picture the relation between them.

And how can that be? How do you get from 3 cycles to 10 minutes. That's the BIG design flaw I see or I didn't get in your design.

A cycle is one insertion of fuel in every reactor. Say you have a 2x2 reactor then one fuel insertion produces 480MW for 200s. 3 fuel insertions at full power is 600s or 10 minutes. Ok, that is the figure you claim.

But what if I draw only 1MW of power to take an extreme. Then one fuel injection lasts for 200*480 = 96000s = 1600m = 26.666 hours. So a bit above a day. 3 cycles would then be 3 days. Your measurement of the power needs for the last day decide the fuel production for the next 3 days. Not 10 minutes. That's the part I feel your design fails.

If you use belt load of item to trigger different % of charge on the power plant, the adaptation is not slower than with your regular steam reading power plant.

You didn't understood "run down the timer to 0 and refuel". I didn't meant to describe how timer design function but how every nuclear power plant function. When some fuel is already being burnt for example, and the power consumption increase, the steam flow increases, the power plant read it instantly, yet, in practice nothing will happen until the fuel is burnt completly, there's nothing else to do to adapt to the spike that adding fuel and fuel is already there being burnt. Therefore yes you can read consumption in real time, both couting item or reading steam flow, thing is you can only react every 200 sec or so. It's more complicated in detail, but you can't put more fuel than every 200 sec on average. ( not counting loading stack of 3 and buffering lol).

No matter how precise and fast is your acknowledgment of the consumption spike, the answer you can give doesn't have the same wide range of precision.
In practice in steamflow regulated design what will happen is that you will read earlier than usually that the steam tank is empty or almost empty, and accelerate refuel, what i called "skip the 30 sec of waiting". And then if the consumption drops ,you adapt by doing nothing. so again no need to hurry.

what i meant is how to implement the timer. It shouldn't be a run down, the opposite actually, this way whenever you change the timer, if the new value happen to be lower than the time passed since last refuel, the refuel would be instant. ( say 600 second had passed since last refuel that was planned every 800 second and you click to have now timer every 500 second instead of 800, well then 600>500= instant refuel and then count again up to 500). This was a way to explain to you that reaction can also be "instant" on a manually setup thing.

Well, if the refuel can be instant then where does the 3 cycle delay come from. It can't be both. Or does the instant only work when you draw more power than predicted while when drawing less power it takes 3 cycles for the plant to slow down?

That's basically the sticking point we are at.

That was my point. The timer is a prediction of when you need to refuel. If you don't adjust it while it's counting down to changes in demand then BOOM. There is a one cycle delay to adjust the timer to the new setting.

The buffer design on the other hand watched consumption and reacts without that 1 cycle delay to the stored stream being used to make up lack of heat. That difference of 1 cycles is why I think the timer design is bad.

Are you saying the buffer design is faster than the non-buffer design and that's why you dislike it ? buffer design the the clock timer ?

i assumed you used wrong word here. You meant the other way around ?

just in case i'm repasting this because it's not the first time you say it need prediction while it's not true, i thought you were trolling me but maybe i'm just that bad at explaining things x).

[ Edit] Also one other point that i think you are missing when you say in practice consumption is not known precisely. If you consider you buffer has a capacity of a 10 you put 5 in it.
let say 10 and 5 are the equivalent of 10 and 5 hour of energy for full power production. ( that's a lot but for the sake of the example ).

After 1 hour you read your consumption clicking on a power pole. You read 0.6. What you do the next hour ? you produce 0.6.
the next hour you read 0. what you do next hour ? you produce 0.
the next hour you read 0.9. what you do next hout ? you produce 0.9?

0.6 is 60% of the max capacity of the plant.
0.9 is 90% capacity of the plant.

You do not predict, you do not need constant consumption. You can buffer enough to make sure you have no risk no matter the situation and then adapt your production to your consumption over the timespan that you have availble thanks to you buffer.

i'm detailing again but that's probably the last time.

T0, you have 5 hours of full power under the form of heat stored.
from T0 to T1 you consume amount of energy.
T1, you read you last hourly consumption : 240 MW. You have a 480MW power plant, you know then that your buffer has 4.5 hours left of energy instead of 5. due to running 30 minutes at 50% and having 5H worth of buffer initially.
You set your timer to 50%, this way from T1 to T2 you will refill the energy dissipated between T0 and T1.
from T1 to T2 you consume amount of energy. And you produce enough for 0.5 hours worth of full power.
T2, you read your last hourly consumption : 120 MW. This means 25% capacity your buffer is 5-0.5+0.5-0.25.that's the 5 initial minus 1rst interval consumption + 2 interval production, (those 2 canceling out). You are left with initial buffer -0.25, and you just read 25% capacity over last our. You just set up timer to 25%
from T2 to T3 you consume amount of energy, and you produce enough for 0.25 hours to refill consumption between T1 and T2.
you read at T3 consumption is 480MW. Whaow much spike, still laughable , because no risk of brownout or black out. instead buffer is just 4 hours worth of energy.

If you replace fast with responsive then yes. Your design is not responsive enough in my opinion.

What you actually described above just looks at the consumption of the last hour and produces as much in the next hour. No "skip the 30 sec of waiting". No "wait an extra 30 sec". That design has a 1 hour responsiveness and a 1 hour buffer is enough to make it work. In the case the plant jumps to no power draw at worst the steam buffer is full at the end of the hour and you won't throw in any fuel. In the case the plant jumps to full power draw at worst the steam buffer is empty at the end of the hour and you throw in fuel every 200s. Either worst case just hits the limit of the steam buffer without brownout or overheating.

Note: obviously you need a little bit more buffer because the game isn't that perfect and you have delays or rounding errors here and there.

But an hours is way to long. How would you modify the design so you can measure every 60 seconds? Where do the "wait an extra 30 sec" come in?

Here is how I would modify your design: Why always wait an hour to measure consumption? Why not simply count up the consumed energy till you hit one fuel cycle worth of power and then throw in fuel. The timer thing is really just delaying the responsiveness of the reactor by one measurement interval.

See my point ? no need to predict ? It's like reading in real time, but with time discretized in interval of a duration you can increase by having lots of heat pipes, the bigger buffer the more flexibility to react. It's not slow it's synchronized with your buffer. The more buffer you have like 20 cycle of fuel doesn't make it slow to the point of there would be a risk if you plan accordingly. It takes 20 cycle of fuel time to adapt ? mmm yes , this means what you call spike is just a mere fluctuation of rounding error.

I see that in that description you have no prediction. You also don't have any "wait an extra 30sec" or do any adapting. It's simply "energy consumed in the last hour" == "energy produced in the next hour" with a larger enough (pre-filled) buffer so production can be 1 hour behind consumption.

You do some math with the steam buffer levels but that seems to be ignored. It boils down to just "Consumption = 25% ==> timer = 25%". You don't explicitly say what happens when the power consumed in one hour is less than 1 fuel cycle. But I assume then it just gets folded over into the next measurement. Or how it would account for drift due to rounding errors or imprecise measurment. You actually do have to look at the steam level at some point and adjust your timer a bit if the level differs from the expected.

Or is the steam level how you measure energy consumption? Not counting science flask on a belt? Then it would self adjust. But really that's just a more complex steam buffer design then: If steam level low => throw in fuel. Except you only check once an hour and spread the refueling over an hour. I rather check every tick.

[mmmPI]

Just pointing out the unlikelyhood of getting the reactor cooled down to 500°C. It can only happen if you draw less power than one head exchanger produces. The more power you draw the hotter the reactor is before the steam tanks are starting to empty.
[later]
But what if I draw only 1MW of power to take an extreme. Then one fuel injection lasts for 200*480 = 96000s = 1600m = 26.666 hours. So a bit above a day. 3 cycles would then be 3 days. Your measurement of the power needs for the last day decide the fuel production for the next 3 days. Not 10 minutes. That's the part I feel your design fails.

as you said yourself this case is very unlikely right ? For the timer to be 26 hours, that would mean for example the average of the last hour is 1 MW draw ?

Even this unlikely situation in which you don't understand how to setup properly the timers to make a design function there is a proper way to do that wouldn't "fail" ( you reasonned with a poor design then take it as illustration saying "my" design fail. what i really dislike. the only thing that fail is the thing you have in your mind maybe ?

The amount of time you need to update the timer is cycle of updating not cycle of fuel. Cycle of updating depend on the quantity of buffer you have, which tells you in second the update time. this not changing over time. In the many example i detailed i choose 1 hour as update time. ( or less than 10 minutes for the design i posted pictures) this means every hour you update the timer to a new value. If you do 25% power, i never said you should wait 4 hours to check again. Why suddenly you would need to wait 26 hours ?

You check every hour if you consider you buffer big enough to handle at least a full 1hour for nothing. I you set your timer to 1000000000 years, and consumption rise up, you need not wait 100000000000 years, you need to check every hours.

the 10 minutes cycle i told in the picture i made is how frequent you should check the timer. that's only 3 cycle that's an illustrating example of the logic i quickly made last week that you dislike and seem decided to let me know. since it can buffer 3 cycle of fuel, you need to check every 10 minutes for the precise case of there would be a low drain for long and a sudden consumption. Buffer being 3 cycle of fuel if you wait more than that you have no power after 10 minute of drain. 10 minutes is the margin of action you give yourself thanks to the buffer. If you change timer to 26 hours and leave it for 26 hours ,it means you don't understand the design, not that it fails.

No, I never reasoned using a poor implementation. I reasoned by poor design. I'm also not saying the logic doesn't work, just that it doesn't work fast enough.

i agree you reason with poor design, you say it doesn't work fast enough but that's because you are not doing it properly most likely. Maybe you should try to make a design like that yourself. I have explained it several time already. can you define "fast enough ?"

Which lead to you adding the 20 fuel cycles buffer to fix. But that fix makes the whole design pointless because any buffer above 5 cycles doesn't need to insert one fuel cell at a time. It can just insert 5 with a stack inserter any time the buffer is near empty.

you don't understand why the 20 cycle of fuel are just player choice ? you could use the amount you want, the amount of buffer is what will determine the interval at which you should check the timer.

Rest of what you say don't apply to design where you use heat pipes instead of storage tank, you can't measure the heat in them, that's also a point i detailed earlier when i posted a picture of a modded game where nuclear reactor are heating furnaces and you need to be efficient to not overburn but you can't read steam.

Also you can totally use max stack size with the 20 cycle of buffer that doesn't make the design pointless, that's part of what you can do thanks to it. being even more efficient in MW per fuel cell by reducing the [cost per swing]/[value of energy worth per swing].

And how can that be? How do you get from 3 cycles to 10 minutes. That's the BIG design flaw I see or I didn't get in your design.

A cycle is one insertion of fuel in every reactor. Say you have a 2x2 reactor then one fuel insertion produces 480MW for 200s. 3 fuel insertions at full power is 600s or 10 minutes. Ok, that is the figure you claim.

yep that's clearly one of the thing you didn't get, or maybe i explained poorly after loosing all my patience. because after that you said the update interval would increase if the consumption decrease. You know like you use less water so the bill only arrive every 42 days. No the bill is still every month ^^, the update interval is the same. The bill itself may be less or more depending on your consumption. the bill is the debt of energy from on cycle to another, CYCLE OF UPDATE.

The relation between the cycle of update and the fuel cycle is that the cycle of update is [your total energy buffer]/[the number of 200sec it takes to fill it up]. That is a fix amount.

Well, if the refuel can be instant then where does the 3 cycle delay come from. It can't be both. Or does the instant only work when you draw more power than predicted while when drawing less power it takes 3 cycles for the plant to slow down?

That's basically the sticking point we are at.

That could be instant if you want it to be, if you reduce the timer outside of the update interval, you can have the power plant realize the new timer is shorter than the time already passed since last refuel and instant refuel this in case you have already really messed up and that your buffer is going to be empty. that's a second layer of protection like a fuel check haha.

otherwise as i said if you need to not insert fuel to adapt to your consumption it is both instant and not instant as the thing to do is stay idle. There's no difference between idling right away, or waiting some time to start idling.

when you say it takes the plant 3 cycle to slow down it doesn't make sense to me. if we talk cycle of update no, it need 1 during 1 hour you consumed a lot. next hour nothing, next hour full power. What your power plant will do is the same with 1 cycle delay, not 3 and not cycle of fuel, cycle of update. IF you update every hour, you gonna have 18 cycle of fuel the hour when you don't consume. full power during 1 hour when you use nothing. That's the worst case, that's when you need the maximum buffer, that's how you compute the relation between update time and buffer.

If you were to be smart about it and that the worst case situation seem like it would last long. you would offset your update moment by half a cycle of update, this way every cycle you would read a 50% consumption while inside each cycle of update there would be 50% of time with lots of consumption and 50% with no consumption.

the situation where you have 100% 0% 100% 0% 100% 0% alternating is not something youhave to worry in practice, it's just the limit in theory.

If you replace fast with responsive then yes. Your design is not responsive enough in my opinion.

what you said earlier makes me doubt we are talking about the same thing if you were to wait 26 hours to slow down consumption when you draw just 1 MW i can understand why you think it's not responsive but that has nothing to do with me !

Also i described several methods, like reading on belt the item flow to change the timer according to the energy consumption they represent, and also having a predictable consumption due to using power switch, and also the manual thing. ( which has many declinaisons of semi manual given the time you spend combinators to ease decision process) i put 2 pictures and a map. So at this point i'm not sure what you say with "your design" i do not own anything here.

what you describe as not responsive enough is your strawman, you have a version of a thing in your mind that doesn't work and you keep saying how bad it is.

What you actually described above just looks at the consumption of the last hour and produces as much in the next hour. No "skip the 30 sec of waiting". No "wait an extra 30 sec". That design has a 1 hour responsiveness and a 1 hour buffer is enough to make it work. In the case the plant jumps to no power draw at worst the steam buffer is full at the end of the hour and you won't throw in any fuel. In the case the plant jumps to full power draw at worst the steam buffer is empty at the end of the hour and you throw in fuel every 200s. Either worst case just hits the limit of the steam buffer without brownout or overheating.

yes exactly what i described just reach the limits without brownout or overheating, without "skip 30 sec". What ?! yeah this one i agree ! if you can see this i don't understand why you don't understand the others x)

the "skip 30 sec" or "add 30 extra" is the way design that adapt in 1 cycle of fuel react. That's why you don't have it in my description, that's because that's how a design on steam buffer or steam flow would react. It's not a timer with repeating interval, each period of time between refuel is different. thus you can read their mechanism as smaller version/edge cases/ part of the subgroup of the thing that function with timer, but the interval is different everytime, it has to be since you only have enough buffer for 200 sec at full power. Here the update time and the refuel time are the same thing. well to some degree, because if you read the consumption decreased to 0 just after you inserterted fuel, what you do is just idling till buffer is emptied we can't really say you adapt super fast if you start wating faster right?

Note: obviously you need a little bit more buffer because the game isn't that perfect and you have delays or rounding errors here and there.

exactly i like that spirit don't let the little details of implementation blinds you from the power of the timer !

But an hours is way to long. How would you modify the design so you can measure every 60 seconds? Where do the "wait an extra 30 sec" come in?

I'm afraid 60 second doesn't make sense to me that's less that the time the fuel takes to burn, what good would it do to me that i know the fuel will be made into buffered heat rather than electricity 5 second 10 second 50 second or even 199 second after insertion ? it only make sense when you/the automation take the decision. At 199 sec you need to know somewhat if you are going to insert a newfuel cell or not. If you do that that's only having 1 cycle delay. 200 second is the minimum interval i would say, under that it doesn't make sense, you couldn't react and add more fuel there's one burning already, you couldn't react and start doing nothing, that's what will happen anyway at least for a whole 200- a few ticks.

i don't recall a "wait an extra 30 sec", but it comes in from steam buffer design, if you had fuel inserted every 240 second to match you consumption, that is now getting reduced. It will be "read" by the buffer power plant, and you will have 1 fuel cycle that will have say 30 second added to make it 270 second because the steam wasn't consumed. then if it stays at this lower level the steam tank will trigger refuel every 270 second, if consumption rises again, one cycle will be shorten, skip 20 second, and then the next fuel cycle is increased say by 30 second and so on. Irregular and chaotic insertion.

While timer design aim at reading average and then having harmonic consumption. thus it helps the larger their buffer.

Here is how I would modify your design: Why always wait an hour to measure consumption? Why not simply count up the consumed energy till you hit one fuel cycle worth of power and then throw in fuel. The timer thing is really just delaying the responsiveness of the reactor by one measurement interval.

I see that in that description you have no prediction. You also don't have any "wait an extra 30sec" or do any adapting. It's simply "energy consumed in the last hour" == "energy produced in the next hour" with a larger enough (pre-filled) buffer so production can be 1 hour behind consumption.

i do not read steam at all so that's already one modification of the design. Timers are a way to use heatpipes as energy buffer, if you use tanks it's like cheating in my opinion it makes it another design that wouldn't need to function based on timer for the many reason you keep throwing at my face x)

no prediction, big enough buffer to lag 1 hour behind is the logic behind it yes. then average consumption in 1 hour because that's something you can do manually easily due to the power GUI, 5 or 10 minutes are easy value too i think.

You do some math with the steam buffer levels but that seems to be ignored. It boils down to just "Consumption = 25% ==> timer = 25%". You don't explicitly say what happens when the power consumed in one hour is less than 1 fuel cycle. But I assume then it just gets folded over into the next measurement. Or how it would account for drift due to rounding errors or imprecise measurment. You actually do have to look at the steam level at some point and adjust your timer a bit if the level differs from the expected.

maybe you thought i mathed steam buffer while i was mathing energy buffer while using a steam tank as unit ? i did not used steam i think.

when the power consumed in one hour is less than 1 fuel cycle it's up to you to decide how you do the rounding, either you consider it should round to a consumption level that means you don't refuel at all during the corresponding cycle of update. ( like 1 MW draw on a 1 TW plant, if you have 20 cycle fuel of buffer for your TW plant, you can let the whole system cool down by 0.000002°C or so that's a made up value, what you call drift over time. if you were to be super nerdy you could report the rounded bits and add them up to round up the time you need to round up.)

If it's a bit too big to be neglected, you can refuel once instead of 0. round it up once in a while to make up for the time you rounded down. equilibrium over time . It's not that hard to read the temperature of the system in practice, you just need 1 point where you always measure to compare. But you could report the little bits and be super precise if you would, like in theory that's not flawed it's just needless. You'd better turn off you plant and reopen it with 1 fuel cycle worth of refill if the draw when turned off was long and important enough to be noticeable;don't forget that such amount of buffers are instantly available in case of spike even if store in heat pipes, those could be 700 800 900°!

Or is the steam level how you measure energy consumption? Not counting science flask on a belt? Then it would self adjust. But really that's just a more complex steam buffer design then: If steam level low => throw in fuel. Except you only check once an hour and spread the refueling over an hour. I rather check every tick.

I don't use steam level period. that's another design than couting science flask on a belt. If you do this ( the counting science) yes it can be made self adjusting, that's my point, it a more complex steam buffer design that doesn't use steam buffer but instead only heatpipes on which you can't read things thus why you need a workaround with a more complex system that can take many shape as long as you get the logic right

Checking every tick is same as you said earlier, adapting every 60 second, you can't, knowing every tick what's happening and taking a decision very 200 second minimum is the same thing to me as getting all information before taking the decision, wheter it is many different reports or one with all the information averaged doesn't make any difference.

If you do with belts that's different. you do not have regular update interval, instead you can count the number of item that goes through 1 belt, and given your assembly crafting speed you can know how much energy cost 1 to make, or you can read an average in the power graph and divide, if you know producing 10K science cost you 1 fuel cycle. Then you count up to 10K and you launch 1 fuel cycle.
IF you want to be more efficient, you count up to 20K science and you launch 1 fuel cycle of a 2X bigger power plant. this means you get more of the efficency bonus hahaha.

the logic is the same refilling the quantity of energy in the buffer after some time consuming it, or after consuming it to make item. in one case you read the energy consumption with your eyes, the others the machine does because you told it science flask represent energy. In one case you want repeating update interval, like every 20 minutes, big for peace of mind, at the cost of a very low kw/tile since most of it is buffer for energy. in the other case reading belt you can follow the same logic as trying to minimze the buffer because it can be made to refill the exact quantity of energy that was consumed at the exact moment when it knows there is enough room available to store the energy.

[mmmPI]

Loading more than one cell at time for sake of "save_energy_of_swing" is false design branch. This idea creates GIANORMOUS needs of heat buffering to reach lossless requirement.

Build cost and UPS cost and power per tile (power density) says clear NO to this design idea.

yes in practice it is not something i would use, but i think in theory it's one of the way to gain the very last little % of efficiency if you try to make a record. Like those car that can go super far with only 1L of fuel. Not the car you want to drive, but cool nonetheless. Making people innovate thanks to a specific challenge, and then what those innovations are used to is up to anyone .

[mrvn]

The amount of time you need to update the timer is cycle of updating not cycle of fuel. Cycle of updating depend on the quantity of buffer you have, which tells you in second the update time. this not changing over time. In the many example i detailed i choose 1 hour as update time. ( or less than 10 minutes for the design i posted pictures) this means every hour you update the timer to a new value. If you do 25% power, i never said you should wait 4 hours to check again. Why suddenly you would need to wait 26 hours ?

Ok, so there we have the big misunderstanding. A poor choice of word where cycle means multiple things.

But an hours is way to long. How would you modify the design so you can measure every 60 seconds? Where do the "wait an extra 30 sec" come in?

I'm afraid 60 second doesn't make sense to me that's less that the time the fuel takes to burn, what good would it do to me that i know the fuel will be made into buffered heat rather than electricity 5 second 10 second 50 second or even 199 second after insertion ? it only make sense when you/the automation take the decision. At 199 sec you need to know somewhat if you are going to insert a newfuel cell or not. If you do that that's only having 1 cycle delay. 200 second is the minimum interval i would say, under that it doesn't make sense, you couldn't react and add more fuel there's one burning already, you couldn't react and start doing nothing, that's what will happen anyway at least for a whole 200- a few ticks.

i don't recall a "wait an extra 30 sec", but it comes in from steam buffer design, if you had fuel inserted every 240 second to match you consumption, that is now getting reduced. It will be "read" by the buffer power plant, and you will have 1 fuel cycle that will have say 30 second added to make it 270 second because the steam wasn't consumed. then if it stays at this lower level the steam tank will trigger refuel every 270 second, if consumption rises again, one cycle will be shorten, skip 20 second, and then the next fuel cycle is increased say by 30 second and so on. Irregular and chaotic insertion.

While timer design aim at reading average and then having harmonic consumption. thus it helps the larger their buffer.

The point of measuring every 60 seconds would be to get the response time down to 60 seconds. Obviously if you just inserted a fuel cell then for the next 200 seconds there is nothing you can do. But at 240 seconds you measure, at 300 seconds you measure, at 360 seconds you measure and each time you decide if sometime in the next 60 seconds you should insert a fuel cell. That would greatly reduce the amount of buffering you need. The choice of 60s was so that it is clearly always below the length of a fuel cycle. You could do 300s intervals. That would still often have the timer > 300s and show how you deal with intervals where no fuel cell is inserted and consumption carries over into the next interval.

Here is how I would modify your design: Why always wait an hour to measure consumption? Why not simply count up the consumed energy till you hit one fuel cycle worth of power and then throw in fuel. The timer thing is really just delaying the responsiveness of the reactor by one measurement interval.

I see that in that description you have no prediction. You also don't have any "wait an extra 30sec" or do any adapting. It's simply "energy consumed in the last hour" == "energy produced in the next hour" with a larger enough (pre-filled) buffer so production can be 1 hour behind consumption.

i do not read steam at all so that's already one modification of the design. Timers are a way to use heatpipes as energy buffer, if you use tanks it's like cheating in my opinion it makes it another design that wouldn't need to function based on timer for the many reason you keep throwing at my face x)

The steam is the only palce in the power plant we can measure. So naturally I assumed you would measure steam. As you say you can't measure heat. And if the plant is to automatically adjust to changes in power demands then you have to measure something. So either steam level or steam flow.

Note: you can measure steam flow with 2 tanks, 4 pumps and a steam turbine. So no big huge steam tank buffer needed. I assumed you would be doing that and the suggestion to count science packs on a belt more of a joke. Counting belts will break when they backlog.


You say you want to use heat as storage medium. How do you buffer 5 or 20 hours worth of heat? Every heat pipe you add between reactor and heat exchanger lowers the temp by 1°C and reduces your thermal range for the buffer. So there is a maximum of heat you can store. I wonder if 5 hours is even possible. Pretty sure 20 hours isn't. Just wondering.

no prediction, big enough buffer to lag 1 hour behind is the logic behind it yes. then average consumption in 1 hour because that's something you can do manually easily due to the power GUI, 5 or 10 minutes are easy value too i think.

You do some math with the steam buffer levels but that seems to be ignored. It boils down to just "Consumption = 25% ==> timer = 25%". You don't explicitly say what happens when the power consumed in one hour is less than 1 fuel cycle. But I assume then it just gets folded over into the next measurement. Or how it would account for drift due to rounding errors or imprecise measurment. You actually do have to look at the steam level at some point and adjust your timer a bit if the level differs from the expected.

maybe you thought i mathed steam buffer while i was mathing energy buffer while using a steam tank as unit ? i did not used steam i think.

Yes, that was very confusing.

when the power consumed in one hour is less than 1 fuel cycle it's up to you to decide how you do the rounding, either you consider it should round to a consumption level that means you don't refuel at all during the corresponding cycle of update. ( like 1 MW draw on a 1 TW plant, if you have 20 cycle fuel of buffer for your TW plant, you can let the whole system cool down by 0.000002°C or so that's a made up value, what you call drift over time. if you were to be super nerdy you could report the rounded bits and add them up to round up the time you need to round up.)

If it's a bit too big to be neglected, you can refuel once instead of 0. round it up once in a while to make up for the time you rounded down. equilibrium over time . It's not that hard to read the temperature of the system in practice, you just need 1 point where you always measure to compare. But you could report the little bits and be super precise if you would, like in theory that's not flawed it's just needless. You'd better turn off you plant and reopen it with 1 fuel cycle worth of refill if the draw when turned off was long and important enough to be noticeable;don't forget that such amount of buffers are instantly available in case of spike even if store in heat pipes, those could be 700 800 900°!

Oh you definetly can't ignore even the 0.000002°C. Over time every little error adds up. If you don't have any steam tanks to measure the reactor actually still has stored heat then you will eventually drift into a brownout. And then your math shows you are using exactly as much energy as you put fuel in and will never increase the fuel input. Worse, every little error will further reduce your fuel input till you have a total blackout. A 0.000002°C drift sounds ridiculous and the sun will burn out before the reactor fails. But a) we are talking theoretical here and b) it will not just be 0.000002°C.

So I'm afraid you need to cheat and have some steam tank somwhere. Even if it is just one for the whole reactor. You need an "Oh shit, my reactor is cold" check in there somwhere to reset your calculated heat level. And I can't think of a "Oh shit, my reactor is overheating" check. If you ever overestimate the consumed power then that error will add up to till your reactor always runs at maximum temp and every overestimation gets lost.

So you would practically have to always round energy consumption down and fuel a bit less so you only have to deal with the "Oh shit, my reactor is cold" case. At which point I say: Why bother? Just the "Oh shit, my reactor is cold" check on it's own will drive the reactor because that is the steam buffer design.

If you do with belts that's different. you do not have regular update interval, instead you can count the number of item that goes through 1 belt, and given your assembly crafting speed you can know how much energy cost 1 to make, or you can read an average in the power graph and divide, if you know producing 10K science cost you 1 fuel cycle. Then you count up to 10K and you launch 1 fuel cycle.
IF you want to be more efficient, you count up to 20K science and you launch 1 fuel cycle of a 2X bigger power plant. this means you get more of the efficency bonus hahaha.

But that's just another way of cheating then. Measuring belt throughput or steam throughput, same thing in the end. Steam is just more accurate because it directly goes into power production. Counting science packs has to much variance. With the way assemblers start and stop because the ratios aren't perfect or inserters sometimes pick up one item and sometimes 2 or have to chase items on the belt more or less I highly doubt you can give an answer to how much power a science pack really needs. A value that won't cause your calculations to drift too far from reality. And without any steam tank to reset your math any drift means death, eventually.

Not to mention laser turrets. No way to count how many shots they fire.

the logic is the same refilling the quantity of energy in the buffer after some time consuming it, or after consuming it to make item. in one case you read the energy consumption with your eyes, the others the machine does because you told it science flask represent energy. In one case you want repeating update interval, like every 20 minutes, big for peace of mind, at the cost of a very low kw/tile since most of it is buffer for energy. in the other case reading belt you can follow the same logic as trying to minimze the buffer because it can be made to refill the exact quantity of energy that was consumed at the exact moment when it knows there is enough room available to store the energy.

Can you provide an actual savegame of a reactor that computes the power consumption and self adjust to the power consumed? Because I just can't believe it will work past 100 or 1000 times the size of the heat buffer without any way to self correct by means of a steam tank.