Jamming more signals into your signals so you can signal more while you signal
Posted: Mon Sep 17, 2018 9:36 pm
I'm sure someone smarter already came up with this before, but for what it is worth, here's my take on getting more signals to do more things to be able to debug more often. I come from era where bit flag arrays stored in integers were still a thing, since then I've had a soft spot for bit manipulation.
Optional TL:DR backstory on the end ...
There are 4 signals: (A), (B), (C) and (D), they represent resource requests as trainloads, since none of these will ever go over 255, we could jam them all into single signal, then get them back out on the other side. that way we can use single signal to send requests for 4 different resources, and still know how many trainloads it'll take, so we can dispatch more than one train if need be.
The signals are 32 bit signed integer, so we can jam 4 signals that are 8 bits into single signal, and with some trickery at the end, we can have 4 - 0-255 unsigned signals on the other end, all 4 transmitted by using only single signal. Or in another words, take care of two resources on both supply and receiving ends using single signal.
Multiplexing the signals on sending end is dead easy, just take number smaller than 256 and bit-shift it right by specific number of bits, 0 for first, 8 for second, 16 for third and 24 for last, then send them out all as single signal.
De-multiplexing on the other end is just little more complicated, we start with the highest 8 bits, shift them left by 24, that gives us value of the fourth signal, we take that value, shift it right by 24 bits, and subtract the result from the main signal, that gives us first three signals without the fourth. Then we just repeat the steps shifting backwards by appropriate amount of bits to get the remaining signals.
Last bit of trickery is to convert signal (D) from signed to unsigned. If the result for signal (D) is negative, add 256, and we done.
To use the blueprint you will need Justarandomgeek's awesome Nixie Tubes, one of the mods i can't do without, thanks geek! :)
---
The next logical step would be to throw away the need for knowing how many train loads are available or requested, and use single signal as 32 flags, to track supply and requests of 16 resources at once :)
But why?:
I tend to use single large signal network for my trains that holds amount of available resources and requests for the same across the whole map, so when request comes in for load of iron ore, signal (1) increases by 1, and appropriate train station is enabled. Whichever train in the train yard, that has a load of iron ore is the closest takes off, and delivers the ore. Then it goes past nearest iron ore mine that has enough ore to fill it and refills it self, then it goes back to train yard. All this takes two signals, one is (1) and the other is (iron ore), so now I'm using two signals to manage offers and requests for single resource.
This works fine as long as you don't come up with the moronic idea where you want a factory where no more than single step in production will be done, without the results traveling by a train. This is precisely what I'm doing right now. I have few choices, i could break up the large signal network to smaller parts, but that is no fun. I like to eat my cake and keep it too. So i decided to complicate the hell out of everything, and this is the result.
Optional TL:DR backstory on the end ...
There are 4 signals: (A), (B), (C) and (D), they represent resource requests as trainloads, since none of these will ever go over 255, we could jam them all into single signal, then get them back out on the other side. that way we can use single signal to send requests for 4 different resources, and still know how many trainloads it'll take, so we can dispatch more than one train if need be.
The signals are 32 bit signed integer, so we can jam 4 signals that are 8 bits into single signal, and with some trickery at the end, we can have 4 - 0-255 unsigned signals on the other end, all 4 transmitted by using only single signal. Or in another words, take care of two resources on both supply and receiving ends using single signal.
Multiplexing the signals on sending end is dead easy, just take number smaller than 256 and bit-shift it right by specific number of bits, 0 for first, 8 for second, 16 for third and 24 for last, then send them out all as single signal.
De-multiplexing on the other end is just little more complicated, we start with the highest 8 bits, shift them left by 24, that gives us value of the fourth signal, we take that value, shift it right by 24 bits, and subtract the result from the main signal, that gives us first three signals without the fourth. Then we just repeat the steps shifting backwards by appropriate amount of bits to get the remaining signals.
Last bit of trickery is to convert signal (D) from signed to unsigned. If the result for signal (D) is negative, add 256, and we done.
To use the blueprint you will need Justarandomgeek's awesome Nixie Tubes, one of the mods i can't do without, thanks geek! :)
---
The next logical step would be to throw away the need for knowing how many train loads are available or requested, and use single signal as 32 flags, to track supply and requests of 16 resources at once :)
But why?:
I tend to use single large signal network for my trains that holds amount of available resources and requests for the same across the whole map, so when request comes in for load of iron ore, signal (1) increases by 1, and appropriate train station is enabled. Whichever train in the train yard, that has a load of iron ore is the closest takes off, and delivers the ore. Then it goes past nearest iron ore mine that has enough ore to fill it and refills it self, then it goes back to train yard. All this takes two signals, one is (1) and the other is (iron ore), so now I'm using two signals to manage offers and requests for single resource.
This works fine as long as you don't come up with the moronic idea where you want a factory where no more than single step in production will be done, without the results traveling by a train. This is precisely what I'm doing right now. I have few choices, i could break up the large signal network to smaller parts, but that is no fun. I like to eat my cake and keep it too. So i decided to complicate the hell out of everything, and this is the result.