Factorio Forums

TL;DR:

• Renaming unique TrainStops leads to updated TrainSchedules.
• Uniqueness is determined over the whole game, not the current surface.

Expectation:

• Updating of TrainSchedules because of TrainStop-renaming should be checked for each surface - not for the whole game.

The described behaviour is explicitly tested in version 1.1.80 and 1.1.82.
Test-Environment: Vanilla / no mods / Editor

I've prepared a simplified Blueprint to test this phenomenon.
https://factoriobin.com/post/TIm_bP-i
Copy blueprint

Test-Setup:

• You have only one Surface.
• You have one (or more) Train with two (or more) TrainStops in it's schedule.
• Train Stop Names: "A", "B" and "C".
• TrainStop A and C are uique on the surface.
• TrainStop B exists twice.
• TrainSchedule: A -> B -> C (wait conditions are irrelevant).

Testvariants: (reset/reload after each test)

• Rename TrainStop "A" to "Alpha". TrainSchedule is updated to: Alpha -> B -> C.
• Rename one TrainStop "B" to "Beta". TrainSchedule remains unchanged: A -> B -> C.
• Rename TrainStop "C" to "A". TrainSchedule is updated to A -> B -> A.
• Updating can be triggered by "Shift-Copy", Blueprinting or manual renaming.

-> This works and is expected behaviour.

Bug description:

• If you duplicate the surface and have the exact Test-Setup on both/multiple surfaces, renaming a suface-unique TrainStop will not lead to an updated TrainSchedule.
• Only after renaming a game-unique TrainStop, all Schedules across all surfaces will be updated (to the name of the last TrainStop).

This should be considered a bug because:

1. The interface (TrainStop-Details & Train-Overview) counts the TrainStops per surface.
2. There is no indication for the user to determine why the TrainSchedules have not been updated.
3. Pathfinding-Behaviour (single-surface) is inconsistent to ScheduleUpdate-Behaviour (multi-surface).
4. Consistent Multi-Surface gameplay may be important for a large playerbase.

Expected Behaviour:
When having the abovementioned Test-setup on two surfaces the uniqueness of a TrainStop (that triggers an update of the TrainSchedules) should be checked for each surface separately.

Disambiguation:

1. "game-unique" = Name exists only once in the whole game.
2. "surface-unique" = Name exists once on a surface. It may exist on other surfaces.

This is not a bug IMO. In a multi-surface game, it is possible for trains to travel between surfaces. Train schedules can contain station names that exist on both surfaces, or that exist only on the other surface from where it is now.

The suggestion, which *increases* the number of cases where train schedules are modified by station renaming, would break the following setup:

1. Trains 1 and 2 are scheduled to use the space elevator between station "A" on Nauvis and station "B" on Nauvis Orbit.
2. Train 1 stops at station "A" on Nauvis, and Train 2 travels to Nauvis Orbit and stops at station "B".
3. Player copies the station "A" from Nauvis and pastes it on orbit.
4. Player renames the pasted station from "A" to "C".
5. If the suggestion were implemented, this would make Train 2's schedule change to "C" instead of "A". The player wouldn't notice until it went down the space elevator and declared No Path because there was no "C" on Nauvis.
6. Furthermore, Train 1's schedule would remain unchanged, so the two trains would no longer be on the same route. This would affect trains randomly depending on which surface they were on when the station was renamed.

The truth is that the current behavior of silently modifying train schedules during some, but not all, train stop renaming operations has always been a hack in need of retirement. It's a small QoL "feature" that hurts as much as it helps and could be replaced with more user-friendly and versatile commands.

The first would be to allow changing a station name in a schedule without remaking its conditions. The second would be to allow modifying the schedules of an entire group of trains at once. With those abilities, the user can generally update train schedules to match the new station names.

If that truly is not enough, then a checkbox or confirmation dialog in the station GUI to enable renaming would be far more useful. There simply is no reason to infer the user's intent based on that particular variable (uniqueness of station name).

No more copy-pasting a stop so you can rename it without messing up 100 train schedules. No more deleting all but one stop so you can use it to rename a complicated condition in a train schedule, then rebuilding the stops with the new name. That would be a big improvement (and I have a suspicion that 1.2 might address some of this already).

Thanks for the report. Issue is now fixed for 2.0.