All good.

The wildcard signal seems to imply that it will match the first signal that passes the wait conditions.

You are not using any signals in wait conditions.


Given the detail in the post above, would you agree that the UI tooltip should reference the interrupt conditions, not the wait ...

OK. So if I associate numbers with each resource, e.g. iron , stone, coal, copper, as numbers < 50, and all fluids as numbers over 50, then indeed, the system begins to work as designed. Wait conditions are indeed not part of the calculation, as specified on the tooltop, but interrupt conditions. To ...

OK. Odd. But OK. So all labels are equal and only the numbers matter?

Regarding the alternative of testing <Circuit parameter> > 0, that achieves the same end result. I tried any number of permutations of these options. I'm still confused about the text about wait conditions causing signals to be ...

If I try this, I still don't get the B signal, which should be the signal passing the condition.

When using as wait condition, you still have not set any circuit condition as wait condition.


I tried to incorporate the wildcard signal into a wait condition, but, as can be seen, the ...

Now create a description yourself and you will find it's extremely difficult to find a short one that's explaining this. It's quite possible you end up with the current one.


Thanks for taking the time to explain this in detail. For the signal wildcard then, what you say suggests the following ...

Just noticed the term 'wait condition' here.

OK.

Where should I set wait conditions?
What does a circuit condition look like?

I'm clearly misunderstanding the absolute basics here, so it's no surprise I'm failing.

If I try this, I still don't get the B signal, which should be the signal passing the condition. I still just get the first signal, A, from the incoming signals.
These are the signals in this test:

I can't define a signal like A to equal water, so I don't see how using the letter signals could work. Is there an example somewhere of how this is intended to work? I feel like seeing one, or possibly multiple, examples of these wildcard signals in action would really help.

I see the 'signals' section. Will play.

Huh. OK. This could be the issue. So ... what would that look like? I was thinking that the signal coming into the station was being evaluated against these conditions, thus the qualified as signals in wait conditions.

How can I incorporate a signal in the wait condition then?

I could create a huge set of decider combinators, one per fluid in the game, to filter out all fluids from the list of incoming signals. This then works. But then, what is the meaning of the text on the UI about selecting the signal that passes the wait conditions. Which conditions if not the ...

There is a stone signal.

The wildcard signal seems to imply that it will match the first signal that passes the wait conditions. To me, it looks like only water should actually pass the wait conditions. So I expect my train with fluid wagons to be able to be controlled to only go to fluid stations ...

Tried this also .. no joy

Tried the condition elements the other way around in case that would help. Same result.

Thanks for trying to help.

Both interrupt setups create the same situation:

So - I tried this as an alternative - following a suggestion that the condition should include the wildcard, but if that's the case, I'm doing it wrong ...

The question is really about the specific meaning of the text on the wildcard signals. To give a concrete example, we have:

11-07-2025, 23-13-23.png

It says it will match the first signal that passes all wait conditions. I'm assuming it means the wait conditions for the interrupt. If so, then ...

In case anyone else finds slidey belt animations a bit odd, this setup seems to fix it, just to keep the belt less than full permanently.