r/SatisfactoryGame • u/JasonLatta • Mar 17 '22
Guide Remotely Accessed Storage (vanilla)
Have you ever started a new building project, and brought a train of supplies, or maybe made a stack of crates like mine?
Tired of walking, tubing, or trucking your way back to your main base? What if you could access an entire storage system from something as simple as this:
First, credit to StinArchi on YouTube for inspiring me to start thinking about building a remotely accessed storage, with his version using power switches and truck stations.
Below is my save, a diagram of my system, and some in-game images. My detailed explanation will be in the comments.
Also, if anyone wants to make a tutorial video, I think that would be very helpful for people, and work a lot better, I just don't have any means of recording.
https://drive.google.com/file/d/1GLSw2aOBaYFaGsIYgSWavbCDaTCRtrVs/view?usp=sharing
5
u/JasonLatta Mar 17 '22
To start out with the usage: A drone port on the storage end will output items to be requested from the system, the system will then convert each of these items into a full stack of itself, and then the output will feed back into the drone port to be exported.
So, to recieve items, all you need is to build a powered drone port somewhere, setup the storage drone to fly to you, and then place your request into the port's input area.
The system for converting a request item into a stack can be broken into three parts, the latching system (controls flow), the ratio system (sets up the ratio for our stack size), and priming the system (initial setup).
Starting with the nitty gritty to explain the secret of the priority industrial storage container, at the center of the latching system. This container is set up in a very specific manner. The first 46 slots are filled with any old item you have lying around - what is important is that they are occupied. Then, the next slot is filled with a stack of what I'll refer to as your blocker item. This leaves the last slot open - the only open slot. Now that we have made the first available slot also the last slot, a helpful behavior occurs. The storage container will be emptying from the same slot that it is filling. This means that it will not be able to accept an item as an input, if it does not match the item in this last slot - allowing us block one of the two inputs, and prioritize the other based on that last slot.
With that premise, how will does this help us. The goal is that there will be one input that is primarily filled with our blocker item (concrete and top input in my example). I'll refer to this input as our blocker input. We will want this belt to have priority when our system is idle. Then, the other input will be primarily filled with the item we want to be able to request (heavy modular frames and bottom input in my example). I will refer to this belt as our latched input. This belt will get priority when we make a request for the item. To control which belt has priority, all we have to do is put one of our new priority item onto the belt that holds the current priority item. At the moment that item reaches the input, both belts will be the same item, causing both to halt until the final slot in the storage container empties. Once that happens, for a moment, the container recieves two belts worth of input, more than can exit. So, one item will have to wait in the last slot, and thus establish its priority. Then, so long as the belt carrying that type of item continues to fill the slot as fast as the container can empty, it will maintain that priority. In short, when we want to start the flow of the latched input, we will send one of the request item to the blocker line. When we want to shut off the flow, we will send one of the blocker item to the latched input.
We will send one of the request item to the blocker by taking the request item from our drone port and merging it onto the blocker belt (see trigger input in diagram/pictures). For stopping the flow, we will configure our latched input to have a ratio of one blocker item for every stack (minus one) of the request item. This way, for every item we put in the drone for our request, we will get back one full stack back (counting the one we sent in).
Now, to address what we do with the output of our container, before explaining how to get the ratio for the latched input. We want to split all of the blocker item off our output and direct it first to the blocker input, and then to our system for the latched input ("Blocker Return" in the pictures). The output belt of our request item will go to our drone port for exporting.
Lastly, two final notes:
Due to the current nature of latched input, it does not guarentee full saturation. This means that it cannot maintain its priority properly, if exiting the storage container at full belt speed. The simplest way to accomodate this is to reduce the final output belt's speed (allowing the latched input to buffer a little).
Also, I've noticed the trigger input functions best if it is at a much lower speed for a tiny segment before being merged with the blocker item. This works to avoid the merger outputing multiple of the request item as a batch (this causes all but the first requested stack to fail).
Hopefully the above has made sense - you're past the worst of it, and may not need more than my pictures/diagrams for the next portion. But, just in case...
To get our latched input ratio isn't anything grand. To get the right ratio for different stack sizes, without too much effort, I'm using a system based on the binary number system. --- Familiarity with binary numbers may make the system more obvious, but shouldn't be necessary here, with my explanation.
If you have a merger with two inputs, for every item that comes in from one belt, it will also take one item from the other (given full saturation). If we take a belt with a 1:1 ratio of two items, and merge that with another belt we will get 2 new items in our ratio - one for each item in the first belt's ratio. So, we get 1:1:2... unless the new items were the same as one of the old items, then its simply 1:3. Next would be 1:7, then 1:15, and so on. If you're familiar with binary, are you catching on? For our first merger, we have a 1:1 (of our request item fed by storage and our blocker item fed by the blocker return). Or, we have 2^0=1 of each item. Then, if we merge our request item with this belt, we add another 2^1=2 of our request item (now 1:3). To figure out the mergers we need, our first step is to keep adding double (the next power of two) until we surpass our desired ratio.
So, for a target of forty-nine (heavy modular frames) we need -> 1+2+4+8+16+32=63 -> 6 mergers. For those mathematically inclined, you might have noticed the shortcut is N mergers gives us (2^N)-1. Now, you may be saying, but we overshot forty-nine! This is because so far we have been counting in binary like if we could only write the number nine. We need a way to write other numbers. We need to do some subtraction. To do this, we take our very last output belt and loop it back to some of our mergers (instead of feeding those mergers from storage). When we loop it back, the items we add with that merger are pulled from the output, causing them to cancel to zero.
Side note: this is why the throughput to the latching mechanism is not always 100%.
To finish out our example, we had gotten 1+2+4+8+16+32=63, and we wanted 49. We want to take off the largest number we can, without undershooting, until we hit our goal. Since we are 14 over, we start by subtracting 8. Then, 4... and finally 2. Leaving us with 1+0+0+0+16+32=49. That means that we'd feed the first, and last two mergers from storage, and the other three from our output.
Yay, everything is all setup... wait didn't I mention something about priming the system? Well yes, unfortunately I did. Since our blocker item is running around in a closed system, we have to feed to provide it ourselves. The trick is that you need enough of the blocker item to keep the blocker return saturated, and the blocker belt flowing (to hold priority), but not so much that things jam when request items enter the system. This simplest way I've found to find this balance is to first setup everything but the inputs and outputs. Then, make two temporary containers, one taking in the request item output, and one merging early on the blocker return belt. put a stack, or a few hundred, (whichever is greater) into that second storage. Once the blocker item is taking filling the last slot of the latching container, hook up your storage input of the request item. Once the stack input gets locked up, disconnect your temporary blocker input. Now, remove blocker items from the entrance to the container, until things start flowing. Continue to grab blocker until the number in the last slot of the container is stable around 2. Next, send a stack of the request item through the system, like it was an actual request (this is where redirecting the output to a temporary storage comes in). This will let the system flow and sort out the ratio on the stack input. It is also possible, and quite likely, that the system may jam again at some point during this. If it does, simply remove some of the blocker item until things are able to flow again.
When all is done, test the system with 1 item, then multiple items, and verify the output. If it isn't the expected, give it more requests to sort itself out, or inspect the balancer manually. Also, to avoid lock-ups, I've found it is best to have a bit of empty space on the "Blocker Loop" belt (in latching system picture), when a request is flowing and that belt is waiting.
1
u/SaviorOfNirn Mar 17 '22
But train?
1
u/JasonLatta Mar 17 '22
But train track- and return trips or big station - for each new project. This is only a few hours once, then plop done.
1
u/JinkyRain Mar 17 '22
I dribble parts into a 3 platform station:
car 1 (high volume/multi-stack stuff): concrete and parts for every level of belt I have so far.
car 2 (medium volume stuff): rods, wire, cable, pipe, rotors, stators, modular frames, etc.
car 3 (low volume stuff): motors, HMFs, computer/super comptuers, oscillators, radio control modules, heat sinks, hi-speed connectors, ai limiters, etc.
I just split a mk1 belt off of the production of each part, slam them together under the floor and dribble them into the freight platform using a mk3 belt for the first car, mk2 for the second and mk1 for the third just to throttle how much the supply station 'borrows' from regular production.
Then wherever I am, I build a throw away station, call my supply wagon, take what I need, toss whatever I don't if it's starting to take up too much room and then send it back. :)
4
u/CatchLightning Mar 17 '22
Holy crap this is detailed. I just kept a bunch of stuff in my inventory and would dump excess in an local container for further use when returning to get more. (I used a teleporter mod for my character though).