Friday Facts #428 - Reactor & Logistics circuit control

[mmmPI]

Those examples do not fulfill what I wanted to do precisely and often are overcomplicated unnecessarily.

Don't even look at what people did with trains then x)

[XT-248]

Those examples do not fulfill what I wanted to do precisely and often are overcomplicated unnecessarily.

Don't even look at what people did with trains then x)

Okay.

I said it before, and someone didn't listen.

I have already tried and haven't found a solution (even with trains and splitters/belts), but a new feature is coming, either with patch 2.0 or Space Age DLC. I might be able to do something.


I wanted to show my excitement for the upcoming feature.

[mmmPI]

I said it before, and someone didn't listen.

I have already tried and haven't found a solution (even with trains and splitters/belts), but a new feature is coming, either with patch 2.0 or Space Age DLC. I might be able to do something.

I was under the impression that you said it was impossible to do because you failed at it while ignoring the "complicated" setup that exist ilustrating that it is in fact possible to create logic gate without electricity. I'm glad the misunderstanding is dispelled.

[XT-248]

I said it before, and someone didn't listen.

I have already tried and haven't found a solution (even with trains and splitters/belts), but a new feature is coming, either with patch 2.0 or Space Age DLC. I might be able to do something.

I was under the impression that you said it was impossible to do because you failed at it while ignoring the "complicated" setup that exist ilustrating that it is in fact possible to create logic gate without electricity. I'm glad the misunderstanding is dispelled.

I am telling you. It can not be done because it is not yet Oct 21st, 2024, and it relies on a new feature that is unreleased before then.

I am not ignoring the other solutions because they have drawbacks or issues that make it impossible to use them.

[mmmPI]

I am telling you. It can not be done because it is not yet Oct 21st, 2024, and it relies on a new feature that is unreleased before then.
I am not ignoring the other solutions because they have drawbacks or issues that make it impossible to use them.

I thought you were ignoring working solutions because they were too complicated x)

Hopefully you can make your simple version, the (currently-broken) way you envisionned it, hopefully you will share it too it will be very interesting x)

[XT-248]

I am telling you. It can not be done because it is not yet Oct 21st, 2024, and it relies on a new feature that is unreleased before then.
I am not ignoring the other solutions because they have drawbacks or issues that make it impossible to use them.

I thought you were ignoring working solutions because they were too complicated x)

Hopefully you can make your simple version, the (currently-broken) way you envisionned it, hopefully you will share it too it will be very interesting x)

I don't need to hope. I know it can be done.

[JackTheSpades]

A bit late to the party but is there any chance we could also hook up labs to the logistic network. The main thing I'd be interested in is getting the time per research unit. I usually build my lab setup such that it works for the 60s/unit as that is the highest value so if I randomly get faster research (e.g. because of mods or research that I've been putting off for later) it tends to burn through my buffers and trigger any potential "chest empty" alarms I might have set up.
For example, I could just disable the belts to 1/4 of my labs if I could read that the current research only requires 45s/unit. Or disable the inserters when using a sushi belt supply.

Any other data would be more of a "while you're at it" kinda thing. Like reading the completion percentage or the total amount of science/units needed. Could be neat for building custom progress bars with lights.
Maybe also the required sciences per unit. Can't think of any actual application but could be neat to maybe set filters? Also some mods have uneven science requirements (e.g. requiring two bottles of red and one of green per unit) so perhaps those could make use of that data.

tl;dr reading science labs data would be neat and I don't think there would be any downsides to having them?

[mmmPI]

I don't need to hope. I know it can be done.

I meant it for me too, i hope you share it nonetheless, because it's harder to share a vision that cannot be done in the game, it's like the vision was flawed or something x). I could see some splitter logic gate without using electricity on reddit, but i hope i will be able to understand the differences with the simpler version you plan to make once the game allow your vision to be realized.

[XT-248]

The information is out there for all to piece together.

No, I will not share the idea before testing it.


If people want to start looking or figuring it out for themselves, start with this blog content and the pseudo-code I posted earlier.

Code: Select all

If( SteamFluid < Large_Steam_Number_Here & Nuclear_Reactor_Has_Less_Than_One_Fuel_Cell & Heat_Level < 750 & Time_Since_Last_Inserted > 200 seconds)

Then enable_fuel_cell_inserter_to_move_one_fuel_cell_to_nuclear_reactor

No belt or train since I might use logistic chests only to move fuel cells for nuclear reactors.


As an aside, I have no further desire to talk with someone of such a reputation, who distorts what other people are saying to something other than what it is (see the conversation in the #427 thread).

[mmmPI]

There is no need to read if time passed is superior to 200 seconds, since you can now read the fuel inside the nuclear reactor, you can just read wether or not the fuel is "used " or not.

The pseudo code in the previous post shouldn't be taken as example imo when space age is released because of this as it will unecessarily add a time counter mechanism.

Instead a better way to do would be to check 1° the temperature of the reactor 2° the presence of fuel in the reactor 3° the level of steam.

There is no need to count 200 seconds.

Note that all of this can already be done without using electricity =)

[Stalinlover22]

Can´t wait to play with these QoL changes!!

[XT-248]

If I only look at the steam level and the reactor's fuel is empty, then when both are true, the inserter will immediately grab at least one or more fuel cells until one of the conditions is invalid.

What I want to do is to move only one fuel cell once every 200 seconds. The condition IS there for a good reason, seeing that it takes 200 seconds for a fuel cell to be used-up/exhausted in the nuclear reactor.


By suggesting removing the timer condition, I would have to consider multiple fuel cells' energy content sitting in the reactor to distribute through the heat and steam network once the steam condition is met.

Increasing a nuclear energy plant complex's heat and steam capacity to handle extra fuel cells with a 400% neighborhood bonus is not a trivial change.


Removing the timer condition has a knock-on effect on how I design the nuclear energy complex. I consider the timer condition matter settled.

[Loewchen]

By suggesting removing the timer condition, I would have to consider multiple fuel cells' energy content sitting in the reactor to distribute through the heat and steam network once the steam condition is met.

You can now read if the reactor has fuel and only insert one fuel if it is empty AND the stored heat/steam is below a certain level, so it will never have more than one. There is no need for a timer.

[XT-248]

By suggesting removing the timer condition, I would have to consider multiple fuel cells' energy content sitting in the reactor to distribute through the heat and steam network once the steam condition is met.

You can now read if the reactor has fuel and only insert one fuel if it is empty AND the stored heat/steam is below a certain level, so it will never have more than one. There is no need for a timer.

Yes and no, I plan to have a timer not just limited to preventing an extra fuel cell from being inserted.


I plan to have an infinite scalable 2xN nuclear reactor layout. When I connect more than one reactor to the checker (that checker being if the reactor has less than one fuel), the condition would also have to consider the number of reactors.

IE: Four reactors have four fuel cells (one each). Then, the four reactors burn the four fuel cells until there is no fuel. Then, another fuel cell gets inserted. Only one is inserted in one reactor, leaving three reactors 'cold.'

So, I have to change the condition (< 1) to (< 4). Then I add another 6 reactors and change the condition to (< 10). Etc.


The timer also ensures that all inserters move simultaneously and only move one fuel cell (via the inserter's pickup stack size setting).

The timer is connected to all of the inserters. The timer condition exists to maximize the neighbor bonus and ensure that all reactors are 'hot' at the same timeframe.


Hypothetically, how do I ensure all inserters are synchronized after removing the timer condition?

Hypothetically, how do I have a master signal to stop inserters if it only looks at steam/heat levels that aren't player-controllable? The timer can also double-duty as a high-level signal to 'stop' by staying as '0 seconds' elapsed.

[Loewchen]

I plan to have an infinite scalable 2xN nuclear reactor layout. When I connect more than one reactor to the checker (that checker being if the reactor has less than one fuel), the condition would also have to consider the number of reactors.

IE: Four reactors have four fuel cells (one each). Then, the four reactors burn the four fuel cells until there is no fuel. Then, another fuel cell gets inserted. Only one is inserted in one reactor, leaving three reactors 'cold.'

So, I have to change the condition (< 1) to (< 4). Then I add another 6 reactors and change the condition to (< 10). Etc.

You will lose the neighboring bonus if you don't fuel them all at the same time, staggering them is a waste. Run them all with full bonus, store the energy and then pause all until the heat storage is depleted, way simper and way more efficient.

Hypothetically, how do I ensure all inserters are synchronized after removing the timer condition?

You just need to read one central value of either temperature or steam and they will be synchronized by default.

[Tertius]

Yes and no, I plan to have a timer not just limited to preventing an extra fuel cell from being inserted.

I plan to have an infinite scalable 2xN nuclear reactor layout.

It's an interesting new challenge with the more direct sensors of temperature and fuel content.

Reading fuel is directly replacing the timer. With timer, you insert one fuel and reset the timer by doing it, then count to 12000. After that you know the fuel is empty (if you made sure you just inserted 1 fuel), because the fuel is always burning for 12000 ticks. With reading the fuel, it's a plugin replacement from C>=12000 to F=0 (F=fuel). This is convenience, nothing more.

In contrast, reading temperature is new. To produce some output power, the heat exchangers need some temperature. The higher the required power, the higher the required temperature, so more heat exchangers are active and produce more steam to produce more power.

Usually, power usage isn't spiky but increases slowly and steadily while the factory grows. There is fluctuation, but usually consumption doesn't change from 0 to full and from full to 0.

It seems we're still not able to directly read power consumption, so we're not able to directly relate temperature to power (temperature is proportional to power). We still need some helper able to tell "current power production is higher than consumption" or "current power production is lower than production", so it's still the steam that's telling us this. So, if steam does rise, we're too hot, and if steam does lower, we're too cold.

Until now, steam level vastly varied because of the huge latency between steam threshold transition and re-heating the reactors.

My new approach would be to keep the reactor temperature up, steam level constant, and constantly adjust the desired temperature to keep the desired steam level. If steam level lowers, I would increase the desired reactor temperature by some degree (by how much is yet to be defined), and if steam level rises, I would lower the desired reactor temperature. This must be a somewhat slow process, may be by implementing a PID controller. That's probably much more complex than a simple steam threshold, but much more exact.

Or may be the cheap version of this is just a copy of the old setups with a temperature threshold instead of a steam threshold and may be even require no combinator at all, since the 2 thresholds can be queried directly in the fuel inserter. You need to query fuel <= 0 AND steam <= [steam threshold] with one condition, which can be done by querying EVERYTHING <= 0 and adding -[steam threshold] from a constant combinator, so both thresholds are 0. Needs more steam buffer, since it's not as exact as a PID controller and you need to always use the temperature threshold for full reactor load.

A thing to investigate. My goal would be to build a reactor with as little steam buffer as possible but still wasteless and keeping the reactor under 1000°C all the time.

[XT-248]

I plan to have an infinite scalable 2xN nuclear reactor layout. When I connect more than one reactor to the checker (that checker being if the reactor has less than one fuel), the condition would also have to consider the number of reactors.

IE: Four reactors have four fuel cells (one each). Then, the four reactors burn the four fuel cells until there is no fuel. Then, another fuel cell gets inserted. Only one is inserted in one reactor, leaving three reactors 'cold.'

So, I have to change the condition (< 1) to (< 4). Then I add another 6 reactors and change the condition to (< 10). Etc.

You will lose the neighboring bonus if you don't fuel them all at the same time, staggering them is a waste. Run them all with full bonus, store the energy and then pause all until the heat storage is depleted, way simper and way more efficient.

When I wire all of the reactors, regardless of the number of reactors, to be checked globally on the red or green circuit network. I have to change the conditions manually to match the number of reactors.

It is much easier to set it to less than 1 to ensure that no reactors have any fuel left to burn and never change it from 1 despite adding more 2xN rows of reactors.

If I have to manually change the condition every time I add a new row of 2xN of reactors, there is more chance for something to go wrong.


I don't design it to stagger the fuel intake between reactors. I design it so that all reactors receive a fuel cell simultaneously.

I highlighted a potential problem by using a single "less than one" condition and checking all reactors simultaneously for any fuel remaining globally.

Hypothetically, how do I ensure all inserters are synchronized after removing the timer condition?

You just need to read one central value of either temperature or steam and they will be synchronized by default.

The timer is an external single central signal visible to the logical circuit, and service double-duty as a master-shutdown signal.


Reading only one of either temperature or steam tells part of what is happening and not the whole picture. It is possible to have a reading at a certain temperature level, and the steam level is filled to maximum capacity or empty due to a lengthy period of unusually high energy demand. The same is true of reading only the steam level, not the temperature level.

Yes and no, I plan to have a timer not just limited to preventing an extra fuel cell from being inserted.

I plan to have an infinite scalable 2xN nuclear reactor layout.

It's an interesting new challenge with the more direct sensors of temperature and fuel content.

Reading fuel is directly replacing the timer. With timer, you insert one fuel and reset the timer by doing it, then count to 12000. After that you know the fuel is empty (if you made sure you just inserted 1 fuel), because the fuel is always burning for 12000 ticks. With reading the fuel, it's a plugin replacement from C>=12000 to F=0 (F=fuel). This is convenience, nothing more.

In contrast, reading temperature is new. To produce some output power, the heat exchangers need some temperature. The higher the required power, the higher the required temperature, so more heat exchangers are active and produce more steam to produce more power.

Usually, power usage isn't spiky but increases slowly and steadily while the factory grows. There is fluctuation, but usually consumption doesn't change from 0 to full and from full to 0.

It seems we're still not able to directly read power consumption, so we're not able to directly relate temperature to power (temperature is proportional to power). We still need some helper able to tell "current power production is higher than consumption" or "current power production is lower than production", so it's still the steam that's telling us this. So, if steam does rise, we're too hot, and if steam does lower, we're too cold.

Until now, steam level vastly varied because of the huge latency between steam threshold transition and re-heating the reactors.

My new approach would be to keep the reactor temperature up, steam level constant, and constantly adjust the desired temperature to keep the desired steam level. If steam level lowers, I would increase the desired reactor temperature by some degree (by how much is yet to be defined), and if steam level rises, I would lower the desired reactor temperature. This must be a somewhat slow process, may be by implementing a PID controller. That's probably much more complex than a simple steam threshold, but much more exact.

Or may be the cheap version of this is just a copy of the old setups with a temperature threshold instead of a steam threshold and may be even require no combinator at all, since the 2 thresholds can be queried directly in the fuel inserter. You need to query fuel <= 0 AND steam <= [steam threshold] with one condition, which can be done by querying EVERYTHING <= 0 and adding -[steam threshold] from a constant combinator, so both thresholds are 0. Needs more steam buffer, since it's not as exact as a PID controller and you need to always use the temperature threshold for full reactor load.

A thing to investigate. My goal would be to build a reactor with as little steam buffer as possible but still wasteless and keeping the reactor under 1000°C all the time.

The way I do it now (before reading the temperature or fuel in a reactor) is to read a steam tank then at a certain XX% or YYYY value out of 25k units (connected to all of the steam storage tanks), only insert if the steam level is low enough to have sufficient capacity between reactor and heat exchanger to completely empty/drain everything down to 500-degree heat.

The problem is that I cannot know the current heat level at any given moment. So, I had to overengineer the heat pipe and exchanger to keep up with what a reactor can produce at a 400% neighbor bonus, regardless of the steam tank capacity at that moment.


In the future, I can change the design to be more aware of the temperature, which is not possible currently. Perhaps even start to re-examine how many heat pipes/exchangers I would need for a given 2xN row of reactors.

Then throw in the new, as much as it pains me to say this, simulation-less fluid network, for steam-turbines/pipe/under-ground-pipe/storage-tank/pump/etc.

Now I can check all three values: Timer (external and run without electric power), temperature (seems to be the highest value? as opposite to cumulative?), and fuel reminding (seems to count fuel being consumed as an extra on top of what is sitting in the input slot) to make a smarter nuclear complex.


I will acknowledge that there is a non-zero chance that heat mechanics may play a new role.


I am looking forward ahead to a new generation of nuclear energy designs.

[mmmPI]

By suggesting removing the timer condition, I would have to consider multiple fuel cells' energy content sitting in the reactor to distribute through the heat and steam network once the steam condition is met.

You can now read if the reactor has fuel and only insert one fuel if it is empty AND the stored heat/steam is below a certain level, so it will never have more than one. There is no need for a timer.

Even before any change in the game, it was very easy to synchronize refuel, just wire all inserter to the same steam storage array, there is only one per power plant, and when the steam is "low" it is for all the power plant, therefore all the reactor will be refueled at the same time. That's how the game is played currently, the addition of an easier optionnal system doesn't remove what is already possible to do like 2xN tileable designs ... duh

Hypothetically, how do I ensure all inserters are synchronized after removing the timer condition?

You just need to read one central value of either temperature or steam and they will be synchronized by default.

The timer condition is not necessary.

If you can check if "any" reactor still has some fuel left in an array of 2xN reactor, there is no point in using a timer for waiting 200 second, one just have to wait when there is 0 fuel cell left in reactors. That's a new method added on top of the existing one.

When I wire all of the reactors, regardless of the number of reactors, to be checked globally on the red or green circuit network. I have to change the conditions manually to match the number of reactors.

No, most players would add a constant combinator next to each reactor that add 1 so as to avoid changing manually the number everytime you add new reactors, i had a good laugh when hearing about that x).

[Roxor128]

Will there be some easy way to get bots out of the system for upgrades?

Many mods have multiple tiers of construction and logistics bots, and upgrading them is a huge headache.

Roboports will be able to set min/max requests for specific robots inside them. That way you can make one roboport request all lower tier bots into itself, where they can be removed from the network by inserters.
Funnily enough, they already used this exact example when introducing it.

IMG_2091.jpeg

Wow. I completely forgot about that. I feel very stupid right now...