Factorio Forums

Attached is a game where a train interrupt fires when it shouldn't.

The train is supposed to get crude oil when there is less than 25k in the storage tanks. At the time of the save it is approaching that limit and the train leaves to get crude oil. When the train comes back it fills the storage tanks but then the interrupt triggers again despite there being enough crude oil present.

I believe the problem is the train stops "Read train contents". My guess is that right when the fluid wagon is empty and the "empty cargo" condition is met the train stop still reports the fluid value from the last tick to the circuit network so the "signal parameter > 0" is also met.

I also attached two saves that won't fire the interrupt. I first tried it without read content, which means the pumps will interfere with each other. So not a solution. Secondly I subtract the train content on the red wire from the green wire, adding another tick delayed value. That way signal value seen by the interrupt will be slightly negative until the fluid wagon has been empty for 2 (I think) ticks. While that works it's quite unsatisfactory.


If my analysis is correct and the read train content reads produces a 1 tick delayed signal then I can think of three fixes:

1) add a color selector to the train stops "Read train content" and the interrupts "Circuit" condition. That way the train content can be put on the red wire and the interrupt fire on the green wire.
2) interrupt conditions should not be checked on the tick the train becomes ready but one tick later giving the train stop time to update the circuit network
3) the cargo empty condition should fire 1 tick after the train was empty, again giving the train stop time to update the circuit network

The minimum of 1 tick delay isn't a delayed signal, it's the interpreting of the signal by the waiting condition/interrupt trigger. This is unavoidable.

If you read circuit, you read "this tick" and check the condition, and the result of the check becomes effective "next tick". It's the same as with combinators and activation condition in every production building. Signal is being read now, activation/deactivation happens the next tick, and it's the same with a waiting condition/interrupt trigger: triggers the next tick.

The waiting conditions that directly check cargo are effective 1 tick earlier, because the circuit network isn't involved.

Often you have more than 1 tick delay, because you decide something outside of the train, then feed the result to the train. The decision is 1 tick, and interpreting the decision by the waiting condition is another tick.

It's not a bug, it's the design. Your request is an idea/suggestion instead. However, if you need complex waiting or interrupt conditions, you can do the whole decision with circuits and not use one of the integrated conditions. This way there are no issues with different delays. You can also get away most of the time by adding a "AND inactivity 1 second" in the waiting condition, since the 1 second enables the circuits to get stable.

Having said that, reading train content and send circuit network to the train at the same time is dangerous for interrupt triggers, because it can happen the interrupt trigger is checked while the train isn't sending its content any more but still reading the circuit network. In this case, the train appears as empty to the outside circuit contraption, although it may be it actually isn't. The train is about to leave, so it disconnected from the station, however for "read circuit" in the interrupt trigger it sill reads the circuit connected to the station. In my opinion this is a bug and could be fixed, but as far as I see, you don't describe this in your post.

It's an unloading station so the train can only leave empty. So the race condition that train content isn't read can't happen.

The problem here is that it is not obvious there will be a problem with the circuit network delay. The interrupt does not have a wire the user places, it just magically interacts with the train stop. The problem is the interrupt reads the train empty condition from the "input" side of the train stop but the train circuit signals from the "output" side of the train stop. So one condition is read without delay, the other with 1 tick delay. As I said, not obvious this will happen.

I settled on a work around now that I believe is generally usable: Add 'inactivity 1s" as condition to the train. That way the train isn't ready to leave before the train stop has updated the train content to empty. Adds an extra second to the unloading but if that matters then the user has bigger problems.