old LTN discussion thread

[Optera]

And this is the part which is not true (based on what I have seen in my little test setup or torne just described). Even if a provider has a provide threshold of one, a delivery is only created if the request threshold of a requester is exceeded .

LTN always was solely request driven.

Before it was created as soon as the amount of wares in the chest minus the desired amount was smaller than zero.

Wrong. Requests always where generated when (amount *-1) >= Request Threshold/Min Delivery Size.
Request Threshold doesn't behave different from Min Delivery Size as they are the same variable, only its name and one check during provider search have changed.

Btw. this is not the description of an active provider chest. Deliveries are only created if someone is missing a ware, an active provider station would have to create deliveries with undefined targets at any time just to get empty, which is of course not possible.

The effect of "ignore minimum delivery size" was effectively "take all this stuff to any station that can use it and has enough room"

This literally is the description of an active provider. LTN certainly never behaved like this.

[torne]

The effect of "ignore minimum delivery size" was effectively "take all this stuff to any station that can use it and has enough room", but just setting "provider threshold" to 1 only means "take all this stuff away once a station needs a full delivery of that item, even though this station can't provide a full delivery".

Functionality similar to Active Provider Chests as you describe here never was part of LTN.
All best effort/ignore min delivery size ever did was making providers eligible that otherwise would be ignored for providing less than min delivery size. Which is exactly what setting provide threshold to 1 does.

I mean that depends what you mean by "similar", but the functionality I describe absolutely was part of the old version of LTN and I have maps that use it - you might not have *intended* it, but it did work.

The situation that worked this way in the old version, to be specific:

1) LTN station that currently has a signal of -100 wood (calculated by adding up a constant combinator set to -2000 wood, and a bunch of chests that currently contain 1900 wood), and a minimum delivery size of 1000.
2) LTN station that currently has a signal of 5 wood (just directly from a chest containing 5 wood), and ignore min delivery size set to 1.

In this scenario, the old version of LTN will schedule a delivery of 5 wood from station 2 to station 1, because it ignores the minimum delivery size. There is no way to get the same behaviour in the new version of LTN: even if you set provider threshold to 1 on station 2, no delivery will be created until after 900 wood is used up at station 1.

The behaviour of "ignore min delivery size" in the old version is basically the same behaviour as active provider chests in a logistic network with no storage chests: if there's any requester that actually needs the item in question then the item will be delivered immediately without any concern for delivery size. This *doesn't* replicate the "move to storage" behaviour of active providers, because LTN doesn't have the concept of storage, but that's still how a regular logistic network behaves if you have no storage chests.

So yes, you are right that all it did is make providers eligible that otherwise would be ignored for providing less than min delivery size - but because the new system now requires both stations to be separately "eligible" to be each end of a delivery based on their own conditions, the effect of the old version can no longer be replicated: just making the provider eligible is no longer enough.

[Optera]

I mean that depends what you mean by "similar", but the functionality I describe absolutely was part of the old version of LTN and I have maps that use it - you might not have *intended* it, but it did work.

The situation that worked this way in the old version, to be specific:

1) LTN station that currently has a signal of -100 wood (calculated by adding up a constant combinator set to -2000 wood, and a bunch of chests that currently contain 1900 wood), and a minimum delivery size of 1000.
2) LTN station that currently has a signal of 5 wood (just directly from a chest containing 5 wood), and ignore min delivery size set to 1.

I have a similar system in place to collect wood and used air filters and it works exactly the same as before. The only differences to your system are my requester being set to always request regardless of storage, since i want all wood and used filters at that station, and I set a provide threshold of 200 preventing trains from running empty.

In this scenario, the old version of LTN will schedule a delivery of 5 wood from station 2 to station 1, because it ignores the minimum delivery size. There is no way to get the same behaviour in the new version of LTN: even if you set provider threshold to 1 on station 2, no delivery will be created until after 900 wood is used up at station 1.

No idea what you used before, it certainly wasn't LTN. Requests where never processed below min delivery size/request threshold.

The behaviour of "ignore min delivery size" in the old version is basically the same behaviour as active provider chests in a logistic network with no storage chests: if there's any requester that actually needs the item in question then the item will be delivered immediately without any concern for delivery size. This *doesn't* replicate the "move to storage" behaviour of active providers, because LTN doesn't have the concept of storage, but that's still how a regular logistic network behaves if you have no storage chests.

For the last time, LTN never had and never will have provider driven deliveries aka active provider.
You could, and still can, instantly collect amounts down to a single piece by having a requester constantly requesting and provider set to provide threshold = 1.

So yes, you are right that all it did is make providers eligible that otherwise would be ignored for providing less than min delivery size - but because the new system now requires both stations to be separately "eligible" to be each end of a delivery based on their own conditions, the effect of the old version can no longer be replicated: just making the provider eligible is no longer enough.

See above.

[Maglay]

-

[Optera]

You say the station with ignore min deliv size results in provider driven deliveries

I keep saying this is NOT what LTN does for the last 2 days.

only if a requester station needs this ware, because the signal at the lamp is negative, a delivery is spawned.

that's correct.

If you still claim that version 1.2.8 is not your mod and I'm doing stuff with it which is impossible in your eyes thats fine. Once 1.2.8 is no longer working i'll clone your repo and add the feature on my own.

You are free to do so for personal use as long as you don't make it publicly available.
I'm not going to offer support for forks of any kind.

[DerGraue]

Hey Optera,

just wanted to say BIG THANKS for this awesome mod!

I really hope the devs will include something like this in the main game one day, it basically adds the next logical step for train deliveries.

[Odhrean]

Can you explain in more Detail for what the Signal "Locked Slots per Wagon" can be used for.

Is it possible to use this signal to reserve one Wagon Slot to reduce the Delivery Size so Inserters are always able to complete the last inserter swing and not hold any items and get stuck?

[Optera]

Can you explain in more Detail for what the Signal "Locked Slots per Wagon" can be used for.

Is it possible to use this signal to reserve one Wagon Slot to reduce the Delivery Size so Inserters are always able to complete the last inserter swing and not hold any items and get stuck?

This is exactly what this signal was made for.
There are still some situations where inserters can get stuck. They can be circumvented by increasing locked slots per wagon accordingly at the cost of reduced load.

• very high stack bonuses and/or 12 stack inserters/wagon can load more than one stack per cycle
• when loading with multiple inserters they sometimes start multiple stacks
• loading multiple items either requires count perfect loading or 1 additional free stack/item

[gexxo]

After updating this mod, it no longer seems to work as before.

My version before was one where the virtual signal "minimum delivery size" still existed, and after the update, the signal seems to be renamed to "Request Threshold". But it doesn't seem to work anymore. On a station with a request threshold of 4k iron for example, I now get deliveries with "1245 iron". I see that there is now also the "Provide Threshold" signal, which I do not use, yet. However, shouldn't one of these two be sufficient to trigger only bigger deliveries? I.e., shouldn't a delivery from station A to B have the minimum delivery size max(provideThreshold(A),requestThreshold(B))? This does not seem to be the case, currently.

[Odhrean]

This Thread is full If explanations, I.e. (just one page ago)

• If you want Deliveries of an item always of size 8k or more set the Provider Threshold on all Stations providing this item to 8k and the Request Threshold on the request Station to 8k
• If you want "Best Effort" set the Provider Threshold on Provider Station to 1 and Requester Threshold on Request Station 1 (the Deliveries are very small... better set it to 50 or something like this )
• If you have a Requester Station which should never provide Items set the Provider Threshold always to 1m
• If you have a Provider Station which should never request Items set the Requester Thresold always to 1m

You can control the complete behavior with the two virtual signals.

[gexxo]

This Thread is full If explanations, I.e. (just one page ago)

• If you want Deliveries of an item always of size 8k or more set the Provider Threshold on all Stations providing this item to 8k and the Request Threshold on the request Station to 8k
• If you want "Best Effort" set the Provider Threshold on Provider Station to 1 and Requester Threshold on Request Station 1 (the Deliveries are very small... better set it to 50 or something like this )
• If you have a Requester Station which should never provide Items set the Provider Threshold always to 1m
• If you have a Provider Station which should never request Items set the Requester Thresold always to 1m

You can control the complete behavior with the two virtual signals.

I read this post before posting, but it doesn't answer my question. It just describes the sitatuion where you have Requester Threshold AND Provider Threshold set to the same value. Never is it explained anywhere what the behavior is when only Requester Threshold is set (and thus Provider Threshold has its default value). It seems unnecessarily complicated to set BOTH. Or more formally asked: What is the relationship between provider and requester threshold? How do these values interfere with each other when they are not equal?

[sumdawgy]

Soo...

I suddenly have an issue where... My trains are taking EVERYTHING of the selected delivery instead of just the right amt.

to wit.. I have a station calling for 40 compressed stacks of iron.. the train proceeds to load untill the supply is drained.
THe logic is 1-until stacks >40
2-AND inactivity >2 sec
3-AND (timeout ticks)

The train is reading it's inventory. If i kill the 2nd logic line.... it rolls off and delivers. But the station Isn't. It's not killing the inventory to the filter inserters. I had a combined call for compressed iron & compressed CPU ....and killing line 2 helped but still went overboard on the iron thanks to LIFO in the warehouse stacks.....

I could temp fix it using the logic from the output lamp and train inv.... but that gets tricky with multiple loads on a train.

BTW is it not too much headache to give it a "no multiples" switch?
(At first glance.. it seems counter-intuitive but......)

[Odhrean]

Sorry that I only link posts, I am not at home and it is easier...
I think a decent wiki/explanation at OP is missing.

For now see this graphic, perhaps it will help you understand it more
viewtopic.php?f=94&t=36976&start=740#p285115

[Optera]

This Thread is full If explanations, I.e. (just one page ago)

• If you want Deliveries of an item always of size 8k or more set the Provider Threshold on all Stations providing this item to 8k and the Request Threshold on the request Station to 8k
• If you want "Best Effort" set the Provider Threshold on Provider Station to 1 and Requester Threshold on Request Station 1 (the Deliveries are very small... better set it to 50 or something like this )
• If you have a Requester Station which should never provide Items set the Provider Threshold always to 1m
• If you have a Provider Station which should never request Items set the Requester Thresold always to 1m

You can control the complete behavior with the two virtual signals.

I read this post before posting, but it doesn't answer my question. It just describes the sitatuion where you have Requester Threshold AND Provider Threshold set to the same value. Never is it explained anywhere what the behavior is when only Requester Threshold is set (and thus Provider Threshold has its default value). It seems unnecessarily complicated to set BOTH. Or more formally asked: What is the relationship between provider and requester threshold? How do these values interfere with each other when they are not equal?

You can't not have set these thresholds, there's always the map setting it will fall back to when no signal is given.

Your initial problem with 1k shipments stems from the map setting provider threshold of 1k.
Request Threshold determines delivery size when providers are overstocked. When they are low on stock you will get Provide Threshold sized shipments.

How they interact? They don't. They are triggers determining when a station is providing/requesting.

[Optera]

Soo...

I suddenly have an issue where... My trains are taking EVERYTHING of the selected delivery instead of just the right amt.

to wit.. I have a station calling for 40 compressed stacks of iron.. the train proceeds to load untill the supply is drained.
THe logic is 1-until stacks >40
2-AND inactivity >2 sec
3-AND (timeout ticks)

The train is reading it's inventory. If i kill the 2nd logic line.... it rolls off and delivers. But the station Isn't. It's not killing the inventory to the filter inserters. I had a combined call for compressed iron & compressed CPU ....and killing line 2 helped but still went overboard on the iron thanks to LIFO in the warehouse stacks.....

I could temp fix it using the logic from the output lamp and train inv.... but that gets tricky with multiple loads on a train.

BTW is it not too much headache to give it a "no multiples" switch?
(At first glance.. it seems counter-intuitive but......)

Check if your stop is set to read train content and if you have wired output and stop correctly to the arithmetic combinator.

[sumdawgy]

Soo...b
.........blah blah blah....

Check if your stop is set to read train content and if you have wired output and stop correctly to the arithmetic combinator.

Ya. It's reading content. BUT......
I just went back to page 35 on this discussion. I'm wondering.. was I using your version before .15.....

I never needed maths to do simple runs.

All I needed for early game...(I just started a new run for latest .15)..
For supply...I simply green wired my constant comb & wharehouse to input. Red wired my filter inserters to output. The signal(s) on the red wire auto-magically disapeared as train loaded. My requester stations just empty their trains.



))Also..I'm looking at pg 35 of this post and I'm going over diagrams there...((

[sumdawgy]

Check if your stop is set to read train content and if you have wired output and stop correctly to the arithmetic combinator.

so...I added the combinator...it works fine!

I don't think I was using your version of LTN originally..I'll have to look into that...

Regardless, I am happy you are making/maintaining it!
Thanks again!

[DaveSh99]

Hello,

Is there a way at a stop to read how much of things are available on the logistic train network? I.e, something like how you can determine how much of a thing is in the normal logistic network?

Thanks,

d.

ps, this mod is very cool, and works quite well.

[Optera]

Hello,

Is there a way at a stop to read how much of things are available on the logistic train network? I.e, something like how you can determine how much of a thing is in the normal logistic network?

Thanks,

d.

ps, this mod is very cool, and works quite well.

With the zoomed map view of 0.15 I always hover over a pole with the wire feeding into a stop to get stats/stop.

I don't plan to add an UI. Coming up with a design to present lists of items/station, potentially filtering for certain items, and implementing it with the limitations of the ui api seems like a lot of work I simply don't want to do.

[DaveSh99]

Ok, fair enough. Merely a curiosity.

Keep up the work on all of your great mods!