TL;DR
In 2.0.77, when the train's active destination is a temporary stop (either manual or interrupt), the next manual temporary stop is added after the active temporary stop. I suggest that when the next stop in a train's schedule is an interrupt stop, the manual temporary stop should be added before the interrupt stop instead of after it. This will ensure that the train resumes its automatic schedule in the correct place after the manual stop is visited.This is a continuation of the discussion in these bug report threads: 118266 133006
What?
There are currently two different ways for manual temporary stops to be inserted in a train schedule:1. When the active destination of the train is a permanent schedule record 'A', the new manual temporary stop '[35,-91]' is inserted before 'A'. The active destination becomes '[35,-91]', and after leaving (and deleting) '[35,-91]' the train proceeds to 'A'. The stops in the permanent schedule are visited in the same order they would have been if the manual stop had never been inserted.
- Case 1 Starting Schedule
- Screenshot From 2026-05-31 20-30-01.png (82.99 KiB) Viewed 110 times
- Case 1 after one manual stop
- Screenshot From 2026-05-31 20-29-47.png (75.71 KiB) Viewed 110 times
2. When the active destination of the train is an existing temporary schedule record 'B' (created either manually or by an interrupt), the new manual temporary stop '[67,-91]' is inserted after 'B'. The active destination becomes '[67,-91]', and after leaving (and deleting) '[67,-91]' the train continues on to 'C' without visiting 'B'. When the schedule repeats (and the user does not delete the skipped 'B' record), the train will visit 'B' after 'A' even if the interrupt did not trigger (and will visit it twice if the interrupt did trigger again). Thus, inserting the manual stop '[67,-91]' while the train was bound for temporary stop 'B' has changed the order in which 'B' was visited relative to the rest of the schedule.
- Case 2 Starting Schedule with Interrupt
- Screenshot From 2026-05-31 20-33-23.png (86.12 KiB) Viewed 110 times
- Case 2 manual stop placed after interrupt
- Screenshot From 2026-05-31 20-33-47.png (123.32 KiB) Viewed 110 times
My suggestion is that when the active destination is a temporary stop created by an interrupt, the manual temporary stop should be placed before the interrupt stop, not after it. This is probably a simple change now that ScheduleRecord contains the flag "created_by_interrupt".
(I appreciate the rationale for placing new manual stops after existing manual stops, and setting the newest one active, so I am not suggesting any change to this behaviour.)
Why?
Temporary schedule records created by schedule interrupts are part of the normal automatic operation of the train. When the user creates a manual stop, they expect the train to resume its normal automatic operations after the manual stop is visited, regardless of when the manual stop was added. To meet this expectation, manual stop creation should treat records created by interrupts the same as permanent schedule records.I acknowledge that the player can rearrange the manual stop to be before the interrupt stop while the train is moving, and that players expected to interact with the schedule when creating multiple manual stops in a sequence. But most uses of manual stops only require one manual stop to be created, and in those cases the player does not expect that rearranging is necessary simply to have the train resume its automatic schedule correctly after the manual stop is visited.
The current behaviour is likely to confuse players when they first try to use interrupts and manual stops at the same time. There are many scenarios where accidentally skipping and not deleting an interrupt stop will cause problems in a train network if the player does not notice and correct it in time. Yes, you can design an interrupt system to account for this (the only cost being trains that go in circles for a while to clear out the old temporary records). But it puts more limits on the types of behaviour you can design and creates more pitfalls that new players will have to learn to avoid.
I'm really looking forward to the 2.1 release and hope you will consider this suggestion before it comes out.