Question about provider threshold

[Jory]

Hello LTN veterans. I'm trying to do something seemingly simple, but cannot find a way to make LTN do what I want.

Lets say I have one requester station A that wants at least 1k engines per shipment (low consumer) and another requester B that wants at least 10k engines per shipment (high consumer). I put the requester thresholds accordingly.

Now, I have a single provider of engines, but what should I set as provider threshold? If I put it at 1k it can create an order of 1k engines to B which I don't want. If I put it at 10k it won't create an order to A until it has at least 10k engines which is also not what I want.

Is there any way to do this simple task? And related question, why is there a provider threshold at all? Would it not be better that the requesters are the one controlling this by setting a minimum amount? What am I missing here?

[mrvn]

Option 1)

Set Network ID 2 on station A and Network ID 1 on station B. Set the provider to Network ID 2 and provider limit 1k. Add a decider combinator "engines >= 10k ==> Network ID 1" and connect it to the input lamp of the LTN stop.

Now A will get their 1k engines whenever needed and B only gets engines when 10k are ready. Problem is that A might starve B, you never get 10k engines ready.

Option 2)

Same as 1 but actually build 2 stations and split the engines between them. This avoids the starvation problem or you can use the splitter priorities or circuit logic to decide which station gets engines first or in which ratio.

Option 3)

You need my patches for multi-stop stations for this (initially mend to stations accessible from two directions).

With my patch stations (not depots) are allowed to have the same name if and only if they are connected by a circuit wire. The wire is there to exclude accidents. With that you can make 2 stations, one providing 1k engines and one providing 10k engines. But one of them is a dummy station that isn't even no the rail network. Just place it next to the real station with a single rail tile, connect them with a wire and connect the buffer chests to both of them. Both need to have the same name. Then when LTN schedules a train to either of them it will always arrive at the real station. The dummy station is just there to give another set of limits.

Still a starvation problem like Option 1. It's more useful for requesting stuff with different limits, networks or priorities. Or all of that combined.



Overall I recommend simply setting the provider limit to 10k. Station A will only get engines when 10k are provided but it will only take 1k. So it should quickly fill back up to 10k. That is unless station B takes the full load. Over time it really doesn't matter. The throughput is the same.

[Optera]

You need my patches for multi-stop stations for this (initially mend to stations accessible from two directions).

Just to let you know. Promoting and sharing custom forks is in violation of my license.
https://github.com/Yousei9/License/blob ... LICENSE.md

[Jory]

Thank you for your suggestions. There is no elegant solution with other words. Option 1 and 3 does not scale well if we have say 20 requesters and providers for the same item while Option 2 is working against the very idea of LTN.

I guess what I wish for is a minimum amount input for all the requesters and the providers simply trying to fulfil what the requesters are requesting abiding to their minimum amount. And controlling who gets the shipment first with priority should multiple stations lack more than their minimum amount requested.

For example if I put higher priority on station B, and station A wanted 2k engines (1k minimum) and station B wanted 78k engines (10k minimum) and the provider had 6k engines it would wait until it had 10k engines before sending the train to B. And continue save up engines for B until it no longer want any more engines. Then and only then start serving station A.

But I guess this is simply not how LTN works. For now I will go with your final suggestion and put the provider threshold as the maximum of all the requester thresholds. It's the only reasonable way if we want efficient trains. But that begs that question, why we have provider thresholds at all if it can be calculated by the system itself?

Thanks.

[mrvn]

You need my patches for multi-stop stations for this (initially mend to stations accessible from two directions).

Just to let you know. Promoting and sharing custom forks is in violation of my license.
https://github.com/Yousei9/License/blob ... LICENSE.md

And that's why it isn't available on the mod portal or accessible to the public. It sucks because I would like to use the feature in multiplayer games too.

But maybe if I promote it more (and I see nothing in the license about that) people will ask you to merge it and make it public.

[mrvn]

Thank you for your suggestions. There is no elegant solution with other words. Option 1 and 3 does not scale well if we have say 20 requesters and providers for the same item while Option 2 is working against the very idea of LTN.

I guess what I wish for is a minimum amount input for all the requesters and the providers simply trying to fulfil what the requesters are requesting abiding to their minimum amount. And controlling who gets the shipment first with priority should multiple stations lack more than their minimum amount requested.

For example if I put higher priority on station B, and station A wanted 2k engines (1k minimum) and station B wanted 78k engines (10k minimum) and the provider had 6k engines it would wait until it had 10k engines before sending the train to B. And continue save up engines for B until it no longer want any more engines. Then and only then start serving station A.

But I guess this is simply not how LTN works. For now I will go with your final suggestion and put the provider threshold as the maximum of all the requester thresholds. It's the only reasonable way if we want efficient trains. But that begs that question, why we have provider thresholds at all if it can be calculated by the system itself?

Thanks.

The thresholds are there to add the request/provide into the list of things LTN checks. One main effect of this is that when you get 20 items more than requested you don't suddenly start providing them back. The other to limit the frequency of trains in normal situations.

The amount LTN will ship is the minimum of requester, available items and available trains. But only once the station is above the provider limit. In many cases you want the limit to be a full train and LTN could compute that itself. But then you have low throughput station where you request 200 transport-science-packs. How should LTN know you want to ship transport-science-packs as single stacks? Only idea I have in that direction is to make it based on time. Have it ship those science packs after 10 minutes no matter how many there are.

It could make sense to set a minimum cargo amount on the requester that really says: Only send a train if it has at least this many items. A side effect of that though would be that when B wan't it's 10k minimum cargo then all engine producing stations would stop providing engines till one of them hits 10k. And then you get a flood for all the other stations that only want 1k minimum draining all the buffered engines. Thundering herd style. Rinse and repeat. Setting the provider limit at 10k means you always buffer that much but the deliveries are less clustered. So first I said "Yeah, need this too" but after writing about it I'm not so sure. Maybe a 10k provider limit is better.

[Optera]

You need my patches for multi-stop stations for this (initially mend to stations accessible from two directions).

Just to let you know. Promoting and sharing custom forks is in violation of my license.
https://github.com/Yousei9/License/blob ... LICENSE.md

And that's why it isn't available on the mod portal or accessible to the public. It sucks because I would like to use the feature in multiplayer games too.

But maybe if I promote it more (and I see nothing in the license about that) people will ask you to merge it and make it public.

Merge what?
You never bothered updating your pull request to dev head like i asked you back while it was somewhat up to date.

I still don't see merit outside the edge case of allowing stops being placed in front and back on one platform.
Two way stations are a lot less effiecient than one way roro. Why make LTN more complicated just to allow an edge case no one but you seems to even care about?

[Jory]

The request threshold already is doing a good job to limit the frequency of trains. Why would I also want to set a providing threshold that is impossible to figure out since I'm supposed to serve both low throughput stations and high?

At first I figure I should put all providers with provider threshold of 1. And just let the requester decide on how much they want. This doesn't work however since if the requesters are asking for a lot but the provider only have one item, it will send this one item EVEN THOUGH the request threshold is 1k or whatever.

I guess what could solve it is a global setting:
- Never dispatch an amount less than the request threshold

Isn't this both what you expect and want in most cases anyway to avoid a lot of almost empty trains? I'm sure there is a good reason why this is not how it works, but I'm having a hard time to wrapping my head around it. The current system is symmetrical but the situation between a provider and requester is inherently not a symmetrical situation. A requester knows what he wants to do with the items and so have a position where it can decide the size and limits of the shipments. A provider does NOT have this information on its own. So why should the provider set his own limits?

[mrvn]

You need my patches for multi-stop stations for this (initially mend to stations accessible from two directions).

Just to let you know. Promoting and sharing custom forks is in violation of my license.
https://github.com/Yousei9/License/blob ... LICENSE.md

And that's why it isn't available on the mod portal or accessible to the public. It sucks because I would like to use the feature in multiplayer games too.

But maybe if I promote it more (and I see nothing in the license about that) people will ask you to merge it and make it public.

Merge what?
You never bothered updating your pull request to dev head like i asked you back while it was somewhat up to date.

I still don't see merit outside the edge case of allowing stops being placed in front and back on one platform.
Two way stations are a lot less effiecient than one way roro. Why make LTN more complicated just to allow an edge case no one but you seems to even care about?

For the other edge case of wanting one limit for good A and a different limit for good B as in this thread. Although I'm still thinking there must be a better way for this than having a dummy station that's unreachable. Would be nicer to have just multiple LTN-Combinator like entitites connected to a stop and each configures a specific set of limits, requests and provides. But that won't work with signals as they just get added together.

Sorry for not updating the pull request. You didn't sound optimistic about merging it so it got a low priority. And then I was only playing multiplayer without the patch so I haven't used it in a while myself. You still don't sound encouraging and it is indeed a big complication to the code.

[Optera]

LTN 1.11 finally reached a stage where almost all bugs have been ironed out and even my perfectionism allows me to call it feature complete.
Just skimming over all the countless changes made in your pull request, make me shudder at the potential bugs these deep changes to a core mechanic might introduce.
I hope you understand that I am less than enthusiastic about merging such fundamental changes at this point. Especially considering the benefit is allowing a single use case most players won't ever make use of.

[ptx0]

Just to let you know. Promoting and sharing custom forks is in violation of my license.

oh, sorry, you are hosting your code on Github and have agreed to their terms which include a "right to fork" the code, as it is published publicly on their platform.

[Jap2.0]

Just to let you know. Promoting and sharing custom forks is in violation of my license.

oh, sorry, you are hosting your code on Github and have agreed to their terms which include a "right to fork" the code, as it is published publicly on their platform.

Right to fork != right to distribute.

[Optera]

Jap2.0 is 100% correct.

I'm closing this thread before this derails into another debate about licensing from someone who clearly has no idea how licensing works.