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.
