Don't show "no path" warnings when all stations on the local network are full, but the same name station exists elsewher

[wheels47]

TL;DR

A train heading to "Plastic Input" will show a "no path" warning if all the stations on the local train network are at their train limit AND if there exists another "Plastic Input" station somewhere in a different train network. My suggestion is to not show that warning in this case.

What?/Why?

I'm working on a system that uses small trains in a local rail network to collect ingredients from larger trains (right) and bring them to assemblers (left). It works well, but I start to get these "no path" warnings (like the train at the bottom of the image) when I copy and paste the module multiple times.

I'd like to be able to copy and paste like this without renaming all the local train stations. It feels messy having "Plastic Input 1," "Plastic Input 2," etc, for each module. And it feels odd that a module with no warnings suddenly gets warnings when a copy of that module is made.

My suggestion is to not show a "no path" warning in the case where all stations on the local network are full, but there is a station with the same name somewhere else on the surface.

[boskid]

No.

What you are asking for is to basically remove "no path". It is there to indicate that train was unable to reach a train stop that it was supposed to be able to reach, which will often show when some rails are destroyed, signals are incorrectly placed, rails are missing etc. Your case of intentionally missing rails to a main network cannot be simply told apart from a player error where rails are unintentionally missing and a true "no path" error is to be shown.

[wheels47]

No.

What you are asking for is to basically remove "no path". It is there to indicate that train was unable to reach a train stop that it was supposed to be able to reach, which will often show when some rails are destroyed, signals are incorrectly placed, rails are missing etc. Your case of intentionally missing rails to a main network cannot be simply told apart from a player error where rails are unintentionally missing and a true "no path" error is to be shown.

"No path" makes sense to me when there doesn't exist a station on the local network that can be reached by the train. This is a little different, where there are available stations, but they are just temporarily full. I think the train status in this case should be "destination full," which is exactly what the status is when you build just one of these modules. It only switches to "no path" once multiple modules are built, and stations with the same name exist elsewhere.

With the current behavior, how would one design a system like this with many local train networks? Copying and pasting identical modules but changing the names of the local stations seems odd to me, even if you use parameterized blueprints to make that faster.

[wheels47]

I made a video to illustrate the issue better. A module like this can't be copied and pasted without adding a flashing warning to the screen.

https://www.youtube.com/watch?v=uCQT3ehkY8c

0eNrlm9tu2zgQht9F13IhiucAvdjLfYbACGSb6wiVJVeS2w0Kv/tSkh0rzjCaIXJRbIECbmzp8z/knCjSv5JNdXLHtqz75OFXUm6bukseHn8lXbmvi2p4ry4OLnlI2qKsknOalPXO/Zs8sPM6TVzdl33ppjvGP16e6tNh41p/QXq9c3tqf7jdagCsiiRNjk3n72rqAe5J2mZp8pI8cA/fla3bTp+x/Jy+g+av0K73vP1zP2IhKIegAmByPFNimQLP1FimxDMtlqmwTJMxLFPjmeg5MlhnMpmCmApgWpC5AcbTTPMuEQ7KsnQeMKtLGAFM82Wiii/3XAZxb+G0OVXfVmXdubb3nwCzz2ZkCJXjUTwk0kBgjgfnJLDAg8WC8bcoGpyzXnV9cwy75p04r6Pri+n/yV9d5w6byrWdv/9Q1KeiehqZ3VNVHsp+yJGAAPXWQbbPo4qAm5hMBN0EdD+NdWrDGGQhFCjsFn3FZHNZ71eHYvtc1m7FP3JBNar29PI43n7qm8M4fqtuW7p661bHYvstuV7y9N0Pov9qf2ndtIdxRMreHaYCU+5m5ag7Om/dodmdqkHD+fVCf139VNY/vBFN+zLdePtrmkH/lQ/ZYCn4CQt+kgc/4ef12f8DBs+SB0/Ag1e2ftj2rmhXP5+dq/7Pg5Zn+Nw8ubF968Zg78DwsSEvUAiTUxubIaEvdzac2trcY6G6mQtqc4OiSmp7g6IqaoODompqi4OiGmqTg6JaaptzT4XSN8+ojQ7DtOKcUTsdlqNaHZ7TW50RDbEiWpL3MqGehAt6F4UkS3q3E7Rfkdqd+4n/hH6H67h+B3AW0AsNteFhiKUBRwei1pdUJJYLkMii+ygm/vhGSrDoRup+9P6gTkrMnpicNtdgBsbK3Nz4NgqV27t6V/jvgtAcXa2YvtIhDr5HuQabBjmS2jR6znLQKmrXGFCH70OuowVzDHm0wDZWWLIekCMzqp6cgRxG1RPg5NTUnefLXiA52UoOqhNkK2GOpMaetxLiKLJdYJ8hyd4d4Bjy7KnljkpaspVg7KmMPOp36lgGYemuD8vLyWaCIa04WQ/MEdSEzNnyZCpJTcj3VHgSFNXzeI4Qq0nll3N8+VWG6oz3guFxID8W5/d9OrgpkFGWAbfGl8v7ZQBIZ6hlzuum0LuVxXyd83e9b93ON9U9aaGjc9x62GQ6aBuHuJy6wuGYEaPHpl52dy3Jm34a4zyKvO2nEUOgyRt/GKohb/1hqJa8+Yegmoy8/YehMvIGIIaa46n42TKcvLGIoQpyidKI1GzQD4b8dF1zjME8cjJvHhPV3bFp+9XGVf2HaAs/czIaL5PTZBqCTL4kk1zoBEPkKhtZ6ATDFDpLK3TvFH9GobN5hLOIDJ4FewvAU71z7b5t/Osybhqt/mV8ntOc+uOph5okKyI8JqhVkrRyqlZFbSDe+wzUQFjynrBA7FVYQy31gmPCx1JLvUAcH2FZRq31OCyjFnscNqdWexyWU8s9Diuo9R6HldTSjMOquIQj5kFc1oEYZhmh+OVv2UuHYDITl36wymeRd/QL0JDoCSoDx2tm558W7Rc0+2dHoD4SKBYERlUvHaLxGJoK0aKqVVCbjKEFtcW0iMKGaDqGZkK0mL4wrM3G0ELaZkdZ8JZKFqKxGFoWouURloa18RhaUJuIsZSHaDKGlodoKsbSoDYdQwtqMzGWhrJlbmNoobOXPIuxNKSNsxhaUFtMXZCh3Mtj6oIM5V4eUxfC2mLqQlhbTF2QoWzJY+qCDGVyHlMXwtpi6kJQ2+wwCGZnQDH8zgAThMPi9nrYNJTWZycIWvf95DoPWm2f/euHuOxy5GK84+mfsuqHg0P+sm5q8i5nKi4/JkmT1yvevHv54vHAxrEqepfMR+H1kMa2ORyLtugbLzj5Or5xGn7Q4td95/VwNAKyKyZEw6MUU65UqPiJmBANa4spV2FthBWOXJRm8M41w32qc22b49F/62e7l42IQY5aCEl8GZ2xc8zzRSYpRTUjsmNKrAo1OjKm3QzTRIRXI6eLEswyOKTw7z0kJbYFFa6jUr/43VO/jMs64jfLOus0+emncPiCR1+lZap0Ktfp4/CSDg2GXK+nc4mDV7/+zDNNfnhVo4VS5VZYK7UWShl7Pv8HNUXsOw==

Copy blueprint

[boskid]

Lets say player builds something and forgets to place some rails making a train stop inaccessible like this:

09-27-2025, 01-09-39.png (1.55 MiB) Viewed 194 times

In this exact case a "no path" error means that there is a train stop that a train wants to go to but is unable because some rails are missing and its up to a player to decide where are the missing rails. Based on your expectations, just because this train stop is disconnected it should be considered a different network and a train should not even try going there and "no path" should not show. How would we communicate that there is a problem in a rail network making some trains unable to reach some goals?

Core of the problem in this discussion is that you are treating disconnected networks as something intended while we want to treat those as unintended. There are no simple rules that based on location of rails would allow saying "yup there are some missing rails, show a no path" or "those are intentionally disconnected, do not attempt pathing to the other network".


If you dislike "no path" alerts, in extreme cases you can run a console command `/alerts disable train_no_path` and you will not get any alerts of this type anymore.

[zig1000]

I think their precise request is not "figure out whether that was the intended station via mind-reading", it's "do not show No Path if another station of the same name exists that IS reachable", which is unambiguous and seems completely feasible if performance weren't a concern.

Now, calculating whether such a same-named station exists when said station is not the current target station might be infeasible from a performance standpoint, assuming the code is optimized for only checking paths to a single currently-targeted station, but if so I think that should be explicitly stated as the reason to close this bug, since I don't think the request is ambiguous like you implied.

[zig1000]

Some examples under their proposal, where A-target is the target station, A-duplicate is a non-target station of the same name, and B is a station with a different name.

Code: Select all

train ==== A-duplicate             <disconnect> A-target | TARGET FULL
train ==== B                       <disconnect> A-target | NO PATH
train <disconnect> A-duplicate     <disconnect> A-target | NO PATH

So, NO PATH cases still exist.

[Kyralessa]

I think their idea is that "no path" where *no* tracks connect is different from "no path" where *some* tracks connect.

In other words, if there's a tiny hole in your otherwise-connected tracks, you get the same no path as if there are two completely different sets of tracks that don't connect at all.

Which is not to say I agree with making this change. It would surely kill performance if on every "no path" the game also had to evaluate whether these tracks were "supposed to" connect or not. And there would be sooooooo many edge cases...

[wheels47]

I understand what you are saying boskid, and I don't disagree. But I think there is more to it.

My proposal is: If any paths exist to a train station, but those stations are full, the train's status should be "destination full" instead of "no path."

The "no path" status would continue to act as usual when no path exists. The system just won't throw at warning when some stations can be reached, but when those stations are temporarily full.

The benefit of this is that now you can make local train networks that share station names without raising a warning. Suppressing the warning is only a partial solution, since that is usually a useful warning that I would want to see.

There is also a semantic benefit, where, in my mind, "destination full" is a better descriptor for a train that has a path to a station, but where that station is full. But that is less important than the fact that the current behavior issues superfluous warnings when local train networks share station names. That was my favorite approach to the game in 1.1, but the increased visibility of "no path" warnings in 2.0 makes it unworkable. It's a huge bummer for me.

Also, notice that in your example, you wouldn't be seeing a "no path" warning, yet. Other stations with the same name are still available, so the trains will throw no warnings. The trains will only throw a warning when those stations fill up. The current system wouldn't warn the player about anything until that condition is met (if ever).

Ultimately, I think the assumption that train networks are connected is very limiting. And I think it's reasonable to infer from the fact that there is a path to a (temporarily full) station, that a disconnected station with the same name might not be intended to be part of this network.

Please, if you wouldn't mind, take a minute to reconsider this request. I'm sure there are performance considerations and edge cases that I might not have considered, but I want to make sure we are at least on the same page before this request is rejected.