Improvements for trains using generic pull interrupts

[Velcas]

This is kinda 2 suggestions, though rather closely related. A lot of the use-cases would overlap, so I figured it'd be fine to add both into the same post.
Honestly, they halfway feel like a bug (or at least oversight), but that's likely in part due to me being rather new to using parameters. That said, I've been fiddling with them for a few hours now, and it's at least mostly unclear as to why it doesn't work, so I'd say at least that part deserves improvement.

First:

TL;DR

A circuit signal being sent to a train can be used to trigger an interrupt and set a target station, but can't be used in a cargo condition for some reason.

What?

Honestly not sure how to explain it more in detail than with example pictures, so here goes:
This is what I'm "trying" to do:

04-22-2025, 20-21-40.png (442.44 KiB) Viewed 355 times

Note that the "select a signal" window doesn't originally offer the "circuit signal parameter", only the "item parameter". I instead "ghost picked" the signal with Q, to "force" it into the cargo condition. I'm assuming this leads to the whole thing not working, though it's somewhat unclear why if you never tried to pick the signal from the list and went straight to the "ghost pickup" like I usually do.

This is what it looks like, if I manually "force" the interrupt to trigger without any circuit signal.

04-22-2025, 20-23-32.png (71.29 KiB) Viewed 355 times

This is what it looks like if I provide an appropriate circuit signal, with available stations.

04-22-2025, 20-25-06.png (73.93 KiB) Viewed 355 times

This is what I'd expect/would like to happen.

04-22-2025, 20-26-27.png (70.14 KiB) Viewed 355 times

Why?

Either the circuit signal parameter not being available is intended to prevent making generic stations too easy, or it's an oversight.
In the first case, I find there's little reason, as the same can be achieved by simply adding all possible cargo items as OR conditions like so:

04-22-2025, 20-39-16.png (118.48 KiB) Viewed 355 times

(Ignore the added "stations not full" conditions, those are related to my 2nd point.)
Since parameters are supposed to (according to their FFF post) to get rid of the need of separate interrupts for each item, I don't think it's a stretch to extend this to separate conditions for possible cargo.
Alternatively, you could use circuits to read the cargo at the pickup station and check for a globally used signal (like checkmark signal) and use that as a circuit condition. Again, seems like unneeded hassle for something that feels like should be easier while not actually making a difference in usage.

On to my 2nd point:

Honestly, this one is very likely due to my lack of understanding, but again, not quite clear on what is going wrong.

TL;DR

Allow "item parameters" to check for stations itself.

What?

Here's what I want to do:

04-22-2025, 20-55-56.png (516.2 KiB) Viewed 355 times

As seen, there's both iron ore pick and drop off stations available.
While waiting at a stop, no interrupt triggers, however. If I manually trigger the interrupt, it just shows like this:

04-22-2025, 20-57-53.png (511.96 KiB) Viewed 355 times

Which sorta makes sense, assuming that there's nothing that "defined" the "item parameter" yet. It's unclear (at least to me in this case) how it's defined in the first place, however. Since I can set it as a condition, I'd expect it to act as such. And not like it's specifically called "cargo item parameter" or anything.

Why?

Again, this might be to prevent making generic interrupts too easy... However the same can be achieved by simply supplying a circuit signal for each possible station, which then runs into the same issue as my first point (and thus has the same "solution" as well).

So in both cases there's relatively "simple" ways to make it work, it just adds some unintuitive hassle. It's not like it needs complex circuitry or clever thinking, so it feels like it shouldn't be necessary, and the tools available seem like they make it unnecessary, but don't actually work that way.

[robot256]

1. Probably it is just an oversight that signal parameter can't be substituted into interrupt schedule wait conditions. Perhaps the blocking of the signal parameter from the cargo signal selector is a patch to hide it, or just another oversight
2. You can also design your system to have each <item> loading stop read cargo from the train, convert <item> to a common virtual signal like "N", and have the train wait for N>400.

[Velcas]

Yeah, there's multiple (not particularly difficult) ways to get around these "issues", no question. But they all just add what feels like unneeded hassle because it's not difficult to do. Like, I can just make a separate interrupt for each item and completely ignore parameters, but that's what they're there for, no? Because doing that is just a hassle without any actual improvement to gameplay. Hence these suggestions.