Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Electric train waits for free path when track is not electrified #9094

Open
DonaldDuck313 opened this issue Apr 24, 2021 · 4 comments
Open

Electric train waits for free path when track is not electrified #9094

DonaldDuck313 opened this issue Apr 24, 2021 · 4 comments

Comments

@DonaldDuck313
Copy link

@DonaldDuck313 DonaldDuck313 commented Apr 24, 2021

Version of OpenTTD

1.11.0, Windows (though I don't think it's an issue with the OS)

Expected result

If I forgot to electrify a piece of track, the electric trains should go to the last electrified tile, then turn around as if the non-electrified track didn't exist.

Actual result

The train stops at the last signal before the non-electrified piece of track, saying "Waiting for free path" even though the path is free. This can be confusing because in more complicated systems, it's not immediately clear why the train is waiting for a free path. And even if I figure out why it's waiting for a free path, I need to look very carefully to see which piece of track is causing the problem.

If the train went all the way to the last electrified piece of track and then turned around as it does when the track doesn't exist at all, it would be much easier to figure out why it's doing that and which piece of track I forgot to electrify.

Steps to reproduce

Build a track similar to the one in the screenshot below (note the piece of track that isn't electrified), buy an electric train, and run it on the track you just built. Don't forget the signals, otherwise it works as expected.

@2TallTyler
Copy link
Member

@2TallTyler 2TallTyler commented Apr 25, 2021

I think the problem here is how trains with impossible routes due to incompatible/unpowered railtypes handle this. Navigating as far as possible and then displaying "waiting for path" isn't helpful, but neither is reversing on what is likely a one-way track. It would be better if it never left the previous station and displayed a warning (both as a news item and on the train's status bar), "no route to next station" or similar. I'm sure there are other solutions, too.

@LC-Zorg
Copy link

@LC-Zorg LC-Zorg commented Apr 26, 2021

If I forgot to electrify a piece of track, the electric trains should go to the last electrified tile, then turn around as if the non-electrified track didn't exist.

This is exactly what will happen when you use regular (block or pre) signals. For path signaling, this behavior is correct and changing this could cause more problems than good. By the way, if the trains go on, you may never notice where the problem is. If the trains stop at the station, away from the problem, it won't be any easier to locate either.
In such a situation, at best, a warning could appear about the inability to reach the destination due to the lack of appropriate tracks (not only the lack of traction can be a problem here).

@Sgt-Nukem
Copy link

@Sgt-Nukem Sgt-Nukem commented May 3, 2021

By the way, if the trains go on, you may never notice where the problem is.

Yes, but it would be more consistent with e.g. a missing track piece hidden under a bridge.
You would then be notified "train X made -5,000 € last year" and would closely follow the train en route to where it surprisingly changes direction and then find the missing track or missing electrification.

Here however - I mean the "steps to reproduce" from the OP are really dumbed down - think big: On a big busy multi-track crossing with two dozen switches and path signals securing each of the entries: You would think the train "is waiting for free path" because the junction is so extremely busy, not because the necessary track isn't build yet.

For path signaling, this behavior is correct and changing this could cause more problems than good.

I have no idea of how the path signal algorithm works, but I imagine something like this:

const paths_possible_list = PathFinding.collect_all_possible_paths( my_position, destination );
bool could_reserve_track = false;
for each possible_path in paths_possible_list
{
         if ( PathSignalBlockingMe.try_to_reserve_path( possible_path ) )
         {
                  could_reserve_track = true;
                  break;
         }
}
if ( !could_reserve_track ) this.ShowWarning( "Waiting for free path." );

If so, one could just check for paths_possible_list.length < 1 and show a different error message.

Something like

"No path to destination could be found."

or

"Destination not reachable."

@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented May 27, 2021

I think in general OpenTTD could serious benefit from "Destination unreachable" message. I have a very similar issue with boats that cannot get to their dock ... especially when using rivers, good luck figuring out it got stuck going up-river.

I really hate that by default it just starts to run around blindly hoping that some day magic happens and it can find its route. But without telling me, the human, about it, that is in many cases rather unlikely to happen.

For trains with PBS it seems it is slightly "worse", as instead of running around blindly, it just gets stuck with a weird (read: unrelated) message .. yeah, that is confusing to any (new) player :)

Currently what you get in most cases is the popup that either "ship is lost" or "made last year", but both are not visible on the vehicle itself, which is also confusing. And also shows up very very late.

So yeah, lets make this a bit more user-friendly, one way or the other :) Shouldn't be "that hard" (famous last words!) :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants