Factorio Forums

Hi,

There seems to be an unexpected conflict with trying to use both "Read stopped train" and "Send to train" functions in the Train stop, combined with circuit-triggered interrupts in trains.

A minimal setup is a track, a train stop with "Read stopped train" ([T] from now on) and "Send to train" enabled, a pole connected by a circuit wire to the train stop, a train with one stop, being the stop it's at, and an circuit condition interrupt that sends a train to a stop named, for example, "{SWC} Pickup", where {SWC} is the "Signal parameter" wildcard rich text.

Once the train's wait condition expires, it seems like the [T] bounces back into the Train Stop and immediately into the train, if there is no other signal present. In the video demonstration attached, you can see it happening - during the wait condition, the [T] signal is visible on the power pole/display panel. Once the wait condition runs out, train immediately gets scheduled a station with [T] substituting the interrupt.
This does not sound like a bug per se, as [T] is a signal like any other, but it does sound like a conflict of available options. I would expect Train Stop to ignore the signal it has created itself, be it [T] or "Read train count" ([C]). The issue could be worked around by using a condition such as "Station is not full" condition in the interrupt, but this may not be desirable, if, for example, I plan to use another interrupt to handle that. Maybe a "Destination available", as an opposite of the "Destination full or no path" condition, could be a solution?

Thanks in advance for taking a look.

Hello, this is a generic problem in more than this place.
We have an internal proposal to make it configurable almost everywhere from/to which wire you read/write. So you could output to red and read from green for example.

But this is not a trivial change, and because of all the other work we need to do, we are planning to do this for the version 2.1 (Is this the first confirmation of 2.1? probably, but don't expect anything big, it will be mainly just a collection of final touches like this one).

kovarex wrote: ↑

Mon Nov 04, 2024 3:15 pm

Hello, this is a generic problem in more than this place.
We have an internal proposal to make it configurable almost everywhere from/to which wire you read/write. So you could output to red and read from green for example.

But this is not a trivial change, and because of all the other work we need to do, we are planning to do this for the version 2.1 (Is this the first confirmation of 2.1? probably, but don't expect anything big, it will be mainly just a collection of final touches like this one).

Hi, yeah, a R/G toggle like in Arithmetic/Decider combinators would solve this problem. Also for a Selector Combinator, maybe? Thanks a lot for considering this.

For others reading, I have a "workaround". I needed this "Read stopped train" signal so I could confirm that a signal went to the train and it's safe to store that signal in the memory cell. However, I then realized that by reading "Read train count" from provider and requester stations, I can count how many trains are actually being dispatched somewhere, and I don't really need to keep a memory cell. (Initially I didn't consider that I should have read it from two stations the train is headed to, not just the last one).

kovarex wrote: ↑

Mon Nov 04, 2024 3:15 pm

Hello, this is a generic problem in more than this place.
We have an internal proposal to make it configurable almost everywhere from/to which wire you read/write. So you could output to red and read from green for example.

But this is not a trivial change, and because of all the other work we need to do, we are planning to do this for the version 2.1 (Is this the first confirmation of 2.1? probably, but don't expect anything big, it will be mainly just a collection of final touches like this one).

How easy/difficult/well nigh impossible would it be to support {N} more wire colours? That would solve a LOT of issues folks are having. (Six colours would be the dream for circuitoholics.)