[disc]

 roeter, on 25 November 2013 - 05:16 PM, said:

Because the analyses is performed for the full path when the train is started, this process is not performed for 'free roam' trains (explorer mode or manual mode), as the process would have to be repeated each time the path is changed, either by reversing or by setting a manual switch.

Why is that so bad? The analysis probably not so slow. And reversing and manual switch settings aren't happen so frequently.
And what happens on yards, which in reality are usuall out of automatic switching, and automatic signaling territory, and manual switching and reversing happens frequently?

[railguy]

Here is how I would set up the "Dispatch" (AI Dispatcher) system. The way most railroads establish train superiority is by right, class, and direction. Even in CTC systems, the Dispatcher will try to adhere to that hierarchy. In OR, it could work like this:

I would establish train superiority using a point system--the train with more points being superior to one with less. The default points assigned by the Activity Editor would be as follows, but could be altered by the activity developer. Let's start with direction. Superiority of train by direction is usually established by Rule or by Employee Timetable. In my "ABC Railroad" Employee Timetable, timetable westbound trains are superior to timetable eastbound trains of the same class. (In this lexicon, there are no northbound or southbound trains, they are either eastbound or westbound no matter their compass direction.) So, an eastbound train would get 0 points for direction superiority and westbound trains would get 10 points. Next would be class. There could be numerous classes of trains, but, for my example, there would be four--Passenger train, fast freight, slow freight, and local freight. The lowest class, the local, would get 0 points, the slow freight 100 points, the fast freight 200 points, and the passenger train 300 points. Finally, there would be right superiority--for example, a train with rights over all other trains would be given 1,000 points. At each passing point, the AI would evaluate the points of the AI trains and the player train and give superiority to the train with the most points at that moment.

So, for an example, let's say the player train is a westbound slow freight. It would get 110 points. There are 4 AI trains, an eastbound passenger train (300 points), a westbound local freight (10 points), an eastbound fast freight (200 points), and a westbound officer's special with rights over all trains (1,010 points). So, during the activity, the slow freight player train would have to clear for the EB fast freight and the eastbound passenger train, and the westbound local freight would have to clear for the player train if the system determined that the player train would overtake it based on average speed of both. Similarly, the player train would have to clear for the officer's special when the special would overtake it. Since the system would be dynamic, with the AI evaluating the points and average speed of trains at each passing point, meets could be scheduled according to the progress of the various trains. For example, two westbound freights with equal priority could proceed across the line in sequence, but, if the first train was moving at a slower average rate than the second, the second train could overtake the first at a passing point.

As for manual switching, taking the switches to manual operation would place the player train at 0 points until the automatic switches were restored, meaning that the player train would have to stay out of the way of all other movements until it finished its switching and the switches set back to automatic.

Changing priorities during an activity could be done through what basically would be equivalent to a train order or track warrant system. For example an eastbound train could be given superiority over other traffic to a certain passing point, where its points could be changed to a lower number, or even dropped to zero until a triggered event occurred--for example the arrival of an opposing AI train. This would be equivalent to a "not effective until the arrival of" train order or track warrant.

The entire system could be based on a mathematical hierarchy, combined, when necessary, with some "if/then/else" statements that could be invoked at certain points. I don't think that it would be that complex to program, but I freely admit to not being an expert in that area.

[Lindsayts]

 railguy, on 26 November 2013 - 11:19 AM, said:

Here is how I would set up the "Dispatch" (AI Dispatcher) system. The way most railroads establish train superiority is by right, class, and direction. Even in CTC systems, the Dispatcher will try to adhere to that hierarchy. In OR, it could work like this:

I would establish train superiority using a point system--the train with more points being superior to one with less. The default points assigned by the Activity Editor would be as follows, but could be altered by the activity developer. Let's start with direction. Superiority of train by direction is usually established by Rule or by Employee Timetable. In my "ABC Railroad" Employee Timetable, timetable westbound trains are superior to timetable eastbound trains of the same class. (In this lexicon, there are no northbound or southbound trains, they are either eastbound or westbound no matter their compass direction.) So, an eastbound train would get 0 points for direction superiority and westbound trains would get 10 points. Next would be class. There could be numerous classes of trains, but, for my example, there would be four--Passenger train, fast freight, slow freight, and local freight. The lowest class, the local, would get 0 points, the slow freight 100 points, the fast freight 200 points, and the passenger train 300 points. Finally, there would be right superiority--for example, a train with rights over all other trains would be given 1,000 points. At each passing point, the AI would evaluate the points of the AI trains and the player train and give superiority to the train with the most points at that moment.

So, for an example, let's say the player train is a westbound slow freight. It would get 110 points. There are 4 AI trains, an eastbound passenger train (300 points), a westbound local freight (10 points), an eastbound fast freight (200 points), and a westbound officer's special with rights over all trains (1,010 points). So, during the activity, the slow freight player train would have to clear for the EB fast freight and the eastbound passenger train, and the westbound local freight would have to clear for the player train if the system determined that the player train would overtake it based on average speed of both. Similarly, the player train would have to clear for the officer's special when the special would overtake it. Since the system would be dynamic, with the AI evaluating the points and average speed of trains at each passing point, meets could be scheduled according to the progress of the various trains. For example, two westbound freights with equal priority could proceed across the line in sequence, but, if the first train was moving at a slower average rate than the second, the second train could overtake the first at a passing point.

As for manual switching, taking the switches to manual operation would place the player train at 0 points until the automatic switches were restored, meaning that the player train would have to stay out of the way of all other movements until it finished its switching and the switches set back to automatic.

Changing priorities during an activity could be done through what basically would be equivalent to a train order or track warrant system. For example an eastbound train could be given superiority over other traffic to a certain passing point, where its points could be changed to a lower number, or even dropped to zero until a triggered event occurred--for example the arrival of an opposing AI train. This would be equivalent to a "not effective until the arrival of" train order or track warrant.

The entire system could be based on a mathematical hierarchy, combined, when necessary, with some "if/then/else" statements that could be invoked at certain points. I don't think that it would be that complex to program, but I freely admit to not being an expert in that area.

I may say I would love to see something like this in OR.

On the iron ore lines in Northern Western Australia the loaded trains to the coast are given priority as it takes between 20 to 30 minutes to get up to speed. A stop at a single signal can delay your arrival at the unloader by an hour, its a real pain!

Lindsay

[mauried]

Open Rails , unlike all the other Rails Simulators, is an OPEN SOURCE simulator.
Which means that anyone can add features to the Sim that they would like to see in it .
If you want some feature added to the sim , then you are free to add it.
Its very easy to keep saying I would like to see something added, and then expect the work to be done by someone else.

[roeter]

The present system is based on the actual train positions, and a train is taken into a loop to wait if deadlock would otherwise occur immediately.
A system based on proirities is much, much more complicated.
A high priority train may not be stopped by a low priority train. This means you have to predict if the low priority train can make it in time to the next passing loop, even though the high priority train may still be a number of passing loops further down the line.
Without a timetable, this gets really difficult. The least which is required is estimated allowances between passing loops for each train. To base this prediction on line speed in very unreliable, in particular for routes with gradients - it might well be that the low priority train is a very heavy one, so it could well be that it's speed up the hill is far below the allowed line speed. If the train is still on the 'flat' part of such a route, it's present speed is of no use for this prediction.
It is envisaged that priorities can be defined in OR's Activity Editor, and perhaps allowances could be included somewhere as well. But it will definitely take quite a bit longer before such a priority system is fully implemented.

And it is ofcourse the last line in Railguy's post which is the real killer here .... ^_^

Regards,
Rob Roeterdink

[railguy]

I know all about how potentially complex train dispatching can get, even with a CAD--computer-aided-dispatch--system. I made the suggestion based on some of my experience. I've worked as a real world train dispatcher. I certainly did not want to offend anyone.

[roeter]

 railguy, on 26 November 2013 - 02:15 PM, said:

I know all about how potentially complex train dispatching can get, even with a CAD--computer-aided-dispatch--system. I made the suggestion based on some of my experience. I've worked as a real world train dispatcher. I certainly did not want to offend anyone.

Rest assured - you didn't.
I know all too well how it feels having a sim which just doesn't do what you want - and just hope that someone, sometime will pick up those ideas! Why do you think I joined OR :pleasantry: .

Keep the ideas coming - all helps to form the complete picture of what is to happen. But please be patient - there is still an awfull lot of work to do.
As I said in another post : it's all on the list - but that list grows by the day.

Regards,
Rob Roeterdink

[railguy]

 roeter, on 26 November 2013 - 04:12 PM, said:

Rest assured - you didn't.
I know all too well how it feels having a sim which just doesn't do what you want - and just hope that someone, sometime will pick up those ideas! Why do you think I joined OR :pleasantry: .

Keep the ideas coming - all helps to form the complete picture of what is to happen. But please be patient - there is still an awfull lot of work to do.
As I said in another post : it's all on the list - but that list grows by the day.

Regards,
Rob Roeterdink

Please be assured that I completely appreciate the hard work you and all of the OR team have done. Without it, I firmly believe that the MSTS sim will quietly die a slow death with no replacement on the horizon to run all the routes, models, and activities that were designed for it. OR already runs circles around MSTS in many important areas--most noticeably things like train physics and overall realism. In a "past life" I worked in a job where part of my duties were to interface with programmers--explaining to the programmers what the program needed to do for the end users, so that the programmers would understand what their programming needed to do and write the code accordingly. It could be a frustrating, head-butting experience at times, but the end product was well worth the efforts. I see this much the same way.

[cjakeman]

 railguy, on 26 November 2013 - 02:15 PM, said:

I've worked as a real world train dispatcher.

That's great. Your insider knowledge could prove very useful as our plans develop.

[roeter]

 disc, on 26 November 2013 - 03:49 AM, said:

Why is that so bad? The analysis probably not so slow. And reversing and manual switch settings aren't happen so frequently.
And what happens on yards, which in reality are usuall out of automatic switching, and automatic signaling territory, and manual switching and reversing happens frequently?

It's not the processing capacity that is the problem here, but the stability of the deadlock processing which would be affected. Also, changing direction or switches can easily lead to situations where deadlocks are unavoidable.
Improvements to the dispatcher window, and use of this window to safeguard agains deadlocks in manual mode, could well be a much better option.

Regards,
Rob Roeterdink