[Aldarion]

ah... oh... ok! In the timetable editor... :whistling:

[Gwyd]

Weter, on 15 March 2022 - 12:19 PM, said:

Hello.
Correct syntax must be:
$triggers=train

Yes, sorry it is $triggers=, but the timetable defaults to $triggers /triggers=, which appears in my experience to crash the loader.
I'm having more problems:
Since the crashes started, I've been keeping a closer look at the log file, and there are a lot of errors relating to passing paths.

On all paths between London Bridge and New Cross there are 2 parallel tracks that trains can equally use (with the odd exception). For Charing Cross trains, there are simply 2 tracks along side eachother. I thought that setting one track as the main path, then the other as the passing path would allow trains to pick whichever one was free. For Cannon Street trains, they can use the Up line (towards London), the Down line (away from London) or the reversible line, so the passing path is set to be down this two way track. The assumption is that if the main route is occupied, the train would go for this other route, in a bid to save being delayed. In my testing, this seems not to be the case, and the train will wait for the occupied platform when there is a free one on the passing path.

My other issue is at the termini: Charing Cross and Cannon Street both have pretty terrible platform markers, only covering about half the actual platform and ending a fairly large distance from the buffer stops. The AI trains stop so short in some cases that they foul the points on the station entrance. I can't work out which command I need to set to convince the AIs to pull all the way up to the buffers.

Any help would be much appreciated:)

[Weter]

Hello.
Please, try to remove
$triggers /triggers=
It must be just
$triggers=train
$triggers is standalone command for #dispose row - it requires only new train's name, while /triggers is a qualifier for $attach/$detach commands.
So $triggers=train /triggers looks like wrong attempt for me.

For terminal platforms use $terminal command for whole station string or for individual trains.
You have to choose: whether You check an "Automatic Passing Paths Processing" in options menu, or manually define passing sections, while editing particular path.
These two measures don't work together - there must be only one solution picked. And for ORTS timetable mode, automatic processing of simple (not furcated) paths seems preferable.

[Gwyd]

I've tried $terminal, which just stops the trains at the end of the platform marker. This is good, but not ideal.

I have also tried $extendplatformsignal, as well as $keepclear /rear=20 /force. These two do better but seem to give a similar result to each other, where the train stops around 30m short of the buffers (see attached image, apologies for the .jpeg but I can't seem to upload a .png). The second image with red lines shows the approximate area where there is actually platform.
 CHX.JPG (23.12K)
Number of downloads: 0
 chx2.JPG (25.65K)
Number of downloads: 1

[Gwyd]

Weter, on 20 March 2022 - 01:40 PM, said:

why don't edit markers, dragging their ends with TSRE?
by default, trains are trying to fit their miggle car with the center of marker

This isn't too hard to do but I worry that people may have unexpected results if they use the timetable with the original LSE route

[Weter]

Sure, they will.
As long, as Your project is intended to be published.
Otherwise, negotiation with route author(s) will be needed - to issue a patch, coming with Your timetables pack.

I'd at least ask them (if possible) about the reason (if it only was no by occasion), for them to place those markers in such odd manner.

This way, You may correct a missed mistake - for common benefit.

[cjakeman]

Weter, on 20 March 2022 - 03:46 PM, said:

Sure, they will.
As long, as Your project is intended to be published.
Otherwise, negotiation with route author(s) will be needed - to issue a patch, coming with Your timetables pack.

I'm in touch with Dave Babb, the owner of Making Tracks. He's been helpful to Open Rails in the past, so I hope he would be again.

[roeter]

Gwyd, on 20 March 2022 - 01:12 PM, said:

I have also tried $extendplatformsignal, as well as $keepclear /rear=20 /force. These two do better but seem to give a similar result to each other, where the train stops around 30m short of the buffers.

Use $extendplatformsignal, and add /closeup to the $triggers command in the #dispose field. That will bring in the train closer to the buffer stops.

Regards,
Rob Roeterdink

[Gwyd]

None of the above appear to work, so I've settled with simply extending the platform markers for now since I already had TSRE installed. I still have my CD so can reinstall the route if need be. If anyone else with LSE can make a small timetable demonstrating this working I'd like to see it. At the terminus stations it's not a huge deal, since OR just teleports the train onto its path.

[Gwyd]

I've been doing some research and I've found that there is some... interesting route geography on MT's LSE, to be expected from a 2004 route I suppose.
I discovered this when testing some services, and I reliably found the 3 minutes timing for Lewisham-New Cross to be very hard to keep up with. The route has London Bridge-Hither Green as a near dead-straight line all the way, where as in reality the line to Lewisham is almost straight but the line to Hither Green takes a rather sharp southerly turn. This funny geography has some rather funny implications, such as the notably straight Tonbridge-Redhill railway being, well, not straight. I've overlaid the map from the track viewer (black) on a map of the actual railway (pink)
 map.jpg (52.61K)
Number of downloads: 3
Anyway, I'll press ahead with the timetabling. The only slight issue is the inaccurate track layout in a couple of locations, namely Lewisham, where a 4 track arrangement with a double crossover has turned into a diamond crossing, means that not all the trains will necessarily work. Oh well. We'll see what comes of it

[Weter]

I wish You success, Gwyd, as I have exactly the same problem with dilemma between real-life charts of different years and unperfect track work modeling, with which I have to work (I currently correcting some mistakes of route builder: at first, without touching tracks themself)

You are welcome for sharing gained experience of working around such issues.

What about posted map comparation, I feel disappointment, how inaccurate that payware add-on was with topographic base.
People paid their money for real-looking route, which prototype might be very familiar to some of them.
As a result, that's no possible to define real timetables on it...

Or did they posted a disclaimer, something as "this is only semi-real route/fictious route, based on ... network map"? That would be fair.

[Aldarion]

That's why I always had my priority on track geometry rather than following coordinates on a marker file taken from google earth...
Now I have a Route with the correct milage, were I can establish working timetables.

[Gwyd]

It's been a while, I'm still making (slow) progress on this timetable (up to about 40 train diagrams complete out of 250+). I have been working on services that join and divide, which has been fairly tricky (doing it the wrong way can make the game crash when driving the service, or make both trains disappear otherwise). I've worked out how I'm meant to do it now, and I'm trying to improve my paths (trying to create some sort of script that can automatically write a lot of them) and try using the $follow command on areas with bad congestion, even if this congestion is somewhat realistic. I'll try upload an "in progress" version of the activity soon if there's any interest.

[Gwyd]

Hello all, I continue to work on this timetable. I'm currently 500 services in and I've hit a few issues. Two were related to signalling: a) I needed calling on signal behavior for some coupling maneuvers, but this was a fairly simple thing to do. b. there is one signal that, both before and after my OR signal scripting, seems to erroneously stay at danger (red). There are no other signals on the route which seem to do this. The signal is a 4 aspect protecting a single diverging junction, each with another 4 aspect signal behind it on each branch. Looking visually at the track there is nothing to block it, and looking at the path info of the train waiting at the signal it seems it should be free to go. The signal will usually wait until the station (London Bridge P6) is cleared by the train ahead before giving a green aspect. There are 3 signals between this signal and the occupied London Bridge P6, so it doesn't really make sense. See images attached, any help would be appreciated as it makes the timetable pretty congested.

Attached File(s)

•  Sig1350.JPG (20.29K)
  Number of downloads: 0
•  Train148.JPG (4.02K)
  Number of downloads: 0

[roeter]

To find out what's happening, it would require to use the signal-script debugging functions which are part of the signal script processing.
Sadly, someone (not me!) changed the signal script code but did not properly update the code for the debug functions, which means these rather essential functions are no longer available.
Presently, due to this (serious) oversight, the program will no longer compile when these debug functions are activated.

Regards,
Rob Roeterdink