While designing my base I started running into the problem that I an outpost died of recource depletion and I didn't really notice it until by chance I spotted one of it's trains coming in empty to the unload station. Therefore I build a little status reporter and a status display which is easy to implement to each outpost without a lot of configuration work to be done.
In the case shown here I'm having each outpost report three statuses:
1) Outpost is connected (green signal)
2) Outpost buffer storage has contents (yellow signal)
3) Outpost buffer storage is empty, effectively just the opposite of the second signal right now (red signal)
First of all I had to wire up my whole rail network with green wire to transmit a combined status signal of each outpost back to the main base.
Second I have a status reporter which is located in each outpost:
Status sender
Status sender blueprint string
When setting up an outpost I set blue signal on the combinator to the ID that the outpost is supposed to have. That signal is actually not supposed to leave the outpost. Keep in mind that the Id must be a power of 2. Meaning one of the set of 1, 2, 4, 8, 16, 32, etc up to 2^30.the decider marked with yellow lines is just a helper so I don't have to touch the walled in set of combinators. It sends A=1 into the local outpost circuit when I want the yellow signal to be true.
The walled in combinators are responsible to to transform the status for transportation into the green wire network connecting everything (the rail-wire).
The ones marked in green there will transform the condition in A into the yellow and red signals respectively.
As the green signal is only used as a connection check I default it to 1 with a constant combinator
The arithmetic combinator muliplies these with the blue signal (the Id) of the outpost.
The set of decider combinators on the left then only makes sure that only the red, green and yellow signals get put onto the rail wire.
By that I can reuse the same blueprint for up to 30 outposts with only configuring two combinators and nothing more.
Now for the display module:
Status display
Status display blueprint string
Status display detail
I'm using a variation of the binary decoder developed by Hanziq and demonstrated by Xeteth in his Name display build.
The rail-wire comes in from the left.
Each line represents an outpost. First line is Id = 1, second line is Id = 2, third line is Id = 4, etc. This is what the combinators on the leftmost column are responsible for. Each combinator takes the result of the previous line and multiplies it by 2, with the exception of the first which gets fixed to 1. All the lines are equal concerning the setup of the combinators.
It might not be noticable in the screenshots but each of the first column combinators is connected with a red wire to the input of the next combinator in the COLUMN and to input of the next combinator in the ROW. However as I've read in the friday facts that's display issue supposed to get fixed.
The second column gets as input the each of it's row's red wire from the first column and the complete green signal from the rail-wire.
Columns 2 to 6 are basically Hanziq's binary decoder with the modification of columns 4 and 6 which are there to equalize the latency times of the signals. In the end the decider combinator normalizes all incoming signals (red, green, yellow in this case) to either 1 or 0.
Connections summed up:
Rail-wire connects to ALL C2-inputs
Column 1 output connects red to Column 2 input in the same row and red to Column 1 in the next row
Column 2 output connects red to Column 4 input and green to Column 3 input
Column 3 output connects red to Column 5 input
Column 4 output connects red to Column 6 input
Column 5 output connects red to decider input
Column 6 output connects red to decider input.
Status sender lamps detail
The lamps simply light up on each decoded signal. The smart chests are just there so that I can see what the outpost is supposed to deliver.
If the first lamp is off that means that outpost is not connected either because it is not built or because the power line to it has been severed. An outpost which has something in it's smart chest without the first lamp on is most likely an issue that needs investigation
If the second lamp is off it means that the storage is empty. Unless the outpost is mined out completely it will start flickering between the second and the third lamp.
If the third lamp stays on without flickering from time to time that means the storage in the outpost is empty AND gets no longer filled. Meaning the outpost is dead.
What each signal means can be defined by each outpost itself. You are not even limited to those three signals, you simply could add more without changing anything to the decoder logic (what I'm looking for is a reliable detector for the information "train is in station").
Another thing I'd like to fix is the flickering if the outpost is not dead but dieing. I'd build a timer into the sender module but that's not yet completed.
As I said beforehand one set of signals can support up to 30 outposts however you can also have several outposts with the same Ids provided they DO NOT share the same status signals.
PS:
While analyzing that build to bring it to here I even noticed that the decider in Column 7 is not actually necessary since I could just combine the outputs of C5 and C6 into the lamps directly, however the decider gives me a mouse-hover-point where I can check the intermediate results of the calculation which the lamps don't. Therefore I decided to leave it in.
PPS:
Even though the blueprint still has 31 lines I'm not sure if the calculations in the 31st line can be performed correctly in the display module, actually I'm even expecting problems because of the datatype (signed Int32). Therefore I've been referring to a maximum of 30 outposts that can be serviced.
