[oliver2]

Greetings to All,

I've created a timetable for the RMD-East route, and now I'm testing it. Mostly freight, only with starting times. I started the TTable in the beginning, around 1:00 AM, riding an observer engine, and typed the arrival times of all trains to a spreadsheet. Then, I selected some mid-day trains to play and opened the Dispatcher window to check the train positions.

I found just after the loading done that AI trains are not where they should be! Some of them are O.K (less than 5 min late), but others are up to 20 minutes late. Even some of them is early.

So AI trains which start before the player, behave (or calculated) differently than AIs created after the player.

I checked the trains tonnage and power, but it isn't the problem. Underpowered trains can make its schedule, but some overpowered ones are late.

It is possible that OR calculates train movements differently at startup than in-game? If so, it'll be impossible to adjust the train schedules correctly. E.g. if there are 2 trains, A and B, and A starts earlier, the train meet wont't be a same, depending on A or B is chosen as player train...

In my single example, I wanted to insert the North Coast Limited among the freights, and altered the times to prevent the NCL wait to freight trains. The result: when I select the NCL to play, all train meets are OK, but when I select any train which starts before the NCL, everything blows up: the NCL have to wait to a MILW freight at a level crossing at Sappington and after that a NP freight at Spire Rock station, and then approx. 20-30min late...


Shortly, my question is: is it possible to calculate the trains correctly in OR Timetable mode, to reach a stable result?

[roeter]

Inevitably there are differences between the running of AI trains and the player train. Partly this is due to the different human reaction to changes or required changes ahead (e.g., a player brakes too early for an upcoming speed restriction). It is also caused by differences in physics, in particular relating to wheelslip and acceleration. Another aspect where AI and player performance will differ is on gradients where a player train using actual physics might not be able to reach linespeed, but for AI trains the physics are overruled and these will run at linespeed regardless of any gradient and possible lack of power.
This cannot be avoided, and can lead to timing differences between AI and player trains. Usually this is just a few minutes, and usually the player train is the slower one. I have not seen differences as much as 20-30 minutes unless there were problems with train regulation commands (e.g. $wait commands which caused blockages).
Some timetables which I tested were based on real timings and worked within minutes of reality.
So, I have no explanation as to what happens on your route.

I do have some advice : rather than testing a timetable running a selected train, it is much better to run tests using 'observers'.
An observer is a player train which is located in an otherwise unused siding, and which isn't going anywhere. With the player as 'observer' and not taking part in the actual traffic, one can observe all that is happening and sort out timings and any unexpected hold-ups etc. You can watch the trains go by at the observer location, but also keep an eye on the F5 dispatcher display to check on what is happening elsewhere. With the player not taking part in the traffic, the player will not influence the cause of events and the timetable can be worked through such that all timings are correct for the AI trains. When the timetable has been sorted out in this way, you can try and see if you can run a player train to the same timing as the AI trains. As I said, there is likely to be some difference. If all crossings etc. are left to be sorted automatic and are critical to even a few minutes difference, you should consider setting $wait commands to influence the sequence of trains. Note that if two trains can meet only once (at a crossing rather than a loop), you can set the $wait in the #note field, and do not need a platform location. For trains running in opposite directions on the same route which need to cross at a certain location, you have the choice to either set a $wait command for which you will need to have a platform location, or if there is no platform, you can terminate a train at that location and have if form into a new train with the $wait defined in the #note field.
If the route is very long, it could help to regulate trains by terminating them in a yard and have them form into a new working with a fixed start time, as a buffer to any timing deviations.

I have run timetables upto about 2000 trains, and it did not matter what time I started or what train I selected as player train. Admittedly, these were all passenger trains which ofcourse have the advantage of having regular stops and therefor cannot 'drift' too much in time. They also do not suffer from loss of speed at gradients as heavy freight trains might do. Futhermore, all critical junctions were regulated using $wait commands.

Regards,
Rob Roeterdink

[oliver2]

Hello roeter,

Thank You for the detailed answer :) I explained myself wrong, I'm indeed using observer consists to check the timetable.

This early morning I prepaired to give more details about this problem. I created a mini-timetable with just one moving train (let's name it train X) and an observer, to show the slight differences in arrival times depending on the starting time-of-day. I noticed that the observed train X gaining more than 5 min late after 20 min running, if I start the sim as observer after the X starts.

The late running also occurs if I start the sim before train X starts, and raise the sim speed up to 700%.

But after this small experiment I updated OR to the recent X3936 (before that I used X3845) and the train X now is on schedule, whatever happens. Then, our baby woke up so I went AFK :) But further examining has to be done.

Thank You for the tip that the wait command is usable also at level crossings, not just at passing loops. I didn't know that. However, I'm sure that solving this issue is necessary because refining a timetable is really a time-waste. Loading the afternoon and evening runs take 10-20 minutes.

I'll report later wether it's solved or not in the updated version X3936.

Greetings!

Peter