1.13 question

[ssilk]

Maybe I’m a bit late, but searched around and found nothing:

Version: 1.13.0
Date: 2020-04-12
Features:
- use temp stops for train pathing, removes requirement of unique stop names by GloinTheDark #210

What does this do? Will it now be possible to built train stations out of several train stops with the same name, like in the vanilla? And how can it be used?

[Optera]

No, vanilla relies on path finder picking which stop "A" a train will go.
The whole point of those temp stops is to have trains go to a specific stop "A".

[ssilk]

Ha, I thought that will be possible under certain situations now. Would be nice to have (for example) three train stops with identical provision and a fourth stop (before the three) that decides which of the three will have the next train.

[Optera]

Why?
That kind of routing is not needed when knowing exactly how many items each stop has and wants.

Having Smelter Unload 1-3 each with their individual buffers hooked to LTN balances much smoother than base routing ever could.

[ssilk]

The problem explained

when the train is assigned it takes a while, until it arrives at the loader. Then it is loaded, then it rides to the requester. With big maps this can take 3 minutes or MUCH longer.

This leads to the situation, that the requester is always empty, because LTN cannot provide “fast enough”. no, it’s not so, that it is too slow or so. 10 seconds and more until an item is requested is no problem in this kind of world. The underlying problem is, that - because there is this big delay between start of travel and delivery - LTN calculates “wrong”. I mean: It’s correct in the moment when the delivery starts, but not anymore after 3 minutes.

This can have several reasons: player took something from the logistic network, which you have coupled with LTN, or you build something, or the items are just used for production faster, than the buffer can be filled (because the buffer is much smaller than the number of trains needed to keep it filled), or have been reloaded into another direction.

My tries to fix this:
1. The most simple and stupid solution: I need to request much more than the station can hold. But that leads to situations where 10 and more trains wait before the requester to unload. Which leads to deadlocks.

2. I can increase the buffer. But that leads to situations where station 1 is full and it’s neighbor station 2 is empty, because of the big delay between request and delivery. The buffers are so big, that there is nothing left to share, because in the moment of request the buffer of station 2 where full. Now (or better 3 minutes ago) when station 2 needs stuff the providers are bought empty.

And you won’t have such big storage, the sense is to have as much as possible delivery on demand. In factories with that size big storages is no good way: the whole system slow, because the buffers wants to be filled over a level, that can be balanced well. You cannot see anymore, if there is a problem, because the buffers are so big until the problem arises and then it is much too late, it takes very long to refill the buffers again. No, the larger a factory is, the more you want to have delivery on demand, because the storage are the wagons then. The more wagons are on the way, the higher is your storage. And vice versa. This balances more or less perfectly out in such scenarios.

3. Make it even more clever: try to estimate the need of items per minute. I know how much items will be used per minute and how much end-products needed. So the

storage - neededItemsPerMinute * estimatedTimeToProduceNeededNumberOfEndProduct

is what I request.

The result was a deadlock with over 300 trains. I didn’t take brownouts into account.
This last setup is so complex that it will be never be stable and it is a horror in setting up. And it works only where you are able to estimate.

And all in all this also does not work for delivery of construction items. For really big constructions (e.g. a sea of solar fields) you want two requester stations, that share one request.

So the solution for me

a) increase the precision of what is calculated as request.
b) allow, that the amount of items “on the way” can be way bigger, than one station alone can hold.
c) enable to share requests between stations, because the request is too big to be handled by one station. This enables to decide the target station in the latest possible moment, which is needed to avoid the above explained problems.

It is the combination of b) and c) which makes the difference! b) alone can be handled just by more buffer, until the number of train exceeds the throughput of a train station. And c) alone makes no sense when you can only request the number of items for THAT station, because the buffers needs to be as big, as the number of trains on the way.

You can argue that LTN doesn’t need to share requests, see your post, but I think my argument is that this “items on the way must be much bigger than one station can handle”-problem, which can be fixed (in my opinion) only if you enable to balance the things at the latest possible moment into several stations.

A view from reality: Long time ago I’ve been working in a very big storage-house. They had dozens of ramps for the trucks to deliver/load and it would not make any sense to tell the trucks which number of ramp they should use, when they startet their travel. The same is it here.

So my ideas of how to change LTN

1. When the travel begins at the depot, the exact number of items are not known yet. LTN knows internally “there is a train on the way and as it looks now it will transport that”

2. At the provider recalculate the amount of items to be loaded (what I already did propagate several times). I let it here open if the train can only load the item-types he has reserved at the depot or if he can load also other items that are now requested/provided. What’s fixed here is only the target station or - if the request is fulfilled meanwhile - the return to the depot.

3. To enable to decide which target should be taken we need a no-wait stop before the targets. Here the real target station will be added to the schedule, depending on the currently requested amounts (biggest request of largest item-amount wins)
This no-wait stop is a new virtual requester: this is configured with a new “virtual” signal (like the depot) and he has the requester lamp connected with the sum-signal of the whole requests.
His output is a new signal (I call this the virtual-network-ID) and all you need to do is to connect this number to all the real target stops. It will also output the train configuration signals you inputted into the virtual stop. Because due to obvious reasons you cannot have mixed train configurations for a virtual station. (Maybe there are ways, but this would make the whole idea a lot easier to implement)

4. The real train stops work just as before. The only difference is, that the inputed requests are used to decide, which real station should be taken after passing the virtual. There are no real requests for the LTN scheduler. This should make it also easier for the scheduler, because - in my typical setup - I would have 4 stations per one virtual station, but the scheduler needs to look only for the virtual stations and stations without virtual-network-ID.

It is a bit complex to make all the circuit network connections, because you need by minimum 3 combinators. One to separate the request signal for that stop from the sum to deliver it to the virtual. One to input the virtual-network-ID-signal and train configuration signals from the virtual stop. And a constant combinator to filter out the feedback into the request-sum.

5. This works also for virtual provider train-stops.

In short

- Depot: change is only that the exact number of items are not set here, only the item-types are known.
- Provider: here the change is, that it calculates the exact amount of items, depending on the current numbers from requester and provider. It sets the schedule to the virtual train stop and then to the first requester station.
- NEW Virtual Train Stop: This is in the train-schedule a no-wait-stop. It is a normal LTN-stop, that receives a “virtual” signal (as the depots). It also receives the total requests from all requesters and it outputs the virtual-network-ID and the train-configuration signals.
When the train passes this signal (hm, is there really an event for passing no-wait-stop?) the target is recalculated based on demand of the targets.
- Requester: this works nearly as before. It doesn’t request items (that is done by the virtual stop only). For the player the work here is to connect the signals for requesters correctly with the virtual train stop.
- there is no test, if the target stops are really “behind” the virtual stop, or if they can be reached, it’s the players task.
- this works for virtual providers identically.

Possible Features

- if you connect a target stop with the virtual-network-ID it can automatically overtake the name of the virtual stop and add “-1”, “-2”, or “-A”, “-B” and so on.
- it can possibly try to figure out the current target, the scheduler has found and if nothing speaks against it it doesn’t need to change the target after passing the virtual stop.
- because of the hassle with connecting the virtual stop with the real stops, I think this all could also be achieved by some kind virtual connection, where all virtual trains stops in an area are listed and you can choose the right one and it will connect the stop automatically.
- More comfort if Factorio would enable to have multiple stops with the same name, but enables to force one stop as a target, not based on name, but based on train-stop-ID.

[Optera]

Once again you seem laser focused on your specific situation, forgetting every other use case for LTN.

1) as you said that leads to trains waiting inside a station to be unloaded. Within reason that can be done for guaranteed high consumption stations. It certainly is not recommended, eventually delivery timeout will invalidate the waiting trains and send new ones.
2) That's the recommended way. Buffer should be large enough to hold under full drain until a delivery arrives. On my Megabase it takes up to 5 min and I never had buffers run below 50%.
3) Not going to happen, calculation is expensive and will fail with factories operating in bursts, which are practically all of my designs. I build to produce 110% and have them operate on hysteresis switches.

a) precision already is single item
b) not going to happen see 1)
c) 100k shared between two station is just 50k each

Pick a random? train from depot and deal with how much it can carry at provider is a terrible concept.
One of the major features of LTN is to calculate delivery size in advance and pick the optimal train for the job.

If you want faster response times use TSM or VTM. 5 years in I won't change the fundamental logic on which LTN operates.

[ssilk]

Well, you can leave out that the real amount is calculated at the provider station. That is just optional. I added it, because I still think it’s useful (and I don’t see the big difference if the amount is calculated in the depot or the provider.)

What I target is your argument that

100k shared between two station is just 50k each

This is not the correct case I described. What I described is, that I have 5 stations which requests 20 k each and in sum they request 100k and that is a big difference in handling, because the amount of stock that can be on the way for 100k is much higher than for 5x20k.

Edit: or in other words, I want to reduce the needed buffers, because they eat my hairs. It makes no sense to request 1 million red circuits in total if you really need only 50k on average for each station.

[Optera]

What you describe is one huge train with a 100k delivery sitting in one station, failing to unload while the other 4 are empty.
All your suggestion does is move items from sitting in buffer chests to trains waiting to unload way too large deliveries.

Items in buffers can easily be balanced with loader>chest>loader constructs. Items in trains are unusable until unloaded.

[ssilk]

What you describe is one huge train with a 100k delivery sitting in one station, failing to unload while the other 4 are empty.

How would such a train match into the station? How would it even travel through the rail system without causing huge problems to the other trains?

All your suggestion does is move items from sitting in buffer chests to trains waiting to unload way too large deliveries.

Items in buffers can easily be balanced with loader>chest>loader constructs. Items in trains are unusable until unloaded.

Maybe you don’t understand me or I don’t understand you.

I tried to look back what triggered me to write this and I it is this:
I want to reduce the summed threshold by adding the requests of many stations into one big request. That sum needs only the threshold of one station, so delivery can start much earlier. So the threshold is percentually much smaller as if I have just one big station, or I make a bigger storage. (And because that one station is not able to handle all the requests).

[Optera]

Again what's the point?
1 large requester has magnitudes better performance than 5 small ones.

Are you trying optimizing performance loss from inserters interacting with huge 1k+ slot storages?
That's pointless 1 LTN stop has more performance impact than 100k inserters on a 100k slot chest.

Are you worried about items lying around "unsused"?
A base requiring multiple unloading stations should be capable of producing enough to fill a buffer in seconds. When producing 2M green circuits per minute having 10k of them resting in buffers is the production of a few ticks.

[ssilk]

Again what's the point?
1 large requester has magnitudes better performance than 5 small ones.

Only, if that one requester is able to handle the amounts of trains to handle it.

It’s similar to single thread vs. multithreaded.

Are you trying optimizing performance loss from inserters interacting with huge 1k+ slot storages?
That's pointless 1 LTN stop has more performance impact than 100k inserters on a 100k slot chest.

No, this is not about CPU performance. It is about that there are (Factorio) physical limits of how much trains can transport. Depends on train length, inserter stacksize and some more. And is limited by space for station and how deep UPS you are wanted to play with and such things.

Are you worried about items lying around "unsused"?
A base requiring multiple unloading stations should be capable of producing enough to fill a buffer in seconds. When producing 2M green circuits per minute having 10k of them resting in buffers is the production of a few ticks.

Yes, and when you exceed more than 50k/minute (dunno, I guess that) then you have that problem: you cannot order more trains, because only one train can be filled/emptied per time. I think someone has calculated the theoretical optimum for the number of wagons/locomotives vs. throughput, but then the stations get really big.