trains behavior with few same name stations

[volkoff]

here is the deal.
We have:
- 1 ore load station
- 3 ore unload stations with same names. 2 of them near in stack (2, 3) and one (1) far away.

if i have 2 trains between them with same script:

Code: Select all

LOAD STATION until train get  FULL
UNLOAD STATION until train get EMPTY 

does that mean that no one from that 2 trains never reach that 1 far away station because they will always chose closest destionation ?
ore they will try to circulate beetween all of them ?


---


i just try to figure out: on megabase can i name all unload stations with same name, or this is bad idea because the farthest stations never get any ore (if case when trains have enough closest stations to not create a queue ?? (for simple example if 1 have 1 train - will he always go to one closest station ?? ))

Thank you

[Serenity]

There is a new feature in 1.1 where you can limit the number of trains pathing to a station. If you set that to 1 then they will pick other stations once the closest has a train going to it

[volkoff]

There is a new feature in 1.1 where you can limit the number of trains pathing to a station. If you set that to 1 then they will pick other stations once the closest has a train going to it

that could work but that limit not absolutely crear:
limit 1 to what ? for simultaniuos destination of all trains to this station? what if i have 1 train for all 3 stations?))
i think limit will work if you have number of trains more than summary pointed limit on all stations , like

Code: Select all

3 stations with same name, limit  = 1 to each of them and lot of trains

but in this case what if i have a 5 trains? 2 of them will just stay??

I read about this new feature in 1.1 but i think we will need detailed instruction how it works

[Serenity]

It's mostly meant for setups where the number of stations is less than or equal than the number of trains. In the first case you probably still want a stacker where the extra trains can park as the stations could be disabled while trains are en route.

Having more stations than trains and trying to service them equally probably isn't good design anyways as it will likely lead to shortages. At least for large scale consumption.
You can do stuff with combinators in these situations and disable stations when they don't need anything. This is very useful for supply trains that drop off a bit of fuel or repair packs now and then. It's probably possible to design a round robin scheduler, but the easy solution is obviously to build more trains.

[Zanthra]

...
i just try to figure out: on megabase can i name all unload stations with same name, or this is bad idea because the farthest stations never get any ore (if case when trains have enough closest stations to not create a queue ?? (for simple example if 1 have 1 train - will he always go to one closest station ?? ))
...

The solution here is of course that you need more ore . It's a lot like bus lines going dry due to stuff at the front of the bus consuming it all.

Another potential solution is to have holding zones near each output station, and have different trains go to different holding zones before going to the final shared station. While the trains may go from one holding zone to a far output station if the near one is not needed, and can lead to some delay in resource delivery, it can make sure that each destination station has at least one train that will find that station as closest during pathfinding after the holding station.

Basically have one train that prioritizes each of the output stations, and a set of other trains that don't have a holding station to prioritize anything.

[Durr]

I use same name stations and what I found works best is to have (for each cargo type) N-1 trains where N is the total number of stations, and each station is limited to one train (unless there is a stacker at that station, in that case I add 1 to N and the station limit for each stacker lane). This works best if you are over producing so the odd-man-out station is a shipping station and not a receiving station.

[volkoff]

I use same name stations and what I found works best is to have (for each cargo type) N-1 trains where N is the total number of stations, and each station is limited to one train (unless there is a stacker at that station, in that case I add 1 to N and the station limit for each stacker lane). This works best if you are over producing so the odd-man-out station is a shipping station and not a receiving station.

hm.... maybe if you have 20 stations and 19 trains its ok, but.. like in my situation (look at 1st pictire) if you have 3 stations and.. lets say 2 trains - if you put limit = 1 to every station nothing will change - those 2 trains will feed 2 nearest stations and far station 1 will starve

3 trains to 3 stations - (with limit = 1 to each) - that sounds reasonabe )

[Durr]

The problem with having the same number of trains as stations is that they will all block each other, there is no empty station to path to.

As I said, my method works best if you are over producing. If you had 3 ore stations going to 2 smelters, or were able to load at the ore station faster than the smelters consume from the trains, my solution would work. Occasionally I run into an issue where a receiving station is always running dry, so I create a new mining outpost or intermediate product factory to meet the demand.

[volkoff]

The problem with having the same number of trains as stations is that they will all block each other, there is no empty station to path to.

As I said, my method works best if you are over producing. If you had 3 ore stations going to 2 smelters, or were able to load at the ore station faster than the smelters consume from the trains, my solution would work. Occasionally I run into an issue where a receiving station is always running dry, so I create a new mining outpost or intermediate product factory to meet the demand.

oh. that makes sence )

[Kahnugo]

hm.... maybe if you have 20 stations and 19 trains its ok, but.. like in my situation (look at 1st pictire) if you have 3 stations and.. lets say 2 trains - if you put limit = 1 to every station nothing will change - those 2 trains will feed 2 nearest stations and far station 1 will starve

3 trains to 3 stations - (with limit = 1 to each) - that sounds reasonabe )

A solution to that could be to have some other means to set limits. For example you could set limit to 1 if the train stop buffer is empty (chest or just having a wire on a belt to see if there's any ore flowing). If there is enough ore to satisfy the demands that should work.

[mmmPI]

i just try to figure out: on megabase can i name all unload stations with same name, or this is bad idea because the farthest stations never get any ore (if case when trains have enough closest stations to not create a queue ?? (for simple example if 1 have 1 train - will he always go to one closest station ?? ))

If you have 1 ore load station and 3 unload iron station. You assume that the ore production can meet the demand of all 3 unload i suppose.

It's up to you to decide how many trains you want to use in that configuration.

If you want to use a single train. You need to enable/disable the unload station named the same. This way when an unload has enough material it doesn't call the train. Which then will go to another unload the next time. For this you need to connect the chests/tank of an unload to the station. The station should be for example open when iron <200. And you use a decider combinator for the upper limit, "iron>2000 output 1-green-signal" You can then pass this signal to the train, it's a box to tick in the station. This allow to set the schedule with an additionnal condition at unload "empty" OR "1-green-signal". This make sure the train doesn't stay at a full unload, once it has brought enough material to trigger the signal it goes back to the ore production and wait for another unload to open. The most prioritized by the train will be the closest unload. In case of material shortage it will be the only one serviced. So this would function ASSUMING production is over demand.

(this is for example how i supply sulfuric acid to uranium patches, i have 1 trains that refill a tank up to 20K when it has less than 1K otherwise , the train sits at the acid loading station)

If you want to use 2 or more trains the same logic roughly apply. But you need to add extra precautions. There must be somewhere enough room to accomodate all train. I see on your picture that you already use stacker so this part is done . Then you may not want your 2 trains to go to the same unload if all 3 of them are requesting material, especially if you have more than 2 trains, say 15 trains, that would look very silly all trains would go the the same outpost as soon as it opens, it would force placing gigantic stacker everywhere. That's one place where the new limit system comes to play. For each outpost you can limit the number of incoming trains to 3 or 4 for example. This way you make sure to avoid flooding the closest outpost with all the supply, and it allows to reduce the size of stacker at this location.

The other thing the limit system allows you to do is a waiting area. if you have A->B->A->B schedule, if all A or all B are closed the train will stay static. If you have A->B->C->A->B->C schedule, if you close all C, the trains will do A->B->A->B. And this is problematic because this means if you have Load, Waiting, Unload, and all unload are closed the trains would go from load to waiting to load to waiting which is silly. To avoid this problem instead of disabling the unload station, you reduce the limit to 0. This way the train would stay at the waiting area, and you increase the limit back to 3 or 4 when you need material as in first example.

You can even use 2 waiting bays, one after loading, one after unloading. The drawback is more indirect travel for trains, the advantage is that you can limit the number of trains on unload AND on load. This way the load and unload function the same way you can have mutiple of them called the same and if you have an load that run empty it disable itself automatically. And you don't need to worry about making a huge stacker for it or having trains queueing after the half-full last train. You could set "inactivity" condition on load, so that even the last half-full train wouldn't get stuck when mining outpost deplete.

This is one way of doing things based on the assumption that production is over demand, there are others .