Parametric Signals - Is there a bug, or am I misunderstanding them?

[TurtleZ]

Incidentally, why does it evaluate Coal(1) as equal to Iron(1) here?

This is because of how the circuit network works. The network isn't comparing Coal(1) and Iron(1) - it's comparing (1) and (1).

Maybe think about the signals as being labels for the number. The circuit looks up the value for the signal labelled Coal, then looks up the value for the signal labelled Iron. Since both values equal 1, the condition returns true.

I think this is the fundamental reason you're getting confused with your other conditions - The condition "<Circuit parameter> == Stone", for example, will always be true for the substitution of Stone for the parameter, since you're comparing it against itself. This explains why the interrupt triggers for the stone signal even when it's not present.

Maybe the condition you're looking for is "<Circuit parameter> > 0". This will trigger the interrupt whenever the signal value is present at the station.

[SpoonUnit]

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 replaced, but now you make me think that perhaps if I tried to use other numbers than 1, perhaps I could achieve the requirement. I'll test that; assigning a different number to each resource type.

Thanks for trying to help.

[SpoonUnit]

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 be clear, if I have the following inputs:

11-09-2025, 16-08-09.png (14.83 KiB) Viewed 174 times

Along with this interrupt configuration for items:

11-09-2025, 16-09-02.png (65.39 KiB) Viewed 174 times

and this for fluids:

11-09-2025, 16-10-33.png (61.38 KiB) Viewed 174 times

Then the interrupt conditions correctly reduce the incoming signal list and replace the wildcard with the first matching signal that passes the interrupt conditions.

This is the text on the tooltip for the wildcard again:

"When used in schedule interrupt, it will match the first signal that passes all wait conditions and replace the signal with that signal"

This can't be true as the wait conditions are populated at the point the interrupt conditions pass. So the text should read:

"When used in schedule interrupt, it will match the first signal that passes all interrupt conditions and replace the signal with that signal"

Give that 'Conditions' appears twice on the same UI panel, in order to make this information unambiguous, perhaps the top conditions could also be labelled 'interrupt conditions' ?

[SpoonUnit]

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 conditions? If so, should I log a bug now?

[Tertius]

This actually happens:

• when the game engine is about to check and process the interrupts, before processing the first interrupt, it creates one replacement for each of the 4 wildcards and stores these 4 replacements.
• for the circuit wildcard, it looks into the current circuit connection of the train(**) and selects the 1st signal according to the internal signal order(*) as replacement. If there is no signal, the wildcard gets no replacement.
• for the cargo wildcard, it creates a unified inventory of all cargo wagons and selects the 1st item according to the internal signal order as replacement. If there is no cargo, the wildcard gets no replacement.
• for the fluid wildcard, it creates a unified inventory of all fluid wagons and selects the 1st fluid according to the internal signal order as replacement. If there is no fluid, the wildcard gets no replacement.
• for the fuel wildcard, it creates a unified inventory of all locomotive fuel slots and selects the 1st item according to the internal signal order as replacement. If there is no fuel, the wildcard gets no replacement.
• now all interrupt triggers are checked one by one with any wildcards replaced with the corresponding replacement found above. Interrupt conditions are checked, and if one matches, the corresponding schedule is inserted with the same replacements.

I made an error, as always. I totally forgot how the interrupt condition is handled, so it isn't always the 1st signal that is selected as replacement. This will also make more sense to the popup description and explains how the interrupt trigger works.

I wrote that before processing only the 1st signal from the list of signals is picked. This is false. Actually the list is being iterated in internal item order and the wildcard is replaced with each signal in turn until the corresponding condition is true. The first passing signal is stored as replacement. Not necessarily the first one as I wrote above.
If the same wildcard appears in multiple conditions, it is always replaced with the same signal. Not every appearance of the wildcard is replaced on is own.
If there are different wildcards, I guess this loop is done multiple times, for each combination, so it's probably nested.

Sorry for the confusion.

[SpoonUnit]

All good.