, computers.
Yes, this is modded. Prior to my coming to the forums to see what other station balancers are out there, I came up with my own version based on modded Factorio. I've put just about 178 hours into this particular map, and is a brand new map for 0.15. I'm learning the new blueprint system (Which is frig'n fantastic) and starting to dig into the combinator system. So part of what I'm doing with this process is coming up with blueprints for outposts and delivery stations that can be stamped with minimal modifications to get them to run, PLUS, built in safeties so the delivery stations don't start making requests for trains until I set a particular variable in the deciders.
Relevant Mods used:
- Loader Redux
- Warehousing
- Logistic Trains (*)
- The FAT Controller
Problems to be fixed
I've been getting to the point where I'm starting to take into consideration a large input of materials for processing, which means many receiving stations, and who knows how many remote collection stations. However, with Vanilla, I was having problems controlling trains showing up with a mix of products on board, clogging up my system. So first, I broke down and started making multiple loader and unloader stations dedicated to just one particular type of ore. I then ran into the problem of managing which trains go to which station, which is where Logistic Trains come into play. (I love that mod so much that if it never is upgraded, I might just not want to play Factorio anymore!!!)
So once I had the trains under control and fully automated by LTN, I found that trains would be sitting in a delivery station that were just waiting to unload 1 of the 3 cargo wagons, thereby bunging up the unloading speed. So I had to come up with a way to better balance the offloading station. Which will be the first set of pics.
Now that I had an efficient unloading station, I started to find that some trains were hanging around at stations waiting for (again) 1 of 3 cargo wagons to load up, and then I'd get alarms from FAT that trains were taking way too much time. Then, LTN would force the train home with a partial load, then send it off to yet another station to pick up a DIFFERENT resource, which, yet again, would bung up the system.
So what I needed was a method to not only keep the stations at both ends of resource collection balanced, but, also leave room for those situations where I can always guarantee that a train could unload its entire load, which meant NOT having the unloading station at 100% full at any time.
So once I had the trains under control and fully automated by LTN, I found that trains would be sitting in a delivery station that were just waiting to unload 1 of the 3 cargo wagons, thereby bunging up the unloading speed. So I had to come up with a way to better balance the offloading station. Which will be the first set of pics.
Now that I had an efficient unloading station, I started to find that some trains were hanging around at stations waiting for (again) 1 of 3 cargo wagons to load up, and then I'd get alarms from FAT that trains were taking way too much time. Then, LTN would force the train home with a partial load, then send it off to yet another station to pick up a DIFFERENT resource, which, yet again, would bung up the system.
So what I needed was a method to not only keep the stations at both ends of resource collection balanced, but, also leave room for those situations where I can always guarantee that a train could unload its entire load, which meant NOT having the unloading station at 100% full at any time.
Rules
So what the builds are;Part of the solution was coming up with a few rules that the stations had to abide by.
The first rule was that any of the cargo trains I shipped out were E-CCC format. Single engine, 3 cargo cars. With Rocket Fuel on board and loaded while waiting at the depot, this was enough to keep the trains time away from the depot short enough.
Second rule was that the unloading stations must always have enough room to unload at least one full train before making a request for another train.
Third rule was that both the loading and unloading stations must be balanced to a degree. For instance, if the loading station ended up having one of the feeds of materials coming in abruptly stop, the other two warehouses had to somehow offload extra stuff into the third warehouse.
Fourth rule was that each loading and unloading station could only support exactly ONE ore. So that meant that whatever balancing circuit I made must be placed in a state that would not allow trains to be called, as the station may not be hooked to the rest of the train network yet, as well as be "generic" enough so that I can set one variable in the circuit to start the requests.
The first rule was that any of the cargo trains I shipped out were E-CCC format. Single engine, 3 cargo cars. With Rocket Fuel on board and loaded while waiting at the depot, this was enough to keep the trains time away from the depot short enough.
Second rule was that the unloading stations must always have enough room to unload at least one full train before making a request for another train.
Third rule was that both the loading and unloading stations must be balanced to a degree. For instance, if the loading station ended up having one of the feeds of materials coming in abruptly stop, the other two warehouses had to somehow offload extra stuff into the third warehouse.
Fourth rule was that each loading and unloading station could only support exactly ONE ore. So that meant that whatever balancing circuit I made must be placed in a state that would not allow trains to be called, as the station may not be hooked to the rest of the train network yet, as well as be "generic" enough so that I can set one variable in the circuit to start the requests.
Images
The first image is a line chart showing the pathing for the two networks that makes this work. The first network I'll describe is the balancing network.Balancing Acts
Starting from the warehouses, there are red network cables going to the first arithmetic combinators, each. These are independent networks for each warehouse to get a count of items. Below the top most warehouse, there is a constant combinator. This holds the "multiplier" value (Gray signal) that tells the network that the warehouses should all be balanced within a certain amount of whatever items happen to be in them. I stamp at Gray being 100, but, I've got a couple unloaders set to 1000, or 6000. Depends on my mood. Each of the arithmetic divides the "each item" count by whatever the Gray value is. Consider this division the resolution of how close each warehouse should be within of each other. The outputs of Red, Green, and Blue signals become the values we compare next. The smaller the number the Gray signal is, the more equal the amount each warehouse has. It is NOT recommended to set to anything less than 100 as some items end up on the belts, get fed in, then upsets the balance. 50 might be pushing it, but 100 is fine.
From there, I link to the decider combinators. From top to bottom, we compare red to green, then green to blue, then blue to red. Always testing for GREATER THAN left to right values. Outputs are sent via the yellow wire in the image (In-game on red wires).
The decider combinators turn on the "0", "1" or "2" signals depending on their conditions, and outputs either nothing or 1 (False or True) on the purple line to the connected belts. The belts conditions to run are set when the output of the connected decider is 1. I could have set the output to be one of any signal type, but, I decided to output each as a unique value.
So what the effect here is if the top (Call it the Red warehouse) has more items than the Green warehouse, this circuit will turn on the belt next to the Red warehouse to start unloading to the Green warehouse. Since we're testing for GREATER THAN only conditions, when the Red and Green warehouses are of equal resolution (based on that Gray value sent by the constant combinator), the belt gets turned off. Same things happens when comparing Green to Blue, then Blue to Red.
The benefit of this is that the Green warehouse is pretty much constantly emptying, as off screen I have that middle belt splitting its feed of materials to two different belts. Also, as mentioned, if I set the value of that constant combinators gray value to a bigger number (less resolution), I save on UPS (Maybe?) since the belts aren't being loaded until absolutely required.
Now, today, I made some kind of mistake earlier and removed the power from one of these combinators connected to one of the warehouses. I didn't notice for a while until I started writing this up. Once I corrected it, the system started working and balancing itself out as expected. Since the balance system works with only a single in/out belt, it took some time. The amount of items were low enough between the three warehouses that trains were being requested and there are 6 off loaders from trains, so the one low amount warehouse was slow to catch up, but, it did. Kinda cool to watch it work.
From there, I link to the decider combinators. From top to bottom, we compare red to green, then green to blue, then blue to red. Always testing for GREATER THAN left to right values. Outputs are sent via the yellow wire in the image (In-game on red wires).
The decider combinators turn on the "0", "1" or "2" signals depending on their conditions, and outputs either nothing or 1 (False or True) on the purple line to the connected belts. The belts conditions to run are set when the output of the connected decider is 1. I could have set the output to be one of any signal type, but, I decided to output each as a unique value.
So what the effect here is if the top (Call it the Red warehouse) has more items than the Green warehouse, this circuit will turn on the belt next to the Red warehouse to start unloading to the Green warehouse. Since we're testing for GREATER THAN only conditions, when the Red and Green warehouses are of equal resolution (based on that Gray value sent by the constant combinator), the belt gets turned off. Same things happens when comparing Green to Blue, then Blue to Red.
The benefit of this is that the Green warehouse is pretty much constantly emptying, as off screen I have that middle belt splitting its feed of materials to two different belts. Also, as mentioned, if I set the value of that constant combinators gray value to a bigger number (less resolution), I save on UPS (Maybe?) since the belts aren't being loaded until absolutely required.
Now, today, I made some kind of mistake earlier and removed the power from one of these combinators connected to one of the warehouses. I didn't notice for a while until I started writing this up. Once I corrected it, the system started working and balancing itself out as expected. Since the balance system works with only a single in/out belt, it took some time. The amount of items were low enough between the three warehouses that trains were being requested and there are 6 off loaders from trains, so the one low amount warehouse was slow to catch up, but, it did. Kinda cool to watch it work.
Calling All Trains
So the Logistic Train portion of this involves some math. I'll "English-ize" it, so the concept is there.
Given this image, and assuming its hooked to the warehouses and the LTN signal, there is a wire going between the three warehouses (Green wire) to the input (Yellow Star - "Each Item"). Whatever this Star give is divided by -6000 (Yes, a Negative. 6k represents the maximum amount of ore a 3 car train can haul) and outputs its answer to the T (# of Trains) signal. What this does is gives me a value that tells me how many train loads it is going to take to fill the warehouses to max capacity. For these warehouses, at full capacity, that'd be exactly 20 train loads required to fill to the brim.
The constant combinator (M for Max Trains) contains a positive number to tell me how many trains I want to ever service this station. I stamp this with M as +17. This means that I will always have room to fill at least 3 trains worth of stuff into the warehouses. With the distance the trains are starting to travel, I found that sometimes a lagger would end up showing up and end up waiting to unload their wares. Since I want the unloading speed to be paramount, I want an Empty Buffer that will allow for these laggers to unload their entire cargo load without waiting for room. (Which goes back to the importance of the "Balancing Act" section)
The next step is to output the maximum number of trains I need to request materials for. Input is [ M + T = Q ]. Q is the maximum Queue of trains to be called for. As the warehouses fill up, Q will start to decrease, meaning fewer trains need to be called to this station.
The next step is to take the Q value and multiply it by another -6000, and outputs the value as R (Result). What this will do is tell the Logistic Trains that there is at least a full trains worth of cargo to be requested. If there isn't room for 6000 ore, don't bother even broadcasting that there is something available. The Logistics Trains work in the way that if a station is asking for a NEGATIVE amount of items, it is asking for items to be delivered to this station. If there is a POSITIVE amount of items, it is telling the Logistic Trains that there are items to be picked up. This second scenario is something I do not want at a delivery station so, the next step....
.... is a comparitor that is testing to see if R is less than zero, and if so, output R. If there is ever a chance that there is enough ore for another train to pick up items, this station doesn't broadcast it for a Logistic Train to come and pick up items. This fixes the problem of the second scenario mentioned above.
And the last step, is we take the value of R and turn it into a Black signal. Why a black signal? Well, this is the safety switch that prevents the Logistic Trains to start making stops at this station, and is the only change needed to get this entire station to start working. The reasons are, first, a train cannot pick up Black Signals, so the trains are never are called to this station. Second, depending on what the warehouses are holding (Since one of the rules is that they can only contain one particular ore) I must indicate WHAT this station wants to receive. Third, if the station isn't 100% completed for not only deliveries, or isn't hooked into the rest of the rail network yet, or, I'm preparing to retire this station, or where these ores are going to be processed isn't fully functional yet, I'm not making requests and then having LTN complain that a train can't get to a destination. Once I set that Black signal to a particular ore, LTN wakes up and starts requesting trains to this station.
On a side note about LTN, the train stop itself is stamped to be configured for a single engine (1) and 3 cargo (14) train, and will only request a maximum of 4 trains at once. So even though Q says it is requesting 17 trains to service this station, the station itself will only have four requests out for trains.
Blueprint Strings:
So the Logistic Train portion of this involves some math. I'll "English-ize" it, so the concept is there.
Given this image, and assuming its hooked to the warehouses and the LTN signal, there is a wire going between the three warehouses (Green wire) to the input (Yellow Star - "Each Item"). Whatever this Star give is divided by -6000 (Yes, a Negative. 6k represents the maximum amount of ore a 3 car train can haul) and outputs its answer to the T (# of Trains) signal. What this does is gives me a value that tells me how many train loads it is going to take to fill the warehouses to max capacity. For these warehouses, at full capacity, that'd be exactly 20 train loads required to fill to the brim.
The constant combinator (M for Max Trains) contains a positive number to tell me how many trains I want to ever service this station. I stamp this with M as +17. This means that I will always have room to fill at least 3 trains worth of stuff into the warehouses. With the distance the trains are starting to travel, I found that sometimes a lagger would end up showing up and end up waiting to unload their wares. Since I want the unloading speed to be paramount, I want an Empty Buffer that will allow for these laggers to unload their entire cargo load without waiting for room. (Which goes back to the importance of the "Balancing Act" section)
The next step is to output the maximum number of trains I need to request materials for. Input is [ M + T = Q ]. Q is the maximum Queue of trains to be called for. As the warehouses fill up, Q will start to decrease, meaning fewer trains need to be called to this station.
The next step is to take the Q value and multiply it by another -6000, and outputs the value as R (Result). What this will do is tell the Logistic Trains that there is at least a full trains worth of cargo to be requested. If there isn't room for 6000 ore, don't bother even broadcasting that there is something available. The Logistics Trains work in the way that if a station is asking for a NEGATIVE amount of items, it is asking for items to be delivered to this station. If there is a POSITIVE amount of items, it is telling the Logistic Trains that there are items to be picked up. This second scenario is something I do not want at a delivery station so, the next step....
.... is a comparitor that is testing to see if R is less than zero, and if so, output R. If there is ever a chance that there is enough ore for another train to pick up items, this station doesn't broadcast it for a Logistic Train to come and pick up items. This fixes the problem of the second scenario mentioned above.
And the last step, is we take the value of R and turn it into a Black signal. Why a black signal? Well, this is the safety switch that prevents the Logistic Trains to start making stops at this station, and is the only change needed to get this entire station to start working. The reasons are, first, a train cannot pick up Black Signals, so the trains are never are called to this station. Second, depending on what the warehouses are holding (Since one of the rules is that they can only contain one particular ore) I must indicate WHAT this station wants to receive. Third, if the station isn't 100% completed for not only deliveries, or isn't hooked into the rest of the rail network yet, or, I'm preparing to retire this station, or where these ores are going to be processed isn't fully functional yet, I'm not making requests and then having LTN complain that a train can't get to a destination. Once I set that Black signal to a particular ore, LTN wakes up and starts requesting trains to this station.
On a side note about LTN, the train stop itself is stamped to be configured for a single engine (1) and 3 cargo (14) train, and will only request a maximum of 4 trains at once. So even though Q says it is requesting 17 trains to service this station, the station itself will only have four requests out for trains.
LTN Network Combinators
I'll update this post with the warehouse setup string if anyone is interested.0eNrFllFvmzAQx79KdY+bWQMB2qF9hPWh6d6qChm4LKeBzYyJGkV899lmyujSrDidlJdIZ87/u/udffEeirrHVpHQkO2BSik6yB730NF3wWu7pnctQgaksQEGgjfW4or0pkFNZVDKpiDBtVQwMCBR4TNk4fDEAIUmTTgKOmOXi74pUBmHg5QNqbnQUyEGrezMXilsBs/OfQdZEJoIFSksx08xs7u1knVe4IZvyWw1/muqNaoTdWxJ6d6sHOKPHsGdzb6UvQUR3kwLcetCjEE7KxXaH4XVtDAyVmo8SZU9aWfavcPAjmqP3sB4VH0QufIXn5JZ9f9Rzc3nig55r0l1Op+NZDUiGdtjwjOQLSo+xoaPxl/2uu09FIualz/AQpmLNH6JNDqBdOmLdHERovcviQbpYvEX1Q9nUF15EU2PiTKI5uE/daLjQ0oVllSh+vdxDr3g/5b832fZZNhy5TLM4Mt52K1Ku8vd2MjXSjY5CaMBmVY9evRk6dOTaF5PEt8rcZkhg7zcvHkrrs9oz7dXb0X0vtGd+kINLwLV/Zl1aDW8gL1/wt97zaJwgtjaic89WL7WMvPscC+VbPKwYVDzAk328KDF1Qp/Xn2lxnjZdm3NQ8FVm8ZxlESfk9ubaBh+AQ+zHgo=
This is my first multi-purpose real combinator setup. With LTN, I always make sure that my off loading stations are at the capacity I require.
---
(*) Logistic Trains isn't absolutely necessary. I know that with Vanilla (now) that I can prevent trains going to a particular station so you can copy/paste schedules between trains, but, it becomes a pain when you're dealing with 20 trains.
