[2.0.43] Parameterized train stop replacement can break train assignment

[blazenclaw]

3 picture overview:
Setup:

04-16-2025, 22-54-45.png (99.48 KiB) Viewed 650 times

Blueprint replacement:

04-16-2025, 22-55-40.png (131.52 KiB) Viewed 650 times

After replacing the wood box station (no end result change), the train stops running:

04-16-2025, 22-56-42.png (142.79 KiB) Viewed 650 times

What did you do?
When I replace a train stop with a blueprint that uses a parameter for the station name [under specific conditions, see below]...

What happened?
Trains assigned to that stop instead begin routing to the station with the parameter, not the item selected in the parameter popup menu.

What did you expect to happen instead? It might be obvious to you, but do it anyway!
If the blueprint makes no change to the station (at the end of the parameter selection process), it should make no change to trains assigned to that station.
(Or more generally, the end result for train stop replacement should be used for swapping train assignments, not stepwise item->parameter, and parameter->new item.)

Does it happen always, once, or sometimes?
Always, so long as the following conditions are met:
- There is an existing station on the map that has the [parameter] station name
- There are no other stations on the map that have the same [item] station name as that which is being overwritten (in this case if it started with 2 [wood box] stations, there'd be no bug)

There is a similar not-a-bug report here (viewtopic.php?p=635469) describing the replace-name behavior, but I think it's different enough here because of the non intuitive nature of the end result of the station not matching the end result of the train.

The reason the station with [parameter] name exists (because yes, removing it would work around this issue) is that the source of this problem is a multi-hundred hour pyanadon mod run in which our blueprint train stops are... complex, and editing the blueprints is far, far easier if there's an existing stop to copy from rather than having to replace each time.

Save with the above screenshots:

Bug_TStop_Paramter_Replace.zip

(2.64 MiB) Downloaded 109 times

And blueprint for train stop:

0eNqVkMFqwzAMhl8l6OzAtnQdMezUZ9iphOEkohUkkrHddSHk3ScnXbfDLjsJ/db3/5ZmaIcL+kCcwM5AnXAEe5wh0ondkDV2I4KFFBxxGZN4WAwQ9/gJ9nFpDCAnSoQbtzbTO1/GFoMOmD94A16iIsLZX23KFwNTdjMQk9se4EgJx1fvgvIJQ/nQQE67C1temnx2px7uSYezSMRi468iPXLZnTGmppBwkynIt6ig0hZ+Ja1BeU7ln/sYGFyLehN486fgeixccfuuKbp/h37oCuumz/unelfXWqq62lfL8gX0z4mu

Copy blueprint

[boskid]

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

Root cause here was that logic that builds a blueprint was trying to be smart to not create copies of the blueprint, but this means the parametrization was not performed on the blueprint copy. Instead the blueprint with parameters was first placed on the surface and then parameters were applied, possibly on existing entities.

This casued the problem to appear, because train stop was first renamed into parameter-0, and because wooden-chest was last stop for a train, schedule was adjusted. When train stop was renamed back to wooden-chest, the train saw it is one of many stops named parameter-0 and as such it refused to move back.

Fix that i did was that when blueprint is built, there is a blueprint copy created, parameters are applied onto the copy and only after that the blueprint with resolved parameters gets placed. This means the train stop is never renamed into parameter-0, not even temporarily and this fixes the issue.