[2.1.13] "Any request not satisfied" condition only cares about requests for the current planet

[jaladreips]

What did you do?
I added the "Any request not satisfied" platform schedule for a platform that is orbiting Aquilo and has unsatisfied request for an item set to be imported from Vulcanus.

What happened?
The condition was not satisfied.

What did you expect to happen instead? It might be obvious to you, but do it anyway!
I expected the condition to be satisfied.

Does it happen always, once, or sometimes?
Always


Screenshot of the situation:

08-05-2026, 23-31-06.png (555.72 KiB) Viewed 445 times

I didn't know if this is a bug or is this intentional (then I would create a suggestion to change it), but:
- the naming of the condition is terrible if it the behavior is intentional
- there are no dedicated conditions for checking unsatisfied planet requests (there is only "Any platform import zero" that requires the item count to be 0, but not "unsatisfied", also it's interrupt only)
- what would be the use case of the condition then? The platform is already stopped at the planet the request is for, why would the player want it to leave?

[Nidan]

- the naming of the condition is terrible if it the behavior is intentional

Clarifying that "All requests satisfied" and "Any request not satisfied" are about importing items from the current location would certainly help.

- there are no dedicated conditions for checking unsatisfied planet requests (there is only "Any platform import zero" that requires the item count to be 0, but not "unsatisfied", also it's interrupt only)

do you want your platforms to leave and fetch more, as soon as a single item is missing? in 2.0, only fetching a rockets worth of new items once the the current stock is exhausted seems the most economical to me. 2.1 might change things a bit, but still, only fetching new stock once you've run out minimizes travel.
If you still want to leave before an item is out, you have the "item count" condition.

- what would be the use case of the condition then? The platform is already stopped at the planet the request is for, why would the player want it to leave?

Because at some point you're done loading up and want to deliver those items.

[jaladreips]

do you want your platforms to leave and fetch more, as soon as a single item is missing?

Yes, I would pair it with inactivity to make it into "if it's not doing anything and a single item is missing, it should go and get it".

in 2.0, only fetching a rockets worth of new items once the the current stock is exhausted seems the most economical to me. 2.1 might change things a bit, but still, only fetching new stock once you've run out minimizes travel.

At some point in the game rockets are cheap enough to not care and if you're moving legendary items then it's common to have minimum payload set to 1 anyway.

If you still want to leave before an item is out, you have the "item count" condition.

It makes sense for one item kind, but for 20+ different items it's very unwieldy and not in the spirit of Factorio (that's the reason "Trash unrequested" was added)

Because at some point you're done loading up and want to deliver those items.

"Any request not satisfied" doesn't help you with that.

[Nidan]

Because at some point you're done loading up and want to deliver those items.

"Any request not satisfied" doesn't help you with that.

It's the negation of "All requests satisfied"; you might need negations sometimes to transform your wait conditions into disjunctive normal form (which is the only thing the game allows). And if your wait conditions have a branch for leaving early, you'll have to use it directly.

[robot256]

Wouldnit be correct summarize like this? This report is basically a suggestion that those entries be reworded as "All/Any *active* request not/satisfied". Active meaning any request that is not grayed out at the present space location. This is what was implied and could easily be made explicit.

[boskid]

I am not seeing any bugs here. If a request is set to import from vulcanus, then it behaves as if it was non existent while platform is over aquilo. Rationale for this behavior is that since the request is inactive, it would not cause items to be requested and because of this there is no expectation that the request would be fulfilled at some future point in time.