Accuracy of train delayed messages

You are here: Home > Forum > General > General questions, comments, and issues > Accuracy of train delayed messages

Page 1 of 1

Accuracy of train delayed messages 15/01/2016 at 23:33 #79889
Danny252
Avatar
1461 posts
Currently, reports of trains being late sometimes appear curiously specific. Yard controllers is able to phone you up to tell you that he's having trouble getting a train ready, but using his magical powers is able to predict that it will be exactly 48 minutes late. Similarly, a driver with brake trouble will be able to predict exactly how long his train will be waiting for a fitter. This feels somewhat unrealistic, and also means that the signaller is able to simply clear the signal for a delayed train at the stated time and only incur at most a couple of minutes delay (I get the impression the delays are slightly randomised compared to the quoted times).

Would it be possible to look into giving more "human" estimates? For example, all delays over 15 minutes could be rounded to the nearest 5, giving a report of "Train XXXX will be about 25 minutes late" for delays of 23-27 minutes. If someone is feeling very creative with their coding, longer delays could result in increasing ambiguity, e.g. 15 minute steps after 1 hour, half hour after two hours, and whole hours after three (is anyone insane enough to set the delay slider that high?!).

Last edited: 15/01/2016 at 23:33 by Danny252
Log in to reply
Accuracy of train delayed messages 16/01/2016 at 00:49 #79891
AndyG
Avatar
1835 posts
I did make a wish list item (# 14415) to have some delays without an ETD, so you don't know when the train is good to go until it is.

Quote:
When trains are delayed, occasionally a train will be delayed without an ETD being given.
Will require signaller to keep options open!

I can only help one person a day. Today's not your day. Tomorrow doesn't look too good either.
Log in to reply
Accuracy of train delayed messages 16/01/2016 at 01:11 #79892
GeoffM
Avatar
6287 posts
Online
" said:
Currently, reports of trains being late sometimes appear curiously specific. Yard controllers is able to phone you up to tell you that he's having trouble getting a train ready, but using his magical powers is able to predict that it will be exactly 48 minutes late.
They're reported in 5 minute windows so it wouldn't be exactly 48 minutes, it would be 43 to 53 minutes depending on how I round it (can't check right now - wrote that a long time ago).

Yes it could be improved.

SimSig Boss
Log in to reply
Accuracy of train delayed messages 16/01/2016 at 09:16 #79894
Danny252
Avatar
1461 posts
That does sound like my experience, although a 5 minute leeway either side sounds large compared to the normal variation I see.
Log in to reply
Accuracy of train delayed messages 16/01/2016 at 16:50 #79909
Jan
Avatar
890 posts
" said:
They're reported in 5 minute windows so it wouldn't be exactly 48 minutes, it would be 43 to 53 minutes depending on how I round it (can't check right now - wrote that a long time ago).

I think the rounding is applied only for delays within the sim, i.e. those where the driver is actually phoning you.
The messages appearing in the incident report (like "7Z07 running 12 minutes late"seem always accurate though and are reflecting the delay visible both via F4 and F8. The problem with those is that (effects of rules aside) this delay value seems to be calculated only once.

So if you look up the entrance delays on the simplifier, the delay values shown normally won't change - if a train not due for another hour is shown as RT, it will enter RT after an hour's play and likewise if it's shown as 15L, it will enter 15L.

Now that timetables can include the origin departure time, one possibility would be to more frequently recalculate delay values to simulate the train gaining/losing time while en route. Basically you'd calculate an initial delay relative to the origin departure time (to simulate passenger trains leaving late right from the terminal station, or freight trains leaving their terminal early/late).
While en route between the actual origin and the sim boundary, trains would then have a certain chance of being delayed and a certain chance of gaining back time, dependent on a number of factors:

  • F3 user settings

  • sim developer settings

  • class of service (passenger trains never run early and usually depart on time from their origin station, freight trains have a higher chance of running late/early right from the beginning etc., general delay distributions might differ for different classes of service, ...)

  • current delay (trains running early might have a lower chance of gaining time, late-running trains above a certain threshold might have a higher chance of becoming further delayed to simulate missing their path etc.)

  • time of day (during day time an early running train might be more likely held to time, congestion effects during peak hours etc.)

  • loss of power

  • train operator (like the special treatment for XC trains in Swindon)

  • general delay probability and amount of timetable padding (sim defaults provided with an override configurable for each train's schedule)

  • ...



This could mean that e.g. when you look up a train in the simplifier it shows as RT, but when you look it up thirty minutes later, just before it is due to enter, it might possibly show as 3L.

The big difficulty with this approach however would be fine-tuning the delay distributions to give a realistic distribution of delays when the trains finally enter the simulation. For trains entering from sidings within the sim, the origin delay would be the major factor influencing the total delay, which could probably work similarly to today.
For long-distance trains on the other hand, the en route delay would be the major factor, which is probably a bit more difficult to get right, especially when some trains might be "running" off-sim for six, seven hours or more, e.g. XC trains originating from Bristol or somewhere beyond and then entering Edinburgh sim.

I've attached a small Excel spreadsheet demonstrating the general principle - if you play around a little with the padding factor or the various delay distributions, you can see that depending on the chosen probabilities, it is very easy to generate distributions where nearly all trains are running to time, or alternatively, where all trains are running very late after several hours, which normally probably wouldn't be the desired effect.

Post has attachments. Log in to view them.
Two million people attempt to use Birmingham's magnificent rail network every year, with just over a million of them managing to get further than Smethwick.
Last edited: 17/01/2016 at 13:10 by Jan
Log in to reply
The following user said thank you: BarryM
Accuracy of train delayed messages 17/01/2016 at 10:57 #79929
kbarber
Avatar
1712 posts
" said:

While en route between the actual origin and the sim boundary, trains would then have a certain chance of being delayed and a certain chance of gaining back time, dependent on a number of factors:

  • F3 user settings

  • sim developer settings

  • class of service (passenger trains never run early and usually depart on time from their origin station, freight trains have a higher chance of running late/early right from the beginning etc., general delay distributions might differ for different classes of service, ...)

  • current delay (trains running early might have a lower chance of gaining time, late-running trains above a certain threshold might have a higher chance of becoming further delayed to simulate missing their path etc.)

  • time of day (during day time an early running train might be more likely held to time, congestion effects during peak hours etc.)

  • loss of power

  • train operator (like the special treatment for XC trains in Swindon)

  • general delay probability and amount of timetable padding (sim defaults provided with an override configurable for each train's schedule)

  • ...



Isn't that last one the random 'Driver on a finishing turn'/'Driver making overtime' factor, linked to huge time gains/losses per mile respectively?

Log in to reply
The following user said thank you: Jan