[roeter]

steamer_ctn, on 17 April 2013 - 02:50 AM, said:

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.

Correct - the info is duplicated in these files, but processing it once is enough. The info from the service definition is used. Timing data is indeed taken from the traffic 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.

If you have a station defined in the default path and the train is routed over the alternative path, you have a real problem. Ths train cannot now locate the station, and therefore cannot decide if it is still to come or allready passed. As a result, the station will not be removed from the list and will remain the 'next station' - so the train will not only miss this station but all following stations as well.

Quote

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?

I can't tell why the train does not move. Did you check the dispatcher control information (3x shift-F5)? That gives details of the signalling and station stop process. As I don't know why the train does not continue, I do not know if it can be fixed.

Quote

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?

No, that is just too complicated.
It was also be a bit of wasted effort as there is the intention to change the alternative path definition, as soon as we have time and can find a way to define additional activity definitions.

Quote

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

No, it's not on the list yet either.

Regards,

Rob Roeterdink

[steamer_ctn]

Hi Rob,

Thanks for the feedback.

roeter, on 17 April 2013 - 04:49 PM, said:

No, that is just too complicated.

That is a bit disappointing, as I had hoped that it might be be easily possible, as the AI approaches the passing path and sets the alternate path, to ignore any stopping points defined within the passing path, and use the timetabled information associated with them instead to control the departure signal at the end of the passing path to hold the train on the alternate path until scheduled.

This would have been a great advantage, as the work that you have done in creating the siding marker scheduling for AI timetabling has the potential to vastly improve the accuracy of activities, thus removing the major challenges of getting AI trains to run on time at the moment.

Quote

It was also be a bit of wasted effort as there is the intention to change the alternative path definition, as soon as we have time and can find a way to define additional activity definitions.

Thanks, this will be something to really look forward to and make activity creation a lot easier.

Quote

I can't tell why the train does not move. Did you check the dispatcher control information (3x shift-F5)? That gives details of the signalling and station stop process. As I don't know why the train does not continue, I do not know if it can be fixed.

In regard to this issue, I have attached a couple of screen shots with the dispatch control information for review.

This first one shows the train waiting at the loop for the tabled departure time of 0813.



This next one shows the train after the tabled departure time of 0813. It is still waiting in the same loop, and appears that the AI Data has now picked up the departure time (0832) for the stopping point at the next passing loop.



Does this explain what is happening?

Again, thanks for your efforts.

[roeter]

Quote

Does this explain what is happening?

It does explain why the train doesn't move (well, until 08:32, anyway).
This problem seems to be more due to errors in the path or siding processing than a run-time problem. The dispatcher info tells me that the train did actually 'run' to the next station (allthough it did not need to move to actually do this) - the distance w.r.t. the station marker changed from -4 yard to -1 yard. So the program placed the second station just 3 yards beyond the first.
Why that happened will need extensive eximination of all related input and processed path and station data.
I will get back to you on that.

Thanks,

Rob Roeterdink

[roeter]

The problem with the station 'shift' was caused by the fact that the station was 'bypassed' as the deadlock processing forced the use of an alternative path through the next loop. I've made a temporary alteration for AI trains which now ignore the next station if this happens (version X1580).
A more extensive change in the handling of station stops when passing paths are activated is put on the list for later but it may be some time before I get round to that.

Regards,

Rob Roeterdink

[steamer_ctn]

Hi Rob,

Thanks for that.

It now works as you suggest.

Cheers