How does priority work?

[McDuff]

I've got some areas set up with a requester station for inputs and a provider station for outputs. I also have an "overflow" system set up so that if, for instance, there is too much iron plate in the area, it gets belted to the provider for pickup so it can be taken back to central storage.

The problem I have here is that, even with the provide priority set high, LTN will still sometimes request iron plates from central storage back to central storage, sending a train on a little loop and leaving the overflow plates in the output station.

Is there a way to ensure that LTN will absolutely prioritise the outposts? Does it calculate priority based on distance? Do I need to set the outpost provide priority to a million or something? Or is this the kind of thing that will just happen sometimes?

[jodokus31]

I made the experience, that the provider with the highest provider prio is used first, if it's simply higher by at least 1
But it only provides, if the provide threshold is met, which is 1000 by default. If not, the station is not considered.

[McDuff]

There were definitely some stations that didn't behave like that for me. I may have to do some test maps.

[steinio]

I suppose you need the loginetwork id.

I have all stations on default (all) networks.

One storage input station
- with id 1
- request 1 billionmemillion item x amount
and the output station with id 2.

With this all stations which provide item x deliver to storage or - if requests from other stations - to them.
The output never delivers to the input because of different network ids.

Priority works like as first service the highest numbers.

[Optera]

Priority works like as first service the highest numbers.

Not quite.
Oldest requests are served first, not largest.

[McDuff]

Well my tests on a new map worked according to how the priority system should work, so I'm obviously doing something weird in my other build. Never mind.

[McDuff]

So this may have had something to do with the way I had set up the circuits. I'm writing up the (partial) solution I found to hopefully help other people and see if I could make it work better.

The issue I had was that the "trash" station could contain any arbitrary number of items. "Provide limit" works on a per item rather than a total number of items basis, so if you set the provide limit to, say, 1000, you could have 999 of everything and they would never get picked up.

I used the circuit network to send the contents of the chest as a request to the dropoff station for the main inventory. So if the trash station had an inventory of 400 belts, 200 inserters, 30 iron plates and 25 circuits, the dropoff station would have a request for exactly that amount.

In order to only request this when the inventory was full, I set a combinator system up to only send those signals when the total number of items across the chests was >1000. This was fairly simple - arithmetic combinator of "each * 1 OUTPUT T," giving a total T of all items. Then a decider of "if T > 1000 OUTPUT A." Then another arithmetic combinator multiplying "each * A OUTPUT each." If the total is over 1000, the signal is sent, if not all the signals are multiplied by zero.

This worked after a fashion, but the station would still send too many trains - up to the trash station train limit, then send another one to the main store pickup to do a useless loop.

To work around that I set another conditional up - stations output a signal on "yellow" to say how many deliveries they're expecting to get. I ran a decider combinator with "if yellow < train limit OUTPUT B" then another arithmetic combinator to, again, null the request signal down to zero if the station was already at its limit of trains being requested.

This did effectively solve the issue of trains going to the main store station and doing a loop. However, there remains a strange issue where LTN does not request the full amount that has been requested. If the station has, say, 500 iron plates, 300 iron gear wheels, 201 circuits," triggering the request signal to be sent, LTN will issue a schedule but it appears to request less than it's being asked for. It may issue a schedule for 400 plates, 320 iron gear wheels, then a second request for 100 circuits or something. This sends too many trains for what should be a single trip, and still does not pick up everything I want it to.

I have solve the initial problem of trains going where they shouldn't, but I can't work out why two LTN stations with their request and provide thresholds set to 1 (so they will request or provide everything no matter if there is only one in storage) won't match up the request amounts properly.

As I understand it if there is one station which has an inventory of "X iron, Y ciruits, Z gears" and a station with a request of "-X iron, -Y circuits, -Z gears," LTN should make a schedule asking for the whole lot. Is there something I'm missing to make this behaviour happen? Is it somehow related to the delay of a couple of ticks it takes to get through the requester network?

[jodokus31]

I'm not sure, if I get the intention of those complex circuits.
But maybe those things will help:
- A train schedule is created as soon as a certain request amount can be served by a provider (couple of ticks delay of ~1 to 60? ticks). This works per item type. If it occurs, that different items types, which are requested by the single requester can be served by a single provider, the delivery gets merged (always considering the train stack size and locked slots per wagon).
- You may not be able to fill a provider with a provide threshold of 1 in only a couple of ticks (inserters are slow, even direct dump from player inventory could be too slow for multiple items). So the train schedule is triggered before the provider contains all the items it should provide.
- Provide threshold of 1 means, that there can be train schedules, which only pickup 1 item. I'm not sure, if you really want that for other than exceptional situations.

[McDuff]

Some testing on a new creative mode map seems to put the issue at having more than one train being sent... which is really fine because, thinking about it, I can live with only one train being sent and for really productive bases I can just set the trigger limit to 3000 rather than 1000.

In this case, yes I do want things to only pick up a stack of one if it's in there. The station is "garbage collection" so it's entirely possible that there could be a bunch of junk in there with small stack sizes and I want to get it all, basically.

[jodokus31]

I have an idea to gate the amount of trains for a garbage train station a bit and make merged deliveries more likely.
Usually, with low provide threshold, the schedule is triggered immediately, if the content of one item reaches the threshold.
Now, maybe you could set a high provide threshold, f.e. 10000 or leave it to default.
Then count the overall amount of items and if it reaches 1000 (this combinator of "each * 1 OUTPUT T), then you set the provide threshold down to 1.
This should set up a delivery with the highest possible content and merged, if possible.
After that, the provide threshold switches back to high.

Need to try it myself for my garbage station...

[McDuff]

I believe this would work. The problem that my way tries to fix is that you don't just need the provider station to provide, but the requester station to request.

The provider station could say "yes I have 5 stacks of yellow belts" but if nothing is asking for it LTN won't generate a schedule.

By controlling the amount sent down the "request" wire you solve a couple of problems.

1) getting the overflow back to central storage
2) if another station wants what you're making, not necessarily having to wait for it to go back to central storage first.

[mrvn]

So this may have had something to do with the way I had set up the circuits. I'm writing up the (partial) solution I found to hopefully help other people and see if I could make it work better.

The issue I had was that the "trash" station could contain any arbitrary number of items. "Provide limit" works on a per item rather than a total number of items basis, so if you set the provide limit to, say, 1000, you could have 999 of everything and they would never get picked up.

I used the circuit network to send the contents of the chest as a request to the dropoff station for the main inventory. So if the trash station had an inventory of 400 belts, 200 inserters, 30 iron plates and 25 circuits, the dropoff station would have a request for exactly that amount.

In order to only request this when the inventory was full, I set a combinator system up to only send those signals when the total number of items across the chests was >1000. This was fairly simple - arithmetic combinator of "each * 1 OUTPUT T," giving a total T of all items. Then a decider of "if T > 1000 OUTPUT A." Then another arithmetic combinator multiplying "each * A OUTPUT each." If the total is over 1000, the signal is sent, if not all the signals are multiplied by zero.

This worked after a fashion, but the station would still send too many trains - up to the trash station train limit, then send another one to the main store pickup to do a useless loop.

That sounds like you are overloading the trains. Only put as much items in the train as requested and there should never be an empty train.

To work around that I set another conditional up - stations output a signal on "yellow" to say how many deliveries they're expecting to get. I ran a decider combinator with "if yellow < train limit OUTPUT B" then another arithmetic combinator to, again, null the request signal down to zero if the station was already at its limit of trains being requested.

This did effectively solve the issue of trains going to the main store station and doing a loop. However, there remains a strange issue where LTN does not request the full amount that has been requested. If the station has, say, 500 iron plates, 300 iron gear wheels, 201 circuits," triggering the request signal to be sent, LTN will issue a schedule but it appears to request less than it's being asked for. It may issue a schedule for 400 plates, 320 iron gear wheels, then a second request for 100 circuits or something. This sends too many trains for what should be a single trip, and still does not pick up everything I want it to.

I have solve the initial problem of trains going where they shouldn't, but I can't work out why two LTN stations with their request and provide thresholds set to 1 (so they will request or provide everything no matter if there is only one in storage) won't match up the request amounts properly.

As I understand it if there is one station which has an inventory of "X iron, Y ciruits, Z gears" and a station with a request of "-X iron, -Y circuits, -Z gears," LTN should make a schedule asking for the whole lot. Is there something I'm missing to make this behaviour happen? Is it somehow related to the delay of a couple of ticks it takes to get through the requester network?

Maybe the train is full when including the reserved slots? Or Y was below the request threshold. Or the train went to a station that only wanted iron and gears.

Usually when requests and provides don't match up I have timing issues. One item is requested or provided earlier than the other. By the time I look all items are requested and provided but when LTN send the train only some where.

[Optera]

I have an idea to gate the amount of trains for a garbage train station a bit and make merged deliveries more likely.

Or simply use limit trains = 1 so LTN ensures only 1 train is ever en route to this stop.

[jodokus31]

I have an idea to gate the amount of trains for a garbage train station a bit and make merged deliveries more likely.

Or simply use limit trains = 1 so LTN ensures only 1 train is ever en route to this stop.

Yes, I have that too. But thanks for pointing it out again. Generally, i gate all my stations with limit 2, to avoid to many waiting trains filling the stackers. Sometimes, i say 3 or 4 for highly used stations, if the stacker can handle it.
My idea could have the advantage, that a merged delivery is triggered, because not just one item type exists in garbage station. However, it may not have a very big impact and works without it quite well already.

[mrvn]

I would set provider-limit = 1 and only send the contents of the buffer chest of the station to the lamp if total content > 1000 or the input belt going to the warehouse (or station used to fill the warehouse) is empty. That way LTN won't send a train as soon as the first garbage item is deposited but will take away every last scrap when no more garbage comes in.

[McDuff]

That sounds like you are overloading the trains. Only put as much items in the train as requested and there should never be an empty train.

The request was only sent at 1000 and the trains would pick up perhaps 3 or 4 stacks, so that wasn't the issue.

Maybe the train is full when including the reserved slots? Or Y was below the request threshold. Or the train went to a station that only wanted iron and gears.

No, the request was set to exactly what was in the "trash" station buffer chests.

[McDuff]

I have an idea to gate the amount of trains for a garbage train station a bit and make merged deliveries more likely.

Or simply use limit trains = 1 so LTN ensures only 1 train is ever en route to this stop.

This is what I've ended up doing, but you still need to put a trigger in place to cut off the request while you've got a yellow signal. Otherwise, if you've got more than a trainful of items to pick up, LTN sees that it has a request, and the station that you want it to get the items from is marked as busy (because it is at its limit for number of trains) and so sends out a train to do a little pointless loop.

The logic/pseudocode is:
IF
Buffer > 1000
AND
Scheduled Pickups from this station < 1
THEN
Send contents of buffer to request station
ELSE
Do nothing

[Optera]

What's the point of instantly pulling every single piece of ore from depots? Just have providers at depots with reasonable thresholds and recirculate items "naturally" through LTN.

I use a provider & requester at each of my 3 depots.
They request fuel and provide anything else to the entire network on a higher priority than any other stop with a threshold of ~100 items. Only time i ever end up with items is when i messed up some wiring or manually send a half filled train back to depot because it was in my way of rebuilding a module.

The depots logistic storage is hooked to ltn through a Logistic Network to LTN stop filter.
A latch isn't needed either since that's built into LTN's logic.

[steinio]

Priority works like as first service the highest numbers.

Not quite.
Oldest requests are served first, not largest.

I mean highest numer == highest priority.

My understanding is, if i have 3 stations provide item x, with priority 1, 2 and 3, the station with prio 1 is always serviced first.
Am i right or is prio 3 always serviced first?

[Optera]

Higher priorities are used first.
The only exception is when merging grabs copper along with some iron from a priority 0 mixed mine even if there are priority 1 copper mines.