Feature Request - Having multiple Stations work as one

[bldy]

This is an amazing mod.

I am currently trying to build a multi-track bot based requester and provider station as shown below (only requester built)

FactorioStation.PNG (768.04 KiB) Viewed 6429 times

The issue that arises in such a configuration is that as soon as I turn on the constant combinator two trains are dispatched.

Would it be possible to have some condition, that if two stations are in the same circuit network only one schedule is created?

Also is it possible for lamps to ignore the colors that are carried by the wire?
It would make depots much nicer, since the colors would not be stuck anymore or you don't need a constant combinator for every single station.

FactorioDepot.PNG (841.72 KiB) Viewed 6429 times

Here both lights are green, even though the right one should be blue.

Best,
bldy

[DaleStan]

Would it be possible to have some condition, that if two stations are in the same circuit network only one schedule is created?

I don't think this is likely to happen. This would break existing networks. Consider a rail network where there are a multitude of stations that request iron plate. One for making steel, one for making iron gears, one for making belts, one for making ammo, one for making green circuits, and so forth. Right now, this just works. With your idea, you have to set the network ID signal for every stop.
Similarly, since there are two stops, the only reasonable assumption is that you need the higher throughput that two stops provide. There would be much anger if LTN made it so you effectively only had one stop. If your throughput needs are just a hair over a single stop and you end up with non-empty trains returning to your depot, there are at least two different solutions. One is to read only the provider chests, and dispatch a train to stop X when the chests for that stop can fit an entire train worth of cargo. The other is to continue reading the network, and dispatch trains to both stops when the network can hold two full trains of cargo.

Also is it possible for lamps to ignore the colors that are carried by the wire?

I think this can be fixed if you use the red wire instead of the green wire.

[Optera]

Please read Description & Information before making feature request or bug reports.

Planned features:

Will potentially be changed/added soon™ in no particular order.

• merge stops to one logical unit
  Honestly I don't know if I'll ever get to it.

[mrvn]

Please read Description & Information before making feature request or bug reports.

Planned features:

Will potentially be changed/added soon™ in no particular order.

• merge stops to one logical unit
  Honestly I don't know if I'll ever get to it.

I already have a patch to make station with the same name behave as a single unit.
@Optera: Did I forget to post the diff?

My aim was to have stations that trains can enter from either side. But this works just as well with stations that have 2 tracks. Only one stations lamp is programmed for the provides and requests settings but both stations yellow constant combinator need to be used. The station actually getting the train will show the relevant signals.

But such a setup only makes sense if the two stations share buffer chests. Otherwise you want dedicated schedules to the station that has space in it's buffer chest. In your case the waters are muddy. On the one hand the logistic networks counts items in all chests so the buffer storage is shared. On the other hand the active provider chests are relevant for unloading trains. If one side is full you want trains to go to the other station. You could disable each station if it's active provider chests become full and set the number of allowed trains to the number of open stations. But I think that just makes the station more complex.

Instead how about this: Connect the active provider chests to each stations lamp and the requested amount to never overflow those chests. Then enable the stations if the logistic network has less items than you want total.

[Optera]

I can't find a pull request on github for something like this.

[mrvn]

I can't find a pull request on github for something like this.

I will make one when I'm home again.

[mrvn]

I just updated my multi-stop station patch for current LTN and improved it a bit. I've made a push request that includes a save game demonstrating a simple working setup and a bunch of error cases.

https://github.com/Yousei9/Logistic-Tra ... k/pull/164

Sorry it took me so long.

[Optera]

No need to ping me here i get github notifications.

[mrvn]

No need to ping me here i get github notifications.

That was more for bldy.

[Mmmmmmorten]

Any closer to a solution or work-around for this? See that two stations working as one is still one the "Planned features" list.

Right now I have a situation where i have made two stations to basically receive the same 4 items. This is my Pink science build and I have 6-12-0 trains delivering Steel, Iron, Stone & Stone brick. Unfortunately Production science eats through a trainload of Steel and Stone in a bit more than 1 minute!
Thought two stations would be safer to make sure I have enough mats in inventory.

Now I'm at the point where I'm about to turn the stations on (constant combinator to ON), but suddenly started to wonder how that will work...
And searching the forum for similar LTN cases I found this - but no apparent solutions or work-around...

Constant combinator for both station are the same

Factorio Pink science - LTN Requester of Multiple items on Multiple stations.JPG (68.79 KiB) Viewed 5797 times

I set the stations to 1 so at least only one train is sent at a time, but afraid I can very fast end up with a bit of storage overload on my buffer chests (all active provider offload with robots) if I turn on both stations.

Any suggestions - outside turning only one of the stations on?

Ahhh - when reading through what I have written so far - I though of one solution - I can split the goods between the two stations and have the two most time critical on one each. If both stations only receive two types of goods there are no crash and no ques to station, and I can increase station to 2 trains...
This might actually work very well. sry

Would still like to know if there are any solutions for two stations working as on receiver?

/old dude

[mrvn]

For support for multiple stops with the same name acting as one station see the pull request on github.

You don't show how you designed the unloading. For two stops with the same name to work as a single station they need to use a shared storage. Otherwise one stop can overflow it's storage and have trains block while the other can run dry.

Possible designs for this include:

1) A bidirectional station with 2 stops so train can come in in either direction and stop at the same spot.
2) 2 stops with a warehouse in the middle so both unload to the same container.
3) Fluid stations pumping into the same tanks.
4) A single reachable stop with unreachable dummy stops that have different provider/requester settings.

Having multiple stops act as one isn't really about improving throughput. That can always be done using multiple stations with different names in parallel. Your case does not seem to call for multiple stops with the same name. As you noticed you can simple split the items to go to different stops. That gives you up to 4 stations right of the bat. But nothing stops you from having 2 stations with different names that request steel for example to increase throughput even more. Just draw equally / balance the belts from both stations.

[Mmmmmmorten]

But nothing stops you from having 2 stations with different names that request steel for example to increase throughput even more. Just draw equally / balance the belts from both stations.

Thanks mrvn. I did read the pull request on github before I posted here, but could not find anything after that post...
But as you said (and I discovered) the split of goods solved the issue there.

I do have the same problems again - Low density requires so much copper that a trainload last 0,8 minutes. But think I have figured out a solution for 2 stations (or more) using the same storage...

I have no belts - only bots that unload from active provider chests into buffer chests and from there to requester chest to belt.
The solution I have used (on the drawing board - to be set out for testing) is to have the first station act as normal and read from logistic network (use that for storage info on buffer chests).
The second station using the same inventory adds full cargo (in this case 48.000) x # of yellow lights from the first station. So the 2 station reads inventory to Logistic storage - item wanted in storage + 48.000 x # yellow lights from 1 station (= # of requested deliveries).
By setting the "- item wanted in storage" for the second station a tad lower than the 1 station they will not request on the same tick when the total storage has a shortage (I think). I will oversize the buffer chest storage capacity in either case - just to be on the safe side.
Hmm.. thought about it a bit more, and the yellow light turns to blue when a train arrives at station. Not sure if it still sending out yellow (for 2nd train if there where 2 yellow to begin with).
Might have to change the 2nd station to use max storage - current inventory - max request station 1 - train delivery x yellow signal instead. Keep a trainload as buffer from max storage and that might work. Have to test this out to see what happens as I don't know the workings of LTN good enough...

Think it will work?
I'll try, and if not I will have to split in 2 stations and far enough away to be two robot networks - and belt them together (as you suggested). This will require a lot more map footprint - so crossing my fingers for my workaround...

/old dude

[mrvn]

But nothing stops you from having 2 stations with different names that request steel for example to increase throughput even more. Just draw equally / balance the belts from both stations.

Thanks mrvn. I did read the pull request on github before I posted here, but could not find anything after that post...
But as you said (and I discovered) the split of goods solved the issue there.

I do have the same problems again - Low density requires so much copper that a trainload last 0,8 minutes. But think I have figured out a solution for 2 stations (or more) using the same storage...

I have no belts - only bots that unload from active provider chests into buffer chests and from there to requester chest to belt.
The solution I have used (on the drawing board - to be set out for testing) is to have the first station act as normal and read from logistic network (use that for storage info on buffer chests).
The second station using the same inventory adds full cargo (in this case 48.000) x # of yellow lights from the first station. So the 2 station reads inventory to Logistic storage - item wanted in storage + 48.000 x # yellow lights from 1 station (= # of requested deliveries).
By setting the "- item wanted in storage" for the second station a tad lower than the 1 station they will not request on the same tick when the total storage has a shortage (I think). I will oversize the buffer chest storage capacity in either case - just to be on the safe side.

Think it will work?
I'll try, and if not I will have to split in 2 stations and far enough away to be two robot networks - and belt them together (as you suggested). This will require a lot more map footprint - so crossing my fingers for my workaround...

/old dude

Why so complicated?

You have a train stop, it has active provider chests as buffer. Simply connect the active provider chests to the LTN stop and set the requested amount to the total size of the active provider chests.

Second train stop you do exactly the same but use a different name. Just copy&paste the whole setup of the first stop. The bots will pull from both stops although they might prefer one over the other due to distance. But so what? The nearer stop will run dry and then the bots will draw from the second stop.

You can ignore the storage chests completely for the LTN setup although they add another buffer so the train station running dry isn't the end of the world. I've made a similar setup yesterday with fluids as an exercise. Each LTN stop has 2 tanks for one wagon and requests -50000 water. The water is then pumped directly into shared tankage. That means each station quickly runs dry and orders 2 trains of water per stop. Each time a train arrives it takes about 10s to empty the stations tank and request a new train. That is until the shared tankage is full and things slow down a bit. I had a train arrive every ~30s after the initial rush.

[Mmmmmmorten]

Super mrvn!

I tend to over-complicate things

Will set it up as you suggest, and with a buffer storage - as I like to have that in case other complications (still got rail issues where trains pile up, and not enough trains on depots yet).
This will do just fine.

/old dude

[boran_blok]

For my blue chips factory I used double stations like this:

BlueChips.png (400.59 KiB) Viewed 5744 times

This factory requires 16 blue belts copper and 14 blue belts iron, so I have 2 of my 1-4-1 stations feeding each. Now this is a retrofit, as it used to be non LTN stations, hence the 6 stackers, you could probably get away with 3 stackers.

Note, the chip factory design itself is not mine, I cant remember whoose blueprint I used, I just placed the feeding and exit stations around.
Note2: This is also in creative, in game it was tweaked a bit more and looks like this when I added a 12 train depot to the right:

BlueChips2.png (403.72 KiB) Viewed 5744 times

[SkaarjRogue]

I believe I have built a workaround solution. The mod requirements for it are LTN itself and LTN Content Reader, and the sole contextual requirement is that there can only be one such "multi-station" per LTN network ID. Might post an actual blueprint later, if I get to cleaning it up a bit, but the core of the design boils down to 3 components:
1) A combinator setup implementing a round-robin over N values, N being the number of stops in a multistop, that uses yellow light from LTN train stops (which stands for a train delivery being scheduled for the stop) for round-robin increment.
2) A filter combinator setup on each stop, that allows feeding the logistic network contents into the the stop input if and only if the current round-robin value is equal to the station number.
3) A LTN delivery content reader feeding the contents of the pending delivery into the signal network.

How it works:
Suppose the initial output value of round-robin is 0. That allows only the first station to see the contents of the logistic network (naturally, with the set values of required deliveries from some constant combinator already substracted). Once some resource's count falls below threshold, a delivery is created with this station as the destination. When that happens, station's light switches to yellow, which causes the round-robin to increment the value to 1, and now this particular station is cut off from logistic network contents signalling (with the newly created delivery still pending), and the next station is connected to contents instead. Normally it would cause this new station to immediately create a delivery of the same resource, because this resource's count is still below the threshold and no delivery of that resource is scheduled to this station, but that's where LTN delivery content reader comes in - by feeding the delivery contents back into the circuit network, it essentially emulates the future where the resources have already been delivered and are inside the logistic network. This allows the station to react to absence of other resources or even the same resource once again, should its count fall to break through the threshold again, and the switching of stations goes on and on in the cycle.

[mrvn]

Wasn't there an (experimental?) option for LTN to not set a temporary waypoint in the schedule?

Without the waypoints there would be a simpler way to implement your setup at the cost of having all stations with the same name act as a single group of stations.

Simply place 1 LTN stop and feed it the provided count. Then place normal Stops (or LTN stops without programming) under the same name for the other parallel stations. Without the temporary waypoint in the schedule the trains will pick whatever station of the same name is free automatically and you don't need any round-robin programming.

PS: This reminds me that I wanted to patch in support for manual waypoints so the user can specify where the waypoint added to the schedule by LTN is rather than using the train stop itself. For a multi station you would place the manual waypoint before the entry into the station or in the stacker and then the trains would pick whatever station is free on their own. This would still allow stations with the same name at other places since the manual waypoint would get trains close enough, just not as close as the current automatic waypoint.