Feature Request: Specify Thresholds as Stacks

[Gullyn]

In my play-through of Sea Block I'm running into a challenge with provide and request thresholds. I have stations that provide multiple items like barrels and ores. Barrels stack to 10 and ores stack to 200. I want to use the trains efficiently so I want to have full cargo wagons. If I specify the provide threshold as, say, 10000 then barrels will never be picked up (or I will have a huge surplus before they are). If I specify the provide threshold as 200, then barrels are regularly picked up but I have mostly empty trains delivering ores.

I'd love to be able to specify a provide/request threshold as stacks as an alternative to number of items. I could set a "provide stack threshold" as 50 which would work for barrels and ores. No more mostly empty trains when requesting/providing ores.

Thanks for your consideration and creating LTN!

Gullyn

ps. The other feature request I had was apparently implemented today as the new "LTN Content Reader" mod. Amazing work!

[Optera]

I kept playing with the idea of adding stack thresholds in some form for a while. So here's my thoughts about the pro and cons of the two methods i came up with.

Toggle option for current thresholds:
I think this would be very confusing. The same threshold would be read as stacks for items while it'd be read as absolute number for fluids.
When changing mode from item to stack LTN would basically stop shipping items until threshold values are lowered. In the opposite direction LTN would run amok sending mini shipments everywhere.

Adding stack threshold signals:
While it's easier to migrate and even implement, the problem with this is what to do when there's both stack and count threshold signal.
If count threshold signals are ignored for items when there's a stack threshold that'd work great as it'd open up count thresholds being used for fluids while stack thresholds are used for items.
Then again this would be very confusing for players already struggling wrapping their head around thresholds as they are.

If enough players want this I would implement the 2nd option with new stack threshold signals overriding count thresholds for items.

[Gullyn]

It seems that option #2 "Adding stack thresholds signals" is the path of least resistance. Admittedly, I hadn't given any thought to how fluids would be handled since I (currently) always barrel But what you propose seems reasonable since it isn't logical to apply stack values to fluids. It also seems unlikely that a stop would provide items and fluids at the same time (no doubt someone is doing it but I suspect they'd be an advanced player anyway).

It is unfortunate that this feature probably won't help with confusion regarding thresholds but I think there will always be that gap. I will certainly be happy to chime in if someone has a question regarding stack vs item thresholds.

If you have any kind of bounty open for this feature I'd be happy to contribute to it. If not, you have my many thanks for creating LTN and considering (and hopefully implementing) this feature.

[MisterFister]

I'm moved to consider that for the OP's issue of providing ores and barrels from the same stop, the solution would be to create parallel stops at the same outpost location, each one keyed to its own resource. (This may or may not perform well when interleaved with separate LTN network IDs, depending on the factory's use-case circumstances.)

Generically, this suggests that if a factorian were to prefer omni-stations as a practice, then I imagine a trifurcated set of stop form factors -- those being tanked fluids, barrels, and non-barrel beltable items (one can get into the weeds based on stack-sizes, though I submit that since many mods manipulate stack size maximums, there is no universal "best practice" when it comes to this.)

Perhaps all of the above can be streamlined with a constant combinator setting? We already have signal flags for depot / requester / provider and train-composition metadata. Why not allow for an in-game user-configurable global setting wherein the player can specify "since all iron ores stack to 50, I want all raw iron amounts to be transacted for LTN-computation purposes as ([iron ore] / 50)," particularly in that there is a filtered-wagon-slot flag already possible. For tanked fluids (perhaps crude) the user can global-set all increments as ([crude] / 25k), thus scaling deliveries in increments of tanker-wagons. Etc...

[GrumpyJoe]

If I specify the provide threshold as, say, 10000 then barrels will never be picked up (or I will have a huge surplus before they are). If I specify the provide threshold as 200, then barrels are regularly picked up but I have mostly empty trains delivering ores.

sorry to dig that up again, but i was just browsing through and its not THAT old

I recently had the same "problem" with a station that wasn´t really meant to be supplied that way, but i was lazy.
It contains slag and barrels (same problem)

It works pretty well with this workaround:
Signal from warehouse into:
Decider combinator; "Barrels > 0; Output Barrels, input count" --- this is to seperate barrels from slag signal (could also be an arithmitic, Barrels *1 or barrels +0), signal joined by slag after that is sent through the following:
Decider combinator; Slag > "insert provide threshold of higher stacked goods" (mine is 32k because of 2xMK3 wagons)"; Outpout Slag, input count --- this only puts slag on the wire if its sufficent to fill the train, otherwise the station gets a 0, not sending trains to pick up only 1000 slag


It shouldn´t be too heavy on circuit network updates, as i dont´t think one will have multiple stations that are so mixed up in stack sizes.
At least i hope I wont

[jaakon]

If enough players want this I would implement the 2nd option with new stack threshold signals overriding count thresholds for items.

I've asked a different thing some time ago, which couldn't be implemented. My problem was quite the same as here and this solution would also work greatly for me, so consider me a +1

[rdrunner]

Hi

I have a (slight) problem:

I have a station requesting barrels and iron... While barrels are a lot smaller in stack size than iron plates, i thought i could get away with setting the provider limit of my smelter to at least an ok amount (8k) while the request limit for that station is 400. Sadly the request for iron gets filled and trains arrive with 425 iron (doh).

So now I am thinking:


- Why is my provider providing even if his limit is not reached? Is this behavior by design?



Workarounds i dont like:

- Remove the exact order count from my iron provider, delivering full trains only.
- Build a 2nd station for bulk goods


Real solution i would love:

- Request limit for "stacks" vs items (Fluid stack would be abut 10 barrels worth or 2.5% of a tank, or add an additional fluid overwrite for requests)

[Optera]

merged into Request topic

[torne]

Adding stack threshold signals:
While it's easier to migrate and even implement, the problem with this is what to do when there's both stack and count threshold signal.
If count threshold signals are ignored for items when there's a stack threshold that'd work great as it'd open up count thresholds being used for fluids while stack thresholds are used for items.
Then again this would be very confusing for players already struggling wrapping their head around thresholds as they are.

I thought of a third option that might work, similar to your second option: add two new control signals (for each of request/provide), one called "(request|provide) item stack threshold" and the other called "(request|provide) fluid threshold". Deprecate the current control signals (e.g. rename them to say "Old request threshold, DO NOT USE" or whatever): allow them to continue working as-is for now, but put the stop into an error state (like the existing coloured lamp error states) and disable it if any of the "new" threshold signals are set on the same stop as any of the "old" ones.

That way people can convert their network incrementally, and by having the two new signals explicitly refer to "item stacks" vs "fluids" it makes it clearer that they are for two separate use cases, rather than having one of them override the other.

(then eventually you could remove the old signals entirely if you feel like doing a "major" release of the mod that doesn't guarantee old networks will function unchanged)

[Optera]

How is ending up with 4 new thresholds + 2 old deprecated ones simpler than just adding item stack thresholds directly?

[themadgunman]

+1 to the idea of having a separate fluid/item thresholds for stations with multiple resources, it would be ideal to set threshold per item but thats a lot more complicated to implement i suspect so just using stacks would also be excellent so you could provide multiple resources with different stack sizes to/from the same stationl

[torne]

How is ending up with 4 new thresholds + 2 old deprecated ones simpler than just adding item stack thresholds directly?

Because each of the new ones can be clearly described and given a straightforward name, instead of it being "it uses the threshold, unless there's a stack threshold in which case it uses that instead, unless it's a fluid in which case it just uses the regular one". Having fewer things isn't automatically simpler than having more things - overloading the meanings of controls to have fewer controls makes things complicated too.

Or to put it another way: just adding an item stack threshold means that the meaning of the existing threshold signal changes depending on whether there's also a stack threshold; if there is, then the threshold signal is just for fluids, and if there isn't, then it's for everything.

I haven't touched the mod API in a while so I don't know this offhand, but is it possible to hide signals in the same way as recipes, so that they still exist (and will work on combinators or blueprints that already have them set) but don't show up as choices in the GUI picker when configuring a combinator? If that's possible then the deprecated signals can just be hidden that way, so that anyone who's starting from scratch never even has to know they existed, and people with existing saves won't ever see them again once they've reconfigured their existing stops/blueprints.

[steinio]

The funny thing is, that stack threshold = item threshold * stack size and you can calculate it quickly in your head. Just saying.

[Ranakastrasz]

The funny thing is, that stack threshold = item threshold * stack size and you can calculate it quickly in your head. Just saying.

Reread OP and try again. The issue is related to train conditions, and involves trains with mixed cargo types with different stack sizes. The player does not interact with it in any way.

[Optera]

Good new everyone.

I've successfully broken LTN code into more manageable modules, made the interface more in line with normal factorio data models and, what most in this thread want to hear, added stack provide threshold and stack request threshold signals.

They work as outlined by me before:
- When a stack threshold signal is set items will use that regardless of old stack signals set
- Fluids still only use the old threshold signals

[themadgunman]

Sounds sweet, Is there going to be a default stack size threshold option so i don't have to individually adjust every station when i upgrade my trains to MKII/III cargo wagons ?

[Optera]

No.
Stack size Thresholds are signals only, the fallback is normal thresholds and those fallback the map setting.

[themadgunman]

Oh well, it doesn't hurt to dream the separate options for stacks/fluids is awesome though

[GrumpyJoe]

Sounds sweet, Is there going to be a default stack size threshold option so i don't have to individually adjust every station when i upgrade my trains to MKII/III cargo wagons ?

I got a "C" signal, representing stack capacity of wagons, at each station that goes into treshold calculations.
At the beginning i just gave that a constant combinator input, but later i connected all of them to a global circuit network.
When the wagon upgrade at the depot is done, i only change one combinator that sets them all to the new tresholds

[themadgunman]

I got a "C" signal, representing stack capacity of wagons, at each station that goes into treshold calculations.
At the beginning i just gave that a constant combinator input, but later i connected all of them to a global circuit network.
When the wagon upgrade at the depot is done, i only change one combinator that sets them all to the new tresholds

Your idea would do what i wanted, but it would also mean having to adding at least 1 more combinator and extra circuit fiddling at every station, what i was hoping for was some sort of Provide/Request "X" Stacks signal so that "X" could be set in settings and supplied to the LTN stop instead of a threshold signal, that way all 100+ of my stations could be adapted to a wagon size change in about 2 seconds. I suppose i could connect all the stops together and then just use a single Stacks Threshold signal for all of them but that brings its own problems cuz I would then have to filter out all the unnecessary signals each stop. Hopefully Optera will upload the new version soon so we can play with it and see what works best