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

Do not go to the depot when you cannot continue from there #1305

Closed
DorpsGek opened this issue Oct 6, 2007 · 10 comments
Closed

Do not go to the depot when you cannot continue from there #1305

DorpsGek opened this issue Oct 6, 2007 · 10 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented Oct 6, 2007

vc-labs opened the ticket and wrote:

Happens sometimes to trains successfully servicing same route for years, although no any construction has been applied to related railroad or any joined stations.
This message is confusing, given the train proceeds as usual.

Alike messages may come up from a binded vehicles long time after completing station' reconstruction, kinda the've been stacked somewhere for certain time term.
*
I think the message-related conditions should be re-checked before poping actual message to the screen.
It's good idea to delay such messages for a certain amount of time to prevent disturbing player during the construction works, but when the construction is done, appearence of such messages is quite confusing.
At the same time these messages are ultimatively useful, been poped at right time (FE, if you miss some tiles during railway conversion).

[r11208 and down to release 0.5.3]

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/1305
@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2007

Rubidium wrote:

Add a savegame so you can actually show us the train is NOT lost when it says it is.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1305#comment2346

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2007

vc-labs wrote:

Right here, attached.
The message stated: "Train 14 is lost".
The message poped up at the moment the mentioned train was leaving the station it's currently heading from ("Hator"), so I paused the game and switched to that part of map to find out what's going wrong, but didn't find any problems.
Right before that I was dealing with a far-away towns at the edge of the map and didn't pay a visit to this part of the map for a long time.

It's hard to reproduce the actual message, given it's spontanic. But, in case it's important, next time it will happen, I can take screenshot with message still on the screen and attach it along with saved game. Let me know if you want me to do this.

In case it has any sense: this game played with Pikka's UKRS trainset replacement, along with other new GRF sets.
Sorry I didn't attach saved game first time - I decided not to do this because these events are quite spontanic and not reproducible.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1305#comment2347

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2007

vc-labs wrote:

...All right, it happened again.
This time I took screenshot; PNG attached along with gamesave.
Same train, 3 years later.
Once again, different part of the map, long-time construction works over different railroad net (caused by another issue, which I'm about to report right away).
The screenshot taken in paused game, right after pop came up. The map even wasn't scrolled to the place mentioned in pop-up...

***

...Now - another issue (which forced me to re-build the multi-platform station on the screenshot and separate connections to platforms for different railroad lines).
In the upper left corner on the screenshot is a window with train # 17, which I was overwatching for a long time, all it's long journey from a newly-built faraway station (the windows stacked in the left corner - other trains following same route behind # 17).
All the platforms on that station was previosly connected in parallel and separated by semaphores from both ends (see in first gamesave I've uploaded). But from time to time trains use to leave this station in wrong direction (strait opposite). It was happening when another train was entering or leaving the station or depot right ahead of station, temporary locking the intersection.
But the most interesting thing - none of these wrong-directed trains even tried to turn back at the intersection on another end of the station (which I was overwatching many times in earlier versions of TT). They used to proceed all the way down opposite road and turn back only at the intersection afront of the faraway station at the end.
*
I was under impression that this behavior was reported and resolved long time ago, but seems it doesn't. Something still wrong with the Path Finder (or AI?).
Should I try to collar this situation, make a shot and place separate report, or you're already on it?..

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1305#comment2348

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2007

vc-labs wrote:

Sorry, I missed a line.
The reason to re-buid this station was that train # 17, which was cought (given I was overwatching it) right at the moment it was attempting to leave the station in opposite direction. At that moment another train was leaving depot ahead and enrouting away to its own station.
I didn't stop # 17 and allowed it to follow that wrong way to see if it will turn back at the intersection behind the station; but it didn't. So I stopped it and turned back manualy...

The related game setting is correct: trains allowed to turn back at the stations.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1305#comment2349

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2007

vc-labs wrote:

Keep happens.
Still same train # 14.
The railroad it belongs to stays untouched over 7 game years, since it was build.
Train makes good profit; no any interruptions in service.
Events look random, no any pattern seen.

I think it's enough proof on that issue. Quite certain it happens, have no any idea about the reasons.

*) There're very few vehicles in that game. When you have hundreds of them, these messages pop up frequently and it becomes really annoying.

**) I have the only suspection that it might be triggered by re-building the station. All 3 mentioned messages poped up showing this train (# 14) entering or leaving same station ("Hator"), which was re-built once (to separate opposite roads from each other, - see another mentioned issue), just after few first rides of this train.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1305#comment2350

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2007

vc-labs wrote:

... I believe I already know why and when it happens.
Seems, this confusing message comes up when the train has to return back to the station it just left in order to be able to proceed to next destination point. FE, if right after leaving the station it decides to visit depot, which doesn't have strait connection to the railtrack, following in required direction.
If such event triggers this message, it suppose to say something kinda "track is not optimized", given the train still able to reach destination point.
It's a bit strange behavior, considering the second issue, mentioned in this thread, when the train leaves the station in opposite direction and follows all way down the wrong road. In that situation no any messages come up.
I think it has to be corrected somehow...


This comment was imported from FlySpray: https://bugs.openttd.org/task/1305#comment2351

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2007

Rubidium wrote:

Apsheron, 18th Oct 1936.sav: the "lost" message of trains number 17, 18 and 19 is correct. They cannot reach Patricia Mines from the position where they are at the given moment in any way. This is due to a signal facing the wrong way at tile 875x300.

Apsheron, 11th Mar 1938.sav: cannot reproduce it in that game.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1305#comment2352

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2007

vc-labs wrote:

Yes, I know it, I didn't mention these messages if you check the posts above. That's why they had their control windows open, - I've been overwatching them untill they'll successfully make their first 2-way run. As soon as I saw # 17 (the head one) turning back in front of incorrectly settled semahore, I stopped it and fixed the mistake. So it was no reason to report these messages, because they were correct.

Meanwhile, it's also a minor issue here. Given these messages do not offer any details, one has to follow such train and overwath it all its long journey untill it will actually face the problematic part of its route. Sometimes it's really hard to find one forgotten non-electrified tile, or wrongly faced light.
I think the major problem with these messages - they do not pop-up at correct time; as well as the incorrect supplemental train behavior.
I think the train should not try to turn back and go anywhere when it reaches the non-passable part of the route. Instead it should stop and pop-up the message that it faced the problem on the way and unable to proceed anymore. Then it will be easy to find and fix advertised problem, and there will be no need to trash the screen by the windows of overwatched vehicles.
What do you think?..

So, it looks for me that all issues mentioned in this thread are connected to one pack:

  1. Lost Train Messages do not provide details.
  2. They come up at the wrong time (far ahead or far beuond).
  3. Wrong train behavior (turns back or picks wrong way rather than stop).

In addition, as I mentioned it for train # 17, the train may follow the wrong direction not producing any warning at all.

As per train # 14, it appears that it produces these messages because it cannot go from depot (which it use to visit ocasionally after leaving "Hator" station) strait to destination point (no track connection in required direction) and has to return few tiles back to the station ("Hator") to be able to proceed in right direction.
So, in fact, the message it sends is correct: train cannot proceed strait to destination from the point it's currently is and it tries to find alternative way (and does it successfully).
Meanwhile, the major problem is hidden exactly here: how did this train got itself to no-route point?
The only way to that depot from the station lays aside of its route (which is clearly set in its order list). The train should not pick the wrong way, which it cannot proceed further from, but it does.

And here is one more issue comes up to mind.
If the railroad splits, the major problem is - the depot. The train, which needs service, use to turn to the road branch with a closest depot, totally ignoring the fact, that it will not be able to return to its own route from that point.
Even if I place depot right ahead of track splitting (which is not allways possible), it happens sometimes anyway, due to fact that service time may come at the moment the engine already passed the depot junction point, but yet didn't pass the road split junction, which is on the next tile.

***
I think none of these issues would take place, have the PathFinder algorithm been improved to proshibit trains to leave their designated route farther than to point of no-return.

I know it's not eazy, given it probably comes to AI, but here is one suggestion:
If the train has to change the route in order to visit depot, it should first check if it will be able to reach its destination from that desired point (depot).
Then, if the depot separated from it route by one-way signal, train will not be allowed to turn, because the way back is unpassable.
When it comes to situations kinda described with train # 14, the train would not go to that "Hator" depot, given it will pre-calculate that it will not be able to reach destination from that depot, and will proceed along its designated route to the next depot, which does offer strait path to destination.

So, let's put it simple. If the train to visit depot, the PathFinder to apply to that depot first. If it fails - train not allowed to that depot and should check the next one on the way, and so on.
What do you think?


This comment was imported from FlySpray: https://bugs.openttd.org/task/1305#comment2356

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 8, 2007

Rubidium wrote:

Well... if the train could get from the station to that depot, there must be a way back to that station. Otherwise it would mean that is no other train going from Hator in the direction of that depot (when leaving Hator), so the piece of track is there for absolutely no reason, unless you intend to make one big interconnected network, but then you must actually make the network connected.

Furthermore trains will not deviate from their path if the depot is more than 16 tiles away. This is very easy to consider in building your network.

What is more annoying than a single lost train to totally jam up your network?

You seem to be the only one with issues with the order review system. If it does not suit your way of making "networks", you can always disable it. You can also disable it when the windows popping up annoy you.

They really pop up at the correct time... when the system finally decides that it is genuinely lost, which it isn't immediatelly after leaving that depot.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1305#comment2361

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 5, 2017

andythenorth closed the ticket.

Reason for closing: Won't implement

10 years is long enough to determine that this is not really a problem.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1305

@DorpsGek DorpsGek closed this as completed Aug 5, 2017
@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) Vehicles labels Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant