This issue generic trains as currently implemented is that they break if a single station needs to receive more than one product. For example, my initial foundries are using stone furnaces, which need both fuel and ore to function.
There is no way to do this in a generic way with the wildcard signals currently supplied. This is due to a number of shortcomings:
- There is no way to control which item the item parameter tag triggers on if there are multiple items in cargo. From my testing, it seems like the item that will trigger it is based on order of iteration through the list of all items in the crafting tab, top to bottom left to right. This means that (for example) coal will always trigger before any kind of ore, since it's the first rock in the list.
- Theres no way to reflect, and see what station puts in a request for what item via the signal newtork. This means I can't just make a generic "dropoff" station that sends out a request signal when it needs stuff--as soon as two dropoffs do it at the same time, wrong items will go to the wrong dropoffs.
- There's no way to get the quantity associated with a signal used for an interrupt.
- There's no way to dynamically change the name of a station. If I could just dynamically rename a station to (say) "iron dropoff" when it needs iron, that would make things work easier.
- There's no good way for a train to send a signal to the circuit network while it's in the middle of a multi-stop route. If I have a station send a request to a network for a hauling job that needs multiple stops before the final one, it will cause a stampede until the train reserves a spot at the final station
- Change the item parameter tag, so it either triggers off the (say) first slot in the first car of the train, or make it iterate through items until it finds one that actually works instead off stopping on a "no path" error the first time it can't path
- Have some way for stations to put a unique identifier for the station into the signal network (similar to how trains can share their numbers with the stations).
- Have the interrupt parameter preserve its quantity, and let us use it for the right hand side of some wait conditions
- Have a flag for interrupt targets that reserves a slot in the targets' train limit as the target is a future temporary stop for the train.
- Not necessarily related to interrupts, but some way of examining the total quantity of items in cargo of a train as part of scheduling would be nice. All we have is "cargo empty," "cargo full," and "item count" for individual items.