[PA1930]

Fantastic work, Rob.

Though, I'm going to apologize and request for a "drawing" or a more explícit explanation about where to put the files and how to actually make this work.
I am one very interested about this, but I already gave it a shot and I couldn't have the timetable mode anywhere in the ORTS menu.
Also yes, I've read the PDF file but still no ideas... Sorry.

Can you help with that, please?

[roeter]

RTP, on 25 May 2014 - 04:02 AM, said:

Mr. Roeterdink:

Please include a list of the required material.

Cheers.

RTP.

Sorry - but I don't quite understand your question.
There is no required material to create a timetable.
You can use the same paths, consists, trains etc. as in activities. The timetable is only a different way of organizing things, but there is no change in actually running trains - either AI or player trains.

Does this answer your question?

Regards,
Rob Roeterdink

[RTP]

The material is not needed to create a timetable, but to run it, like an activity.
Imagining the material needed reading the name of the consists is a bit arduous.

Cheers.

RTP

[roeter]

Quote

I am finding the AI behaviour a little difficult to work with, approaching station stops it appears to brake too much/too early and then crawl slowly forward to the platform, as a consequence the AI always runs late. Comparing the same short (approx. 20mins with 6 station stops) service as AI and Player results in a 5 minute difference. Player train is 2 minutes early at final stop and the AI is 3 minutes late. Is there any way to adjust AI performance?

Quote

I believe (though Rob will surely correct me if this is wrong) the AI in OR basically uses the controls you as a player would have (although with the simple adhesion model IIRC) which means it can sometimes struggle to get the train to do what it wants. It does have some overrides (e.g. it can brake harder than the consist would actually be able to do, if it isn't stopping as fast as it needs to).

Basically, James is right.
The problem in controlling AI trains is that the system has no knowledge of specific behaviour of the AI train. As player, you learn to adapt to the characteristics of, for instance, the braking system. You learn that some specific train has a braking system which is slow to react, so you apply the brakes early and wait until the reaction sets it. Other stock brakes more quickly so you apply the brakes much later.
Alas - the AI controller does not have that 'knowledge', and so has to treat all trains in the same way.

Also, you do sometimes get it wrong as player and overshoot a platform or even pass a signal at danger. But that should not be allowed to happen to AI trains.

So some precautions are taken in the AI control to avoid mishaps and ensure the train stops in time, whatever the braking system. These include a safety margin with regards to the location where the train is to stop, and an override if the train is not slowing down fast enough.

The principle is fairly straightforward. Trains have an average deceleration value, and using this value and the present and maximum allowed speed, a braking distance is calculated, and this is converted to an 'activate' location - when the train reaches that location it must start to prepare to stop. You can see this in the Dispatcher HUD in F5 : that is when the state of the train changes to "BRAKE" mode.
From that moment on, an ideal speed is calculated which follows the estimated deceleration. An allowed speed 'band' is used around this ideal speed, and if the train is still going too fast, brake application is increased and if it is going too slow, brakes are released. If with full brake application the train still does not slow down enough, the 'override' kicks in and simply reduces the speed directly.

All this is set up in such a way that the train will have slowed down enough when it reaches the safety margin position. From that position onward to the actual stop position the train will move at 'creep speed' (about 5 mph). The length of the safety margin depends on the allowed speed at that location - higher speeds will result in longer safety margins.

This exactly matches the observations noted above : the train will slow down such that its speed will have been reduced sufficienly when it reaches the safete margin position. From that point on it will run at 'creep speed' upto the required stopping point.

If this means that AI trains loose time depends very much on the used trains and the local situation. If speed through the station is relatively high, it means a longer safety margin and thus a longer time the train runs at creep speed. Also, if stock is used with modern, quick braking systems that would allow the player to apply the brakes later as the average AI train will do.
On the other hand, if you have stock with slow brakes, and speed at the stations is low, the AI trains can actually be more efficient and better at timekeeping than the player train.
Without more detailed knowledge within the program of the braking characteristics of the train etc., there is no way this can be improved.

Quote

AI trains are trying to reach the station exactly at the set time, if early, they are slow down.

Nope - that's not so. There is no interaction between train speed and expected arrival.
Arrival times at stations are only used to calculate required dwell time, or to determine delay in case a train is to be held for a connection (see $connect command).

Quote

Though, I'm going to apologize and request for a "drawing" or a more explícit explanation about where to put the files and how to actually make this work.
I am one very interested about this, but I already gave it a shot and I couldn't have the timetable mode anywhere in the ORTS menu.
Also yes, I've read the PDF file but still no ideas... Sorry.

These are the required steps :

• Create a spreadsheet file (e.g. using Excel or something similar) - anywhere.
  
• Save the contents of this spreadsheet as *.csv (should be an option in the spreadsheet program).
  Use either comma or semi-colon as separator.
  
• Rename or copy the *.csv file to *.timetable_or (e.g. : ttfile.csv to ttfile.timetable_or).
  
• Create a subdirectory "OpenRails" in the "Activities" directory of the required route.
  
• Place the *.timetable_or file in the OpenRails subdirectory as created above.
  
• And saving about a thousands words to describe it :
  

Regards,
Rob Roeterdink

[JohnnyS]

roeter, on 25 May 2014 - 04:37 PM, said:

Basically, James is right.
The problem in controlling AI trains is that the system has no knowledge of specific behaviour of the AI train. As player, you learn to adapt to the characteristics of, for instance, the braking system. You learn that some specific train has a braking system which is slow to react, so you apply the brakes early and wait until the reaction sets it. Other stock brakes more quickly so you apply the brakes much later.
Alas - the AI controller does not have that 'knowledge', and so has to treat all trains in the same way.

Yeah, I understand that the AI doesn't have knowledge of specific stock characteristics, and I can only imagine how difficult it must be to create an AI model that caters for all of the possible eras and systems that the cosmopolitan world of Train Simulation provides.

roeter, on 25 May 2014 - 04:37 PM, said:

So some precautions are taken in the AI control to avoid mishaps and ensure the train stops in time, whatever the braking system. These include a safety margin with regards to the location where the train is to stop, and an override if the train is not slowing down fast enough.

The bottom line for me at least in this particular situation is the trains don't stop in time. I have done some crude experiments. Sitting in a second train waiting for the first, shows that with the original timetable the first train arrives 3 minutes late. Observing the AI performance with the Alt+9 camera view and the F10 display showing the time I can see the AI loses approximately 30 seconds per station stop.
Adjusting the timetable to add 30 seconds travel time between each station results in a very similar 3 minute delay.

Changing the consist for completely different stock (before was local service 2-car DMU, after is fast regional service with fast electric loco + 3 coaches)results in a similar delay.

roeter, on 25 May 2014 - 04:37 PM, said:

This exactly matches the observations noted above : the train will slow down such that its speed will have been reduced sufficienly when it reaches the safete margin position. From that point on it will run at 'creep speed' upto the required stopping point.

From my limited experiments giving the AI longer travel time to cope just made it 'creep' for longer. Perhaps this part of the process needs some refinement? What are your own experiences with the Surfliner timetable provided above? Would be interested to know other peoples experiences, has anybody else out there tried making a timetable?

I shall try some other routes and stock from different eras and see what happens.

Cheers,
John.

[Lindsayts]

Now this is a VERY interesting development and congratulations all round one may say, Now............

As I believe for PA1930, I find the two documents, the concept and the example difficult to rationalise. This is due to the great complexity of the example. It being quite difficult to track down how everything works.
It would be nice to have a simple example with only a handfull of trains doing as much in the timetabling as the simplcity of the example allowed.
This would make the example easier to study both in the spread sheet and the csv file, with the reference document.

It is likely one is never meant to directly work on the csv file, overall though its always nice to be able to do it that way.

A question, the example has 3 pages/sheets Libreoffice only saved the first page/sheet to a csv file. Mind you this has 511 columns the longest row being at least over 6000 characters in length.

Lindsay

[roeter]

Quote

From my limited experiments giving the AI longer travel time to cope just made it 'creep' for longer.

Sounds odd. There is no relation between the station times and the process which runs the trains. Only when the train has come to a standstill at a station is the timing used to set the moment of departure.

Quote

Perhaps this part of the process needs some refinement?

It literally took me years to find a proper balance between running the trains and stopping them in time. Unless someone comes up with a proper calculation which results in a more precise braking characteristic based on consist and braking system, I will definitely not make any changes to that logic. I most surely do not want to see those lines "Train passed signal at danger" back in the logfile.

Quote

What are your own experiences with the Surfliner timetable provided above?

Surprisingly good, actually.

There are two main reasons for delay but these are not caused by actual running perfomance :

• Delays occur because the system 'selects' the wrong passing loop for trains to meet.
  This is in particular a problem on the long single track section between Laguna Nigual and Oceanside. It causes delays of upto 20 minutes on some services as these are held in the wrong location.
  These in no easy way out of this as yet - only the definition of additional 'locations' (other than station stops) could help out here, but that is still a long way off.
  
• A number of services are delayed because of congestion in the LA area, in particular during the rush hours due to the large number of empty stock workings between Union Station and the Metro Yard. Some fine tuning of paths and timings of ECS workings might help here, but I have not yet looked at this in any great detail.

Apart from this, this is what I observed per route :

• Surfliner : generally quite well, many trains on time or just 1 or 2 minutes late.
  
• Coaster : very fine - most are on time. Some delays due to congestion at Oceanside.
  
• AMTRAK Coast Starlight : timings seem to be very generous, with trains often arriving 5 minutes early.
  
• Metrolink Orange County : most are allright, but some services are 10 - 20 minutes late.
  Not sure yet what is causing this, but the complex movements of empty stock around Laguna Niguel could well attribute to this.
  Many trains terminate and reverse at Laguna Niguel, but there are no reversal or stabling sidings in this area.
  
• Metrolink Ventura Valley : the only service where there seem to be some basic problems.
  All long distance services on this route (to and from East Ventura, Chatsworth and Moorpark) somehow accumulate a delay of 10 to 15 minutes. Strange enough, the Surfliner and Amtrak trains on this part of the route perform well.

In all, it's quite acceptable, especially given the complex nature of the route and the timetable, with long single-track sections and trains reversing at all kinds of locations often without proper reversing facilities. Oceanside, Lagune Niguel, Burbank Airport, Chatsworth are all used to reverse trains and all are without any usefull sidings to do so. Proper reversing and stabling facilities are actually only available at Goletta, Moorpark and Irvine.

Regards,
Rob Roeterdink

[roeter]

Lindsayts, on 25 May 2014 - 11:05 PM, said:

Now this is a VERY interesting development and congratulations all round one may say, Now............

As I believe for PA1930, I find the two documents, the concept and the example difficult to rationalise. This is due to the great complexity of the example. It being quite difficult to track down how everything works.
It would be nice to have a simple example with only a handfull of trains doing as much in the timetabling as the simplcity of the example allowed.
This would make the example easier to study both in the spread sheet and the csv file, with the reference document.

You can start of by just looking at one train. Delete the rest of the timetable if you want to. It would still work - you might get some warnings because of references to none-existing trains, but those can be ignored.
You can build up the timetable by adding the trains referenced in these warnings, and so gradually extend back to the full timetable.

Quote

It is likely one is never meant to directly work on the csv file, overall though its always nice to be able to do it that way.

You need to be very brave to do so for a timetable like that for the Surfliner route.
I would not go down that path - it adds nothing to the concept.
Personally, I have made a small batch-script which renames the *.csv files and moves them to the Activities/OpenRails directory (the spreadsheet is located somewhere else). So I actually do not even see the *.csv or the *.timetable_or files.
Compare them to compressed shape files - do you ever bother to look into these using a Hex editor?

Quote

A question, the example has 3 pages/sheets Libreoffice only saved the first page/sheet to a csv file. Mind you this has 511 columns the longest row being at least over 6000 characters in length.

When creating a new Excel file, it always contains three worksheets - that is Excel's default. But only the first is actually used. I suppose I should have removed the other two, but I've got so used to this I never give this a second look.

Regards,
Rob Roeterdink

[James Ross]

roeter, on 25 May 2014 - 04:37 PM, said:

• Rename or copy the *.csv file to *.timetable_or (e.g. : ttfile.csv to ttfile.timetable_or).

So close, we should be using "timetable-or" as the file extension. :oldstry:

[JohnnyS]

roeter, on 26 May 2014 - 12:32 AM, said:

Sounds odd.

It's not beyond the realms of possibility that I've got something wrong, either in design or observation. :oldstry: As I said my tests were fairly quick and crude.

Do you own a copy of the SWB route? if so I can attach the timetable and paths for your perusal.

Regards,
John.