Better “No Path” feedback for trains

[Gandalf]

Based on this thread. Idea is simple: Be more specific then “No Path” when trains don't work.

Basically there are two possible reasons why a train can not reach a destination:

1. There is no physical link between the trains current position and the destination, i.e. tracks are missing.
2. There are tracks, but the signals are placed in a way that prevents trains from going through in a certain direction.

I assume the pathfinding will have a simple enough way of distinguishing between these two errors.

In order to keep it short I suggest “No Tracks” or “Tracks missing” for a) and “Path Blocked” for b).

Additionally it might be a good idea to add a global alert for trains that are stuck, to help detect deadlocks. (You know, one of those annoying yellow triangles that flash every other second once you start using robots)

[Gregorovitch]

It would also be very helpful if when a train was ordered to commence a route, and there was a problem with the route, it advanced as far as it could to the first error then stopped giving a "Track error" or Signal error" message at the position of the problem. This would make debugging rail lines much easier and more importantly quicker.

[LordFedora]

But if there is an error, how can it tell what route to take?

[Gregorovitch]

But if there is an error, how can it tell what route to take?

I would think that the game must already calculate the whole route to the next destination station in order to identify any fault on the route. It would follow that the train could advance to the position of that fault.

[Gandalf]

Pathfinding tries to find any route, not “a route without an error”. If you get “no path” it means the pathfinding didn't find any route at all. Finding the error would mean the pathfinding has to guess what your intention was (for example estimate missing tracks), which is quite difficult and probably not worth the effort.

[ssilk]

I think this is an possible task, and there are some cheap calculations, which would have a big benefit. I try to explain an algorithm:

1. Calculate path, if no route found remember the points, where signals have blocked the way.

2. Then calculate the path again, but this time don't look for signals or current train direction.
2a. If no path has been found: nice, then there is really no path. There must be a track missing. (*) Or it is just not reachable without changing direction. (**)
2b. If now a path has been found it can have two reasons: signals and/or train direction.

3. Calculate the path with the current train direction.
3a. If found: it must be a signal! Look into the remembered positions of step 1 and compare, which signal(s) have been in the way. (***)
3b. The direction of the target train stop is eventually wrong. We can testing-wise change the direction of the target train stop. If it can be reached its that.

(*) it's an idea here to check the path in the other direction with this algorithm. If found, it's a complex switching. Maybe some roundabouts... If not, there is really no connection. There must be two networks or its a switch, which is not possible to pass. In this case it is eventually a good hint to find a path, which ends in the most near distance from both sides. The endpoints of these two patches are most probably a good hint to look for first.
(**) it could be also the length of the train, but I think this is not taken into account yet.
(***) I think this is the only complex part: if there are more than one, we can test to remove one signal and repeat step 1. If found, then this is it, if not we can remove the second. Etc. until we removed all found signals once. Then we can remove 1 and 2, 1 and 3 etc. (remove the signals in all combinations) until all alternations played through.
Optional: we repeat this alternation-stepping, we remove signal by signal in all combinations, but this time if step 1 finds new signals, we can take them into account and recursively look, which other signals than the first found may block the way.

This algorithm is of course not correct nor finished.

[Xuhybrid]

Edit: [retracted]

Checking for a route without signals first, then checking signals would help it determine which problem it is.

[Gregorovitch]

@ssilk: if I understand your approach correctly then we could have the following conditions and messages:

1. In the case where there is no available contiguous track to the next station (regardless of signals and station orientations) you can say "No track to next station". We can then search for the bad join or missing rail section along the new track section etc because we now know that's the problem

2. In the case where there is no route to the next station because of the direction orientation of that station, where the only available physical route (regardless of signals) has the train approach from the wrong direction in other words, you can say "No valid approach route to next station". We can then lay new track to enable the train to approach from the right direction (or change the orientation of the station) since we now know that's what the problem is.

3. If neither of the above are true and there is still no path to the next station you can say "Signals blocking route to next station" by default since that's all it can be. We can then examine the signaling we've put in.

On reflection as far as signal problems are concerned I would say we are just as likely to refactor the whole signal set up to sort out the situation as make minor adjustments making detailed pin-pointing of signal errors potentially superfluous. Just knowing for sure it is a signal problem would be a huge step forward for now.

There is one potentially confusing condition where, for example, you have a loop at a remote station and you have set up the signals incorrectly relative to to directional orientation of the station. But in that case it is not really possible to determine the intention of the player - did she put the station or the signals on the wrong side? On this scheme the error report will be signal error. I don't see that as too much of a problem because getting that right is one of the first things you learn with railways.


Initially I would think testing and reporting in the above order would be logical and easiest.

[Kokelvogel]

...

On reflection as far as signal problems are concerned I would say we are just as likely to refactor the whole signal set up to sort out the situation as make minor adjustments making detailed pin-pointing of signal errors potentially superfluous. Just knowing for sure it is a signal problem would be a huge step forward for now.

There is one potentially confusing condition where, for example, you have a loop at a remote station and you have set up the signals incorrectly relative to to directional orientation of the station. But in that case it is not really possible to determine the intention of the player - did she put the station or the signals on the wrong side? On this scheme the error report will be signal error. I don't see that as too much of a problem because getting that right is one of the first things you learn with railways.


Initially I would think testing and reporting in the above order would be logical and easiest.

I have only started to play around with trains very recently and so I am still making any number of very avoidable mistakes.

That being said ... for a beginner like me it is immensely hard to figure out what I did wrong THIS time. And it is the rail signals that trip me up ... and there is no simple way to spot the wrong one/s (like there is with train stops).

I would greatly appreciate a feed-back on not only which part I screwed up (tracks, stops, signals) but also to point me to the faulty parts. As I do NOT like to refactor the whole signal set up Sure, if we're only talking a dozen or so signals, that's no problem. But what if you have to rip out a considerable amount (and no, I try not to plaster intersections; I try to keep rail signals to a minimum) because you cannot spot the problem if you simply take a second look?

This might be a beginner's problem but it makes it extremely frustrating and seems to cause people to shy away from using trains (when they are actually very convenient ... once you get them running ).

[ssilk]

No, I think it's also an advanced player problem. Just a moment and you placed the signal on the wrong side.

Ah that would be the rule zero!

0. When building tracks and signals (etc.) (not when searching for the path! that is much too late) the game shows me:

- When I place a signal, that leads to unusable/dead blocks, like simply placing two signals on one rail in different directions.
- When changing rails, that lead to dead blocks. Typical example: Building a loop at the end of a single direction rail
- When placing train stations, that could not be reached:
--- The game searches backwards to reach any other train station in the same network.
--- The game searches backwards to reach all other train stations in the same network.

Maybe there are more situations.

In that cases the game shows the player while placing, that there might be a problem. E. g. orange arrows (like the yellow arrows yet), and a textual warning, that explains the situation.

The difference is, that many (not all) problems are avoided while building, which makes much more sense.

[Kokelvogel]

@ssilk: I agree that it would be best if you were stopped from even placing something wrong. But wouldn't that mean you'd have to build in a fixed order:
1. tracks
2. stops
3. signals

Admittedly, that is how I do it now anyway (as it is easier on my brain).

And couldn't you still end up with situations (I am thinking of using rails in both directions) when a signal might work for one path but not for the other? Not sure about that, though, as I do not use tracks both ways.

What about later additions and changes to your tracks? I am again not quite sure (but I think I remember having run into that exact thing) where you have to take out signals on the former line to make the new one work.

Don't get me wrong, I am not trying to discredit your idea (which I actually prefer as the easier solution for the player). And I know that I might not have a good enough grasp on the whole train-building-system to throw in my five cents (or to a fellow German ... mustard ...).

[ssilk]

@ssilk: I agree that it would be best if you were stopped from even placing something wrong. But wouldn't that mean you'd have to build in a fixed order:
1. tracks
2. stops
3. signals

Yes and no. A check can only happen, when you connect the railway-elements together by tracks. Before that, no check can be done/is needed/makes sense.

Admittedly, that is how I do it now anyway (as it is easier on my brain).

Of course.

And couldn't you still end up with situations (I am thinking of using rails in both directions) when a signal might work for one path but not for the other? Not sure about that, though, as I do not use tracks both ways.

Of course. But I think with checking stuff while building we can find about 50% of all errors could be avoided for beginners and for advanced players it would be a big help, cause they only make stupid mistakes like the above mentioned. I think the more advanced the player gets, the more this kind of pre-checks pays back.

What about later additions and changes to your tracks? I am again not quite sure (but I think I remember having run into that exact thing) where you have to take out signals on the former line to make the new one work.

Every time, when you change segments/blocks this check is done. Perhaps in background, cause it isn't a problem, when an possible mistake is displayed a second later. The problem begins, when I placed the wrong thing and 10 minutes later I run into the problem. What is wrong then?

I think the cleverness must be so, that it doesn't annoy you.

Don't get me wrong, I am not trying to discredit your idea (which I actually prefer as the easier solution for the player). And I know that I might not have a good enough grasp on the whole train-building-system to throw in my five cents (or to a fellow German ... mustard ...).

That's why this is a discussion.

[orzelek]

I'd really like some kind of warnings being displayed if you create wrong track configuration.

Especially if that means that no train will pass because you created wrong blocks.
Cases when you missed the straight track on corner (been there done that and were surprised at no path message on train) might be more difficult to detect. That would involve trying to actually analyze neighboring blocks not only connected ones.

[Kokelvogel]

@ssilk: I agree that it would be best if you were stopped from even placing something wrong. But wouldn't that mean you'd have to build in a fixed order:
1. tracks
2. stops
3. signals

Yes and no. A check can only happen, when you connect the railway-elements together by tracks. Before that, no check can be done/is needed/makes sense.

I was maybe a bit too cryptic here. What I meant is that you cannot build tracks that have "open ends" (because you just want to build a segment and do a quick test whether or not it does what you think it should). You'd have to build a closed track-system and then do the stops and signals. Which admittedly, isn't that much of a hardship ... as long as the player is aware of this caveat.

And couldn't you still end up with situations (I am thinking of using rails in both directions) when a signal might work for one path but not for the other? Not sure about that, though, as I do not use tracks both ways.

Of course. But I think with checking stuff while building we can find about 50% of all errors could be avoided for beginners and for advanced players it would be a big help, cause they only make stupid mistakes like the above mentioned. I think the more advanced the player gets, the more this kind of pre-checks pays back.

Certainly, not building stuff you'll just have to rip out later saves aggravation.

What about later additions and changes to your tracks? I am again not quite sure (but I think I remember having run into that exact thing) where you have to take out signals on the former line to make the new one work.

Every time, when you change segments/blocks this check is done. Perhaps in background, cause it isn't a problem, when an possible mistake is displayed a second later. The problem begins, when I placed the wrong thing and 10 minutes later I run into the problem. What is wrong then?

I think the cleverness must be so, that it doesn't annoy you.

Sounds good to me. And I think if the error messages are less laconic than right now then it will be less annoying as well. Ideally, there'll be corresponding information (with trouble shooting solutions) on the wiki, so if "Inverse signal" or some such error message pops up you can simply look up what it means and how to fix it

@ orzelek: Especially with tracks I think that the error message can only come when you try to run a train. Or you could have the option of checking a track-layout for incomplete/wrong components (I can imagine this to work in a way that you just left-click on a track and implement a check). So far, visually checking my tracks for track-ends where I do not want them is working fine, but I shudder to think of checking things that way for huge setups.

[ssilk]

I was maybe a bit too cryptic here. What I meant is that you cannot build tracks that have "open ends" (because you just want to build a segment and do a quick test whether or not it does what you think it should). You'd have to build a closed track-system and then do the stops and signals. Which admittedly, isn't that much of a hardship ... as long as the player is aware of this caveat.

Hm. I thought a while about it and what I now think is, that this should be really, really simple. Forget all from above. No explanation, just a graphical marker.

It should work like so:

The tracks have arrows on it in ALT-mode. The arrows look about like now when you build rails/signals etc. But not that dense (only 10-30%). So some rails have yellow arrows on it, if the block shows only in one direction.
If that track leads to a dead end (cause you are currently building it, it has an "open end") then the arrows are orange.
In the map these rails are also orange/red.
Or if you have two blocks or segments clashing together, the arrows are also marked... and so on also for train stops, more or less all situations are explained above.

It is just that simple.