Wait condition: "Full Items" / "Full Fluid" for mixed cargo/fluid trains

[K4i]

TL;DR

Add train capacity-based wait conditions to make schedules work cleanly with mixed fluid/cargo trains across different wagon qualities.

What?

For my uranium mining outpost, I run trains that deliver sulfuric acid and pick up ore — one schedule, two conditions: fill fluid on the way out, fill items on the way back. I built this with Item count and Fluid count conditions using hardcoded numbers.

With quality cargo/fluid wagons, a wagon's capacity is no longer fixed, so those hardcoded counts break as soon as I mix wagon qualities. To get the same behavior I'd need a separate schedule per quality combination, which doesn't scale.

The existing "Full cargo" condition already solves the "no hardcoded numbers" problem, but it ANDs fluid and item fullness together — it fires only when both are full. That doesn't fit my case, where I want fluid-full/items-empty outbound and items-full/(fluid-empty) inbound.

Suggestion: add "Full Items" and "Full Fluid" as separate wait conditions, so a train fills/empties fluid and items independently. For symmetry with "Full/Empty cargo," an "Empty Items"/"Empty Fluid" pair could be added too — though this is already achievable today with Item/Fluid count conditions set to 0.

I also thought about a wildcard signal Item/Fluid capacity so it can be used in the existing Item/Fluid count conditions. This could work for Fluid capacity, but Items are bound to the number of stacks and stack size varies per item. A Stack capacity signal isn't very useful without a way to multiply it by the relevant item's stack size — and it breaks entirely if a train carries multiple items with different stack sizes.

Why?

This is a small improvement that would make schedules reusable across quality tiers for mixed fluid/cargo trains, without forcing players to maintain hardcoded values and a separate schedule per quality combination.

[worph]

+1
I think the baseline usecase, mixed cargo/fluid wagons, is enough to warrant this already. Without even considering quality (which of course makes it even more useful).
I hate having to input numbers, when an intuitive (similar) setting is right there.

[Brathahn]

have you tried the "inactivity" condition in combination with "has cargo" ? with this you can easily detect a full train of mixed ores or fluids.

[robot256]

+1

The most basic application is a uranium mine outpost train with a fluid wagon of acid and cargo wagons of ore. You want to leave the base when fluids are full and items are empty. You want to leave the outpost when items are full or fluids are empty. Inactivity isn't what you actually want in either of these cases.

[Dfq]

+1

Did not know I needed this feature as I have always worked around it, but it is indeed tedious and this would be a simple yet very significant QoL feature. Do want.

[redrook]

Maybe it could be generalized in the form of "Full [x]" where [x] is a select of any item or fluid.

Then fullness is determined automatically on the basis of how much of [x] the train can possibly fit:
1. for fluids it's just total capacity of all fluid wagons
2. for non-fluid items it's a sum: all slots filtered to that item + all slots without a filter

That way mixed solid items trains with different pick up / drop off locations will also work so long as the user sets filters for all item types.

That brings the question though what happens today when a wagon with filtered slots gets upgraded to higher capacity? Are all new slots just unfiltered or they get assigned filters (or lack of it) proportional to the prior assignment? Seems like without the latter an upgrade would be breaking trains - when every slot in every wagon has a filter often that means they actually have to have filters and clogging a wagon like that up with random other items might create a disaster.

If it's the latter (new slots are assigned filters proportionally), then an alternative to (2) becomes meaningful: if there is no slot in any wagon filtered to [x], "full" for [x] is all unfiltered slots, otherwise it's the capacity of all slots explicitly filtered for [x] (so either / or, not the sum). This is all to see how this new condition can have useful AND/OR combinations with pre-existing "full cargo" condition, as well as coverage of use cases.

[worph]

Maybe it could be generalized in the form of "Full [x]" where [x] is a select of any item or fluid.

I like this, it would be kind of similar to "request satisfied" on platforms, where you can select a specific item. Just one for full and empty each.

[Mar_Veloz]

+1

I would also find this helpful

[K4i]

Currently, upgrading a cargo wagon with filters only adds new slots without filters, and I don't think that will change. E.g. for a construction train with 10+ different filters, upgrading from common (40 slots) to uncommon (50 slots) makes it impossible to determine what the 10 new slots should contain. A "Full [x]" condition could help here, but upgrading filters themselves will probably always need to be a manual process.

Personally, I try to avoid setting filters because it's a tedious process. In my initial example I don't even need filtering, since the wagons only carry uranium. "Full Items" would be an easy setup, no filtering needed, and it works regardless of quality. It wouldn't work for a mixed-item train that's only partially filled though, e.g. item X inbound / item Y outbound.

Another edge case is mixed-quality cargo wagons, e.g. quality mining directly into a train. This most probably will never fully fill a Train because of the statistical distribution (e.g. only one legendaray item in a stack).This is where my idea from the first post might help, if the logic is based on slots rather than item count since stack size can vary between different items. Something like a "Full Stacks / Occupied Stacks" wait condition, combined with a "Stack Count / Filtered Stack Count" signal. That's a more complex solution, though.

One small addition to my initial idea: I think all current cargo conditions (Full Cargo, Empty Cargo, Has Cargo) would benefit from this items/fluids-based approach. That might overload the UI with too many options, though. An alternative would be to add a dropdown to the existing condition, so "Full Cargo" could be switched to "Full Items" or "Full item x", similar to how the "Station is full" condition can be parametrized with the stationname afterwards

[redrook]

Sounds like what we are looking for is "Room for [x] [comparison] [value]" - where "Room for [x]" is populated to how many more units of items or fluid of type [x] the train is capable of housing.

"Room for [x] = 0" is expected to be often used for materials filled up by inserters or pumps, and "Room for [x] <= S" for some small S for materials chuted directly into wagons by mines (or any other buildings with chute outputs) that do stacking. Can also be used to bypass slowdown of pumps when fluid tanks are almost full.

In case of items "Room" is total remaining space in wagons that is currently available across (1) empty slots with no filter + (2) slots partially filled by [x] + (3) slots with filter of type [x]. [1]
In case of fluids that's total remaining space in those fluid wagons that are either (1) empty or (2) already contain some amount of the same fluid.

Notice that the condition is quite dynamic - if the train has first visited some other station and it filled it up partially, this will be targeting the remaining capacity, just like "Full Cargo" does, except the condition is filtered - storage of wrong type (fluid vs items) doesn't need to fill up, and wagon slots explicitly filtered to items of other type don't have to either.

On the other hand it's familiar as it's just the opposite of "Has [x] [comparison] [value]" already available.

This works with upgrading trains that have filtered slots too - the fact that extra slots added during the upgrade that lack filters will just get filled up by whichever item is loaded into the train first will neither cause a deadlock on the next item (filled up slots to do not contribute to "Room") nor result in complete underutilization of the train's new capacity (the first item will use the space).

[1] I'm assuming here that buildings that direct chute stacks of items can distribute the stack across multiple slots (imagine a wagon with 4 slots filled by 99 items each and no other slot available, I'm assuming a machine that always produces stacks of 4 will not block targeting a wagon like that).

[redrook]

I misunderstood the corner case with quality, the problem isn't with stacking (from stack inserters and stacking by mines), it's with the sushi-character of output of buildings with quality on them.

It's interesting, so to simplify let's say the entire train has 2 slots, one slot already has 1 legendary item of type X, and the other - 1 common item of type X, what is "Room for [x]" (with "x" of "any quality")? 198, 99, or 0?

[redrook]

I'd say if the condition is "Room for [x] [condition] [value]" where [x] is specified with "any quality" the condition is true whenever there is a quality level for which it's true. If [x] is specified with a specific quality level, what is "Room for [x]" is well-defined as per prior definition.

Let's debug that in the case of a quality mine directly mining into a wagon. Say the condition is "Room for [x:any_quality] = 0". One high quality item is produced and occupies the whole slot, every other fully fills up with items of normal quality. The condition is true for normal quality, it's satisfied. but only after the slots for normal quality full fill up, no gaps.

If there is only 2 slots, and they get 1 item of legendary, and 1 item of uncommon, while the mine produces mostly normal quality, there is no deadlock either - the condition is true for all quality levels except legendary and uncommon.

However, if there is a slot partially filled for every quality level, the condition is not true for any levels, and thus overall condition is false. Which is correct - a wagon like that can still accommodate extra items of type [x] regardless of what quality they come out with, including normal.