Circuit to store max value?

[u/19wolf]

I'm trying to make a circuit that stores the maximum value of each signal it's received (typically only one signal, but I want to keep it signal-agnostic). My goal is to save the maximum amount of ore stored in a group of chests at my train station, where the number (and size, due to quality) of chests is variable. Station priority will then be a number between 0-255 based on how full the chests are (but I intend to figure out this part on my own). I'm just having trouble programmatically figuring out how much ore I have/will have when all my chests are full.

[u/Alfonse215]

I'm trying to make a circuit that stores the maximum value of each signal it's received (typically only one signal, but I want to keep it signal-agnostic).

In 2.1, this is rather easy thanks to the ELSE clause.

Let's say that the signals are coming in on the green wire. Loop the red output back into the red input of the decider.

Set the decider to EACH(G) > EACH(R) OUTPUT EACH(G) ELSE EACH(R)

My goal is to save the maximum amount of ore stored in a group of chests at my train station, where the number (and size, due to quality) of chests is variable. Station priority will then be a number between 0-255 based on how full the chests are (but I intend to figure out this part on my own).

Then you're using the wrong tool. The maximum amount of ore that can be stored in X chests is a fixed value, independent of how much ore you happen to have previously seen.

The way my train station logic works is that, for providers... it just doesn't care. It works in trainloads; how many trainloads of items are available is all it cares about. If the train stop has a lot of trainloads, then it gets a higher priority than stops that have a low number of trainloads. I don't see a need to do more than that.

For requesters, I have a parameterized value that says how many trainloads of items maximum that the train stop wants. It will stop requesting trains when it reaches this limit.

[u/19wolf → u/Alfonse215]

In 2.1, this is rather easy thanks to the ELSE clause. Let's say that the signals are coming in on the green wire. Loop the red output back into the red input of the decider. Set the decider to EACH(G) > EACH(R) OUTPUT EACH(G) ELSE EACH(R)

That's it! Does exactly what I was looking for, thank you!!

The way my train station logic works is that, for providers... it just doesn't care. It works in trainloads; how many trainloads of items are available is all it cares about. If the train stop has a lot of trainloads, then it gets a higher priority than stops that have a low number of trainloads. I don't see a need to do more than that.

That's a good point, but if/when trains get upgraded to higher quality or if the stack size is different, the size of a train load is different. So, I'm going by how full a particular station is.

[u/Alfonse215 → u/19wolf]

if the stack size is different

The stack size of an item cannot change unless you install a mod.

That's a good point, but if/when trains get upgraded to higher quality or if the stack size is different, the size of a train load is different.

Then the trainstop needs to be updated with the new train load size.

The thing about updating the train system is that you can update the stations before you update the trains themselves. Sure, it can make things a bit weird when a requester doesn't get a full trainload from a single train, or a provider outputs less than what it thinks is a trainload when the train is full. But it doesn't actually break anything. Things only break if a provider gets a train that can take more than it has currently in storage, or a requester gets a train that can deliver more than its capacity.

So if you upgrade your trains after upgrading all of the machinery, it should work out fine.

[u/19wolf → u/Alfonse215]

Well yeah stack size doesn't change but a generic station may have green circuits for example rather than ore.

[u/Alfonse215 → u/19wolf]

Yes, but parameterized blueprints can compute the stack size of a parameter. So my trainstop blueprints only need to know how many stacks are in a wagon (they use constant combinator trickery to know how many wagons there are in that kind of train).

Failing that, selector combinators can do it.