[Metro4001]

OR runs AI a bit differently than vanilla MSTS so I've had to tweak some timings on my AI trains which is okay. I'm having one minor issue though; it seems that no matter how low I set the expected performance number the AI runs at track speed anyway. I'm trying to decipher the dispatch window codes but I can't make hide nor hair of it. I saw one of my AIs cruising much below track speed and it's AUTHORITY was REST, whatever that means. Some eastbound AIs I had set up were bunched up at signals, I believe their AUTHORITY was TRAH. I'm all turned around. Any assistance would be greatly appreciated.

[roeter]

Performance value is indeed, as yet, not used in OR.
REST means Restricted - it means the train is approaching a Restricted signal aspect.
TRAH means Train Ahead - that is multiple trains in a single section, generally this occurs where 'permissive' signals are used which allows trains to pass signals at danger and to follow another train into the same section.

Other reasons why AI trains will behave different :

• OR uses different physics than MSTS, resulting in different speed, acceleration and braking profiles;
  
• When passing speedposts or signals which raise the speedlimit, in OR the higher limit is only applied when the rear of train passes the speedpost, MSTS applies the higher speed immediately when the front passes that location;
  
• In OR, when speedpost sets a higher speed limit than a limit set by a signal the speedpost limit will be used, in MSTS a limit set by a signal always applies upto the next signal;
  
• For passenger AI trains with booked station stops, OR will use the departure time as set in the traffic details, MSTS always ignores that;
  
• For permissive working, OR will ensure trains will properly stay clear of eachother, MSTS could not handle that situation.

Regards,

Rob Roeterdink

[markus_GE]

As it´s now been mentioned as everything else than a bug....

Why does OR raise the Speed Limit to anything implied by speedpost, also if the signal speedlimit is lower than that?
As of some official (but yet a bit old) signal rule Charts (are These too called timetables?) I read, this seems to me not quite like common practice.
And also, it seems a bit illogical: The Signal speedlimits are set up to have the Train slowed down before it encounters a Stop (or similar) aspect, so that it can safely come to a halt with out use of ermgency braking or passing the Signal when not allowed to - that´s why it makes sense, that speedlimits higher than the signal limit are in reality ignored.
I know, I can run to the real rules to with my player train, but what for AI trains? Wouldn´t the above-mentioned imply, that they will run faster than save, so that they might likely not be able to stop at an indication dictating to do so?

That would explain a few Problems I recently had when Timing an activity AI setup.

Yours,

Markus

[roeter]

The problem is there are two types of speedlimits which are set by signals :

• Speedlimit imposed because of restricted aspect for next signal
  
• Speedlimit imposed because of routing of train through speed-restricted section, i.e. cross-over or junction.

The MSTS signal rules, which ofcourse still have to be used for OR, can not distinguish between these two different rulings. Also, it is not possible to lift this imposed limit if the aspect of the next signal clears.
You are correct that for the first type of limit, the speed as imposed by the signal should be maintained. But that would be wrong for the second type of limit. One rather frustrating problem in MSTS is that, after passing through a restricted junction, you have to keep crawling at that low speed for miles on end upto the next signal while if you had gained access to that track in another way you could be running at full line speed. The original USA1 route has many examples of such inconsistent speed limits. Some routes use 'dummy' signals to clear these limits.

So, a choice had to be made. The problems with the second type of limit seriously affect the actual running of the trains (in particular if you want to run to real timetables), so that was given prevalance. For the first type of limit, it is still the responsibility of the driver to keep his speed in accordance with the expected next signal aspect, whatever the actual limit.

As for AI trains, these will regulate their speed based on the next expected most restricting 'object' which requires speed reduction (signal, speed limit, station stop etc.). A 'speed profile' is calculated such that the train will have reduced it's speed at the location of the next 'object' as required. The present speed limit is taken into account in this calculation, but that does not mean the train will automatically raise it's speed - it will only do so if that is possible within the required speed profile. This calculation is not just based on the next object but takes all objects ahead into account and determines which is the first most restricting object - so, for instance, a speed restriction reducing speed from 80 to 40 kmh, which is located just 100m. in front of a signal at STOP, is ignored - the required speed profile for the STOP aspect would be well below 40 kmh at that position. But if the signal clears, the train will adjust it's speed profile to that speed limit as that has now become the most restricted object.

Regards,

Rob Roeterdink

[Csantucci]

I'm happy to see that people are beginning adapting or writing activities for ORTS. It's a good sign that the simulator is on the good path too!
Referring to service performance, I'm also one of those who would like to have it implemented, and I hope that this will happen.

Regarding to this

roeter, on 25 May 2013 - 02:42 AM, said:

... One rather frustrating problem in MSTS is that, after passing through a restricted junction, you have to keep crawling at that low speed for miles on end upto the next signal while if you had gained access to that track in another way you could be running at full line speed. The original USA1 route has many examples of such inconsistent speed limits. Some routes use 'dummy' signals to clear these limits. ...

Rob Roeterdink

I think that ORTS cannot solve problems created by badly designed routes. As Rob says, there is a solution, and it is to use "dummy" (here we say "virtual", maybe the right word could be "hidden") signals, as implemented within many routes.
So I think it would be more correct that also for the player train the maximum allowed speed is the lowest of the two (speedpost and signal).

[markus_GE]

This seems all plausible and well-thought to me, but since it has been possible to introduce superelevation (an all non-MSTS feature), I don´t think it´s impossible to implement these speedlimit thingies.

SE now somehow manages to determine if track belongs to a Switch or not, and from that knowledge decides if the concerned Piece of track will or won´t be se´d (AFAIK). Using the same method the speedlimits through switches could be set, manitained and after the train has passed the switch, raised to whatever the Speed was before passing the last signal - i.e. by automatically implementing the ghost / dummy / virtual (or whatsoever) signals you, Rob and Carlo, mentioned. And (from my Little knowledge of programming) I think, by adding a variable that indicates the type of speelimit, the "identification" Problem could also be eliminated (i.e. implementing the three kinds of speedlimits as seperate variables, such as speedlimit_post, speedlimit_signal, speedlimit_switch, comparing them and setting the lowest as the actual one)

If I go furhter ahead with my thought´s, the limit´s this way could be implemented for e.g. an aspect like "Diverging Approach" (next switch to diverging path, next Signal at stop, so a.) a Speed through the turnout and b.) a Speed to keep to because of approching a STOP is needed) in the following manner:

1.) The Signal will set the speed restricting the trains advance throughout because of it´s indication (Divergin Approach) or the indication of the next Signal (STOP). If this is lower than the speedpost Limit (active up to the signal), it will become "active", if it is higher, the post limit stays active.

2.) The Signal will set the turnout limitt restricting the train through the switch(es; for multiple Switches in a row, the ghost / virtual / dummy signal for sure can somehow be set behind the "ladder"). Again, if that one´s lower than all other Limits, it will become active, else, the lower one of the two other Limits will become / stay active.

3.) If a speedpost is encountered, the whole comparation starts again: new post Limit set -> checking whcih one of the three is the lowest -> this one gets active.

4.) After the train has passed the switch(es), the Switch Limit will ...
a.) be deactivitaed some way
b.) be set to a very high, thus unrealistic-to-ever-be-reached value, like 1000 mph / km/h so that it always is higher than the other limits. It will only be lowered again, if the train encounters a divergin indication again.

I think, that way all needs of a realistic signalling system could be met.

Cheers, Markus

PS: I´ve never been programming in C# nor have I ever lokked at the code of OR - the above is just a suggestion from somebody who is happy to have taught himself the basics of BASIC programming language and still struggles how to write buttons ;). I would be happy if the above helps in any way, and also maybe would like to know, what "real" programmers think about it.

[roeter]

The problem is not the detection of where the train is etc. - the problem is the enormous variety in signal definitions, aspect use and meaning etc. over all countries and routes.
With the limitation of 8 aspects per signal, many signals use the possible aspects simply because all 8 are required and the use therefor no longer has any 'link' to the aspect name. So logic based on the aspect shown is not possible - the name of that aspect has no relevance to it's use.

The problem can and will be properly handled once we can leave MSTS signal scripting behind and introduce OR signal definitions - or at least OR extentions.

Then, it will be possible to distinguish between the two types of speed limits.
Furthermore, it will be possible to define 'speedsignals' - these are objects which are defined as a signal but work as a speedlimit. The advantage of this is that it will apply only to the track on which it is placed, and it can be route-linked. So, it is possible to define a speedlimit which applies only through a cross-over, for instance. As it is a speedlimit, it would be automatically overruled by the next (higher) speedlimit. For this cross-over, there would be no need to define a speedlimit related to a signal aspect.
Most of the logic for all this is allready implemented - it is the lack of possibility to set the definition which is the main obstacle to introduce it.
So, please be patient - these items will be dealt with, sooner or later. It just needs time.

Regards,

Rob Roeterdink

[markus_GE]

Well, it was just an idea, and as I already stated, I can put with it as it´s now. Was a.) just worried about and b.) looking (and still am) for an Explanation for AIs overriding STOP signals.

[markus_GE]

Well, it was just an idea, and as I already mentioned above, I can put with it as it´s right now - I was just concerned about AIs riding over STOP indications, as I encountered it with an activity I´m playing around with at the time.

Cheers, Markus

[roeter]

I'm rather interested in this AI train skipping STOP signal. If an AI train runs through stop it is immediately removed. Does this indeed happen?
Can you make a screenshot of the Dispatcher info (3x SHIFT-F5) just before it happens?

Thanks,

Rob Roeterdink