Factorio Forums

What happens?

When adding a temporary stop to a train by ctrl-clicking the map, if the currently active stop is a temporary stop, either from another ctrl-click or an interrupt, the new temporary stop is added after the active stop and any other temporary stops until the next permanent stop. This is contrary to behavior with permanent train stops, where a temporary stop is added before the active stop.

Steps to reproduce

1. Create a simple train loop with 3 or more stations.
2. Create a train with a schedule of the first station, and an interrupt that has it visit the other stations. Something as simple as Condition: At station 1, Target: Stations 2-N.
3. At any point while the interrupt is running, add a temporary stop.

Expected result

Temporary stop gets added before the currently active temporary stop, then once completed, the interrupt schedules resumes from where the player interrupted it.

Actual result

Temporary stop gets added after the end of the interrupt schedule, train then returns to station 1, then resumes the interrupt schedule from where the player interrupted it.

As it is now, if one adds multiple temporary stops all in a row, they're all iterated on in a FIFO order, except for the last one, which effectively becomes LIFO for only that one stop.

Sounds similar to 118266

I did see that thread while searching, and it seems like the conclusion in that thread is "a newly added temporary stop should always replace the currently active stop", which I can definitely see as necessary and intentional.

The point of contention I'm running into is where those temporary stops get added in the schedule. If I ctrl-click 4 times, pre-2.0, the behavior would be for the train to visit stops in the order of 1, 2, 3, 4. That got changed in 2.0, and the behavior would now be for the train to go in the order 4, 1, 2, 3. That seems non-intuitive to me, and I would expect it to follow the order 4, 3, 2, 1.

boskid wrote: Fri Mar 06, 2026 7:22 pm Sounds similar to 118266

Yes, it is the same issue. The arguments made in that thread for changing the behavior remain valid, and the arguments for keeping it as is remain absent. I will let someone else write the requested suggestion thread to say "please fix this bug".