KUDr wrote:richk67: please can you give me some savegame that i can load without tons of newgrf stuff? If you know how to reproduce the problem on trunk head build without obscure newgrfs, i would appreciate such savegame a lot. I would like to understand the problem and then look at it more deeply with debugger. I have played a lot with new 'train is lost' behavior, but never experienced any problem with it. Must be some railway design pattern that i don't use.
Sorry - dont have one. Ive only played on Brianetta's server since RC1 came out. Ask Brianetta for the missing grf - or just wait until I get home from work (yes, Im at work today ).
As for the design - its a long straight mainline at least 400 tiles long. Round trips are about 1 per year.
PS. If you want a quicker way to get the grfs, go to the OpenTTD site, and select the Brianetta Server. The grfs are listed with a hotlink to the grfs in grfcrawler. Only the pb_hovs.grf is not there (the one linked is incorrect).
No. If you can wait until I get home AFTER WORK then I will email you the required .grf (Im not sure if its publically distributable, as its a dev version apparently.)
Seal wrote:@KUDr:
Mr. Wednesday has it right, instead of waiting at the red sign, apparently, it immediately complains about being lost. This confused me.
--
Seal
Hmm, then there must be something wrong. Train should feel lost when stopped on red only if the red signal is two-way. It is by design because if there are two trains going against each other on two-way track and only one two-way signal is between them then those trains are really lost. They can only wait for timeout and reverse.
Is it your case?
Referring back to my diagram, now with signal notations:
The '2's denote two-way signals. There is a depot between C and the two-way signal. There are two trains, one running between A and B and one running between A and C. When a train is between A and the split, the other one will get unhappy, rather than waiting for it to clear the signal on its branch.
I'll try to make a savegame to demonstrate, when I get a chance, which may not be for a couple of days.
Hmm, maybe i am on good way to understand your problem. But when trying to use your layout in practical example i always incline to use one-way signals there. If A track is bi-directional, it needs to be connected to the two-track line by two one-way signals. So signal on the B branch allows trains from A to proceed to B and the other one allows passing from C to A. Or am i missing something?
I was also thinking about the alternative that you would like to have all three tracks (A, B and C) bi-directional. But i can't get such network working anyway. There are always traffic jams. Is this your case?
Hmm, maybe i am on good way to understand your problem. But when trying to use your layout in practical example i always incline to use one-way signals there. If A track is bi-directional, it needs to be connected to the two-track line by two one-way signals. So signal on the B branch allows trains from A to proceed to B and the other one allows passing from C to A. Or am i missing something?
With one-way signals, additional trackage would be required to allow the trains to do the return trip.
I was also thinking about the alternative that you would like to have all three tracks (A, B and C) bi-directional. But i can't get such network working anyway. There are always traffic jams. Is this your case?
I did not have jams -- at that time, I was only using two trains. When I was ready (and financed) to add more trains, I expanded the lines to two one-way tracks.
I installed 0.5 of OpenTTD Yesterday and found that trains get lost very easily.
I'm was using a very simple track, 1 station to another, double rail sometimes with signposts (double) on the entrance/exit of the double rail areas.
This used to work fine, now I get messages about trains being lost.
Anyone else experiencing this?
--
Seal
I did experience this yesterday. I had two trains, on two shourt routes, and they shared one station, with one platform. Every once in a while, one of those trains ran off to the depot, and away from the platform it was supposed to go to. I had no idea why, cus it was the most simple kind of route there can be
Chrill wrote:
I did experience this yesterday. I had two trains, on two shourt routes, and they shared one station, with one platform. Every once in a while, one of those trains ran off to the depot, and away from the platform it was supposed to go to. I had no idea why, cus it was the most simple kind of route there can be
Chrill: please look at the end of previous page how to set the rail_firstred_twoway_eol config value off, do it and try again. Then please tell me if it solved the problem.
Chrill wrote:
I did experience this yesterday. I had two trains, on two shourt routes, and they shared one station, with one platform. Every once in a while, one of those trains ran off to the depot, and away from the platform it was supposed to go to. I had no idea why, cus it was the most simple kind of route there can be
Chrill: please look at the end of previous page how to set the rail_firstred_twoway_eol config value off, do it and try again. Then please tell me if it solved the problem.
Well, first of all, I don't use YAPF. Secondly, I did this at a Multiplayer game yesterday, which now is gone
Thanks to Brianetta's support i was able to load rick67's game. Finally!
The problem seems to be that YAPF returns 'no path' in the case of first signal is red and two-way. And single two-way rail connections are used commonly in this game. I will try to suppress those messages if they happen due to 'rail_firstred_twoway_eol'.
r7628 /trunk/yapf/ (yapf_costrail.hpp yapf_rail.cpp): -Fix: [YAPF] suppress 'Train is lost' message if pathfinding ended on the first two-way red signal due to yapf.rail_firstred_twoway_eol option.
Tell me if it continues to happen on post r7628 builds.
).
