SSPP Logistics Train Mod

by jagoly

A logistics train mod that aims to be as pleasant to use as possible, even when knee-deep in byproducts. SSPP stands for Source-Sink-Push-Pull.

Content
11 days ago
2.0
584
Logistics Trains

g Minimum and maximum amount of items

a month ago

Thanks for the mod again, i'm enthusiatic about setting my network with it.

As I understood delivery size in network settings is a maximum amount of items that can be delivered at once. But what if i want to be able to deliver the maximum amount that's currently available but that is less then absolute maximum set? For example, i've set 1992 iron delivery size, and if i have it enough on one station it can be delivered, but what if i have 1892? I still want it to be delivered but no less then say 1000 items.

In CS I have an option to set a minimum amount for an item to be requested and the train will try to find any station that has enough and an option to set maximum amount by setting desired amount of stored items. So it means that difference between desired amount and amount actually in storage will be requested only if it is above the set threshold. For my example, if i set request threshold 1000 the train will go and pick up all available ore if a provider has it above 1000.

In SSPP (correct me if i'm wrong) the calculated deficit is basicly the same difference between wanted amount and amount actually in storage, but we don't set the desired amount in storage directly. Then I see that the delivery is requested only when deficit gets higher then delivery size for that item. This means that i should put delivery size as minimum deliverable batch (1000 in my example). But if I do that and I have surplus in the source I still get the minimum amount and the wagons travel half empty.

The problem is that sometimes i have enough items to deliver the full wagon, but sometimes i need to deliver at least the minimum amount. It's a common place for basic resources when you have to deliver coal to several places and the consumption is not stable so sometimes you have shortages or surplus

a month ago
(updated a month ago)

For many different reasons, deliveries in SSPP are a fixed a size. This makes the core algorithm a lot simpler, and more robust. One thing to understand is that, for a given item, delivery size should be set to a value which your network is actually able to produce in a reasonable time frame. At that point, where you are able to produce that item fast enough, the only benefit to using lower thresholds (delivery sizes) is that it reduces the the amount needed in storage at requesters. Likewise, if using a smaller delivery size, the only benefit to larger deliveries is having slightly fewer trains rolling.

By using a fixed delivery size, SSPP can be a lot more responsive and reliable. Just as one example, SSPP doesn't lock deliveries to a requester until they actually leave the provider. This means that if a dispatch is made to deliver to a low priority (sink) station, but in the time it takes the train to pick up those items, a higher priority (pull) station opens up, then the delivery will be redirected there. This and other things rely on consistent delivery sizes.

Basically, I would ask you to consider if a train delivering a low throughput item, meaning that there won't be that many trains overall, being partly empty is actually an issue. Likewise, for high throughput items, where by their nature as high throughput items overbuffering won't be a big problem, is actually an issue.

a month ago

Yes, it makes sense. I'm transitioning from CS and some things are not obvious.

Another thing i found is that a request amount at a station can't be lower then delivery size regardless of the numbers i put in throughput and latency. It means that delivery size is the exact quantity that will be delivered, contrary to my initial assumption of it as maximum deliverable quantity. So while in CS I set required amount for every station depending on expected consumption, in SSPP i need to consider overall production of this item. it also means that requested amount is just a multiple of delivery size and there's no need to think over throughput and latency much, i just need to guess how many batches equal to 'delivery size' i want in storage.

So if this logic is correct, then why don't you make a single counter in station menu for number of batches you want on this station like 1, 2, 3, 4 and move rather confusing throughput and latency calculations to network tab, where you set delivery size?

a month ago
(updated a month ago)

Because it is not that simple. Delivery size only sets a minimum - any station with significant demand will need more than that minimum. See this example from the mod page: https://assets-mod.factorio.com/assets/d1d358c64dd17562c51cf13296f99624b1ce1574.png

The delivery size of all three of these items is a full wagon, but the amount that needs to be buffered for each is not the same as they all have different stack sizes, and push/pull items need a larger buffer to allow temporal prioritisation of items coming from pull or going to push stations respectively. When I'm designing my factory blocks in YAFC or factory planner, I don't have a "buffer this many items value", I have a throughput value. SSPP lets you input that value directly, rather than requiring you to guess or calculate the buffer required yourself.

The system does have a tunable for when you specifically do want to buffer extra items (because your network isn't always running at full capacity, is still getting built, etc) - latency. With that, you are instead of putting in a "buffer x items" value, you are putting in a "buffer enough items to support (throughput) items per second for (latency) seconds", which I find to be generally more useful. You can also make use of a maths quirk to set a minimum count directly: if you set throughput to 1, then latency is now a minimum count. SSPP will try to ensure that the count of items in the station never drops below (throughput * latency).

New response