[steamer_ctn]

I am wondering whether it would be possible to adjust the code for AI passenger trains to set the arrival and departure times at stations that they are tabled to stop at?

It could be done in the relevant AI srv file as follows:

A normal srv file which has the AI set to stop at stations looks like this:

StationStop (
PlatformStartID ( 276 )
DistanceDownPath ( 4452.3 )
SkipCount ( 1 )
)

Ideally it would be possible to include the start and departure times in the relevant srv file as follows:

StationStop (
PlatformStartID ( 276 )
DistanceDownPath ( 4452.3 )
SkipCount ( 1 )
ArrivalTime ( 31290 )
DepartTime ( 31320 )
)

Only stations selected for stopping appear in the srv file.

These files would need to be hand edited until an OR AE is built, but I for one would be happy to accept this overhead.

It appears that MSTS will ignore modified srv files, thus the service will not appear in the activities run in MSTS. Hence these activities would only be suitable for running in OR, but again I would personally be happy to accept this impact for the sake of having better functionality in OR.

What do others think?

Is it possible for the signalling code to be easily changed to accommodate this?

Thanks

[Csantucci]

Differently from MSTS, OR already manages arrival and departure time for AI trains, taking them from the traffic ( .trf ) file or from the activity file (they can be found in both files). MSTS AE already puts these values within such files, but the problem with MSTS is that it does not consider them at runtime (while ORTS does). If you look at a traffic file you will see data like following ones:
Service_Definition ( 1664 58860
ArrivalTime ( 59040 )
DepartTime ( 59220 )
SkipCount ( 0 )
DistanceDownPath ( 108.614 )
PlatformStartID ( 1269 )
ArrivalTime ( 59400 )
DepartTime ( 59400 )
SkipCount ( 1 )
DistanceDownPath ( 1767.36 )
PlatformStartID ( 1378 )
ArrivalTime ( 59940 )
DepartTime ( 59940 )
SkipCount ( 2 )
DistanceDownPath ( 6012.28 )
PlatformStartID ( 1380 )

It is not correct to put arrival and departure time in .srv files, as you can have multiple instances of a service, each starting at a different time, within a traffic file.

So no need to modify file structures.

To be more precise OR manages departure time. That is, AI train could arrive also before arrival time, but it will depart at departure time or after the passenger loading/unloading interval expires, selecting the latest between the two.

[steamer_ctn]

Thanks for the reply.

I didn't realize that the trf file already had them in it.

I will play with these figures.

Thanks for the feedback.

[Buttercup]

You can edit the arrival and departure times for ai passenger services in the MSTS AE and with: http://msts.juliane-und-torben.de/.

[disc]

These arrival and departure times counted from the start of the activity or the start of the service, or it's an exact time point?
I think the best would be(for future) to count it from start time of the service, then it can be useable for all similar services, just with different start times.

[steamer_ctn]

Setting the arrival and departure times for the AI Passenger service certainly improved the "on time" running statistics.

Would it be possible to do a similar thing with a siding marker? This would enable Goods trains to be timetabled where there is no platform marker in situ.

For example:

Service_Definition ( w78_ai-w9 27000
ArrivalTime ( 27600 )
DepartTime ( 27660 )
SkipCount ( 0 )
DistanceDownPath ( 4452.3 )
SidingStartID ( 52 )
)

This could be hand coded in the traffic file. The TrItemId could be identified by the user and then referenced into the trf file. It appears that the marker is the "end" one when viewed in the direction of train travel.

The skip count appears to be easy to calculate. I am not certain about the DistanceDownPath parameter. Is this critical to OR? Could it be omitted?

Is this a possibility as it would then enable complete timetabling, provided a relevant siding marker is in place.

Thanks

[roeter]

steamer_ctn, on 15 April 2013 - 03:38 AM, said:

Setting the arrival and departure times for the AI Passenger service certainly improved the "on time" running statistics.

Would it be possible to do a similar thing with a siding marker? This would enable Goods trains to be timetabled where there is no platform marker in situ.

For example:

Service_Definition ( w78_ai-w9 27000
ArrivalTime ( 27600 )
DepartTime ( 27660 )
SkipCount ( 0 )
DistanceDownPath ( 4452.3 )
SidingStartID ( 52 )
)

This could be hand coded in the traffic file. The TrItemId could be identified by the user and then referenced into the trf file. It appears that the marker is the "end" one when viewed in the direction of train travel.

The skip count appears to be easy to calculate. I am not certain about the DistanceDownPath parameter. Is this critical to OR? Could it be omitted?

Is this a possibility as it would then enable complete timetabling, provided a relevant siding marker is in place.

Thanks

If you can change the MSTS Activity Editor so this data can be set :thumbup3:
That's where the limitation is - there is no definition.
By the way, OR does neither use the SkipCount nor the DistanceDownPath. I am not entirely sure (would have to check the code for this), but likely you must also set the siding ID in the Service definition :

SIMISA@@@@@@@@@@JINX0v0t______

Service_Definition (
	Serial ( 1 )
	Name ( AI_Howl_Hamd )
	Train_Config ( ADP_LAR_DMU170_2x2 )
	PathID ( Howl_Hamd )
	MaxWheelAcceleration ( 0 )
	Efficiency ( 0.75 )
	TimeTable (
		StartingSpeed ( 0 )
		EndingSpeed ( 0 )
		StartInWorld ( 0 )
		EndInWorld ( 0 )
		StationStop (
			PlatformStartID ( 5539 )
			DistanceDownPath ( 147.021 )
			SkipCount ( 0 )
		)
		StationStop (
			PlatformStartID ( 5596 )
			DistanceDownPath ( 43594.4 )
			SkipCount ( 2 )
		)
	)
)

So, to include siding stops you would have to :

• Identify the required siding ident in the tdb file
  
• Edit the related train service path to set the stops
  
• Edit the related traffic file to set the siding and the required times

All these changes must be made by hand, and, ofcourse, without any typing errors or the program will likely crash.
Not a very user friendly way to introduce this.

BUT : if you are in a mood to try all this, there is a little surprise waiting : siding stops are allready implemented.
All you need to do is set the data as detailed above!

Regards,

Rob Roeterdink

[steamer_ctn]

Hi Rob,

Thanks for the reply, this is exciting news.

I have started to try and get it to work, but at the moment I am getting the following message in the OR log file:

Warning: Train 2 : platform 53 is not on route


As you have suggested, I have probably made a typing mistake, etc, so I would like to check my understanding of the process. So I have prepared the attached document to confirm my understanding of the process, and also later to act as a memory jogger and reference document. Could you review it and identify any places where I may be making a mistake. I have assumed that the parameters are all the same, ie PlatformStartID, etc and not SidingStartID, etc. Is this correct?

Can you also provide some feedback on the following:

i) Will this work on a path that has been set up as a passing path (ie inside the passing path)? What happens if the siding marker is on the loop, but the AI attempts to stay on the Main Line?

ii) If for some reason that the siding marker extends past the departure signal, will this cause any problems?

Are there any other issues that one needs to be careful of in using this feature?

Thanks

Attached File(s)

•  Setting Timetables for AI Trains.pdf (283.83K)
  Number of downloads: 264

[roeter]

steamer_ctn, on 16 April 2013 - 04:17 AM, said:

Hi Rob,

Thanks for the reply, this is exciting news.

I have started to try and get it to work, but at the moment I am getting the following message in the OR log file:

Warning: Train 2 : platform 53 is not on route


As you have suggested, I have probably made a typing mistake, etc, so I would like to check my understanding of the process. So I have prepared the attached document to confirm my understanding of the process, and also later to act as a memory jogger and reference document. Could you review it and identify any places where I may be making a mistake. I have assumed that the parameters are all the same, ie PlatformStartID, etc and not SidingStartID, etc. Is this correct?

Can you also provide some feedback on the following:

i) Will this work on a path that has been set up as a passing path (ie inside the passing path)? What happens if the siding marker is on the loop, but the AI attempts to stay on the Main Line?

It will (alas) not work with passing paths, stations (or sidings) must always be in the main path.
The reason for this is that stops are defined in service/traffic files, away from the path definition. Stations stops are checked before the train is run, and can therefor only be checked against the main path.

Quote

ii) If for some reason that the siding marker extends past the departure signal, will this cause any problems?

Yes, in the sense that the signal will now not be seen as exit signal for the siding, and will therefor clear immediately as the train is routed into the loop - which rather cheats the whole idea.

Quote

Are there any other issues that one needs to be careful of in using this feature?

Admittedly, this feature was only tested very briefly (as it was not likely to be used yet anyway), so there still may be some program issues.
One point you may notice is that trains are stopped halfway along platforms (middle of train located at middle of platform), and so will likely also be stopped halfway sidings. If the train is longer that the siding (the area marked by the markers, not the length between end signal and entry point), it may be that the signal will be cleared to allow the train to position itself again with the middle of the train at the middle of the platform.

By the way, which route are you using to test this?

Quote

Thanks

My pleasure - you're not the only one who likes to run his trains using proper timetables!
I'll have a look at your document later.

Regards,

Rob Roeterdink

[steamer_ctn]

Hi Rob,

Thanks for the feedback.

I have done some more experimentation and found the following:

Quote

Warning: Train 2 : platform 53 is not on route

Station (or siding) stopping information needs to be inserted into the both the act and srv files. I had only done the srv file. {On closer inspection whilst it appears that MSTS requires stops in both srv and act files OR will work with only the srv code in place - Is this correct?}

Timing data needs to go into the trf file.

Quote

It will (alas) not work with passing paths, stations (or sidings) must always be in the main path.

I think that this means if the AI train has to leave the default path to pass another train. Is this correct?

I did some experiments with passing paths and it appears that both station (and siding) markers work sometimes if the train doesn't leave the default path. Though I found an interesting anomaly.

At the location shown in the attached file, the AI train was tabled to stop at the station markers. It stopped, but would not restart, even though the departure signal appeared to be green. Any thoughts on why this might have happened? Can this be fixed?

Quote

The reason for this is that stops are defined in service/traffic files, away from the path definition. Stations stops are checked before the train is run, and can therefor only be checked against the main path.

In this instance is it possible to use the fact that the train has stopped at a signal off the default path awaiting for a passing train, so its location is known and therefore it should be kept at this signal until the departure time?

I will continue to do some more experimentation.

On another note:

Is it possible to add code to allow the train to start the activity in motion at a certain speed?

Thanks

Peter

Attached thumbnail(s)

•