AI Train created at incorrect time - collides with player

[Sid Penstone]

OR Version: X1847 (also Version 0.9)
Route: Mactier
Activity: Generated by Skyline Activity Generator; simple pickup and setout.
Symptom: AI train is created at the wrong clock time, meets player train head on. Also- some ambiguity between Auto and Manual in signals presented.

The activity starts at 09:30 AM with the player train on a section of double track, between the two "Bolton" switches. It must move south to the single track main line through the Bolton South switch to reach the Gerdau Ameristeel Metals siding to pick up some cars. An AI train is started by the activity at 9:29:50 AM or 31190 in the traffic file (Note - before the player start time). It is moving north from the Elder North switch towards the player train's location on the single track portion of the main line.

In MSTS, the activity starts with a red signal facing the player at the Bolton South switch; the player train must wait until the AI train has passed by on the adjacent track before proceeding on to the main line. (Clicking TAB produces "Permission Denied".) The AI train appears as expected, and the activity proceeds normally.

In ORTS, in Auto Signal Mode, a green signal is shown at startup. The HUD shows that the AI train has not yet been created, although the simulation time has already started at 09:30 AM. If the player train is driven on to the main line, it encounters green signals. But at approximately 09:36 AM the AI train is suddenly created on the single track main line and the player train encounters it head on in a collision. (In Release 0.9, the AI train appears at about 09:37:50 AM)

In ORTS, in Manual Mode, a red signal is shown at startup (09:30 AM), even though the AI train has not yet been created. The HUD shows that the AI train is created at approximately 09:30:20 AM in Auto mode. Switching back to Auto Signal before the AI train is created shows green, but afterwards continues to show red signals as expected. (Incidentally, switching back and forth between Manual and Auto during the first minute delays the actual time at which the AI train is created.)

[r.roeterdink (r-roeterdink)]

Hello,
can you please also provide the related service and path files?
Cannot test this without those files.
Thanks.

[Sid Penstone (penstone)]

I am attaching the activity files as packaged by the MSTS Activity Editor. Hope that helps.
BTW, I have created an activity for the default Marias Pass route that shows some similar symptoms, but using the default trains from that route. Would that be useful as well? The MacTier route uses a lot of special cars and locos.

Cheers,
Sid

[r.roeterdink (r-roeterdink)]

Thanks - but there is no need for other tests - consists are not important here.

Here is what happens, in bits and pieces.

Train start.
That the train does not start before the activity is just a little unfortunate.
Before the activity starts, AI trains are updated at a low frequency interval timing - only once every 5 secs. This is a normal 'full' update, ensuring that all signal and speed rules etc. are maintained (something MSTS does not do), the low frequency is used to avoid excesive processing time.
The last update for this pre-update is not performed anymore, to avoid mix-up between pre-processing and actual processing.
The start of this pre-update is taken from the start of the first AI train.
In this case, the start is at 09:29:50. The check for starting the train is starttime < time, so at this update the train does not start yet. The next update would be at 09:29:55, but this is not performed as precaution.
As a result, the AI train start is delayed by 10 secs. - normally no problem, but in such 'fabricated' activities as this it works out a bit different.

Train placed in player train path.
As the AI train is not started before the player train, the player train will now clear it's route. The AI train tests it's placement location to check if this available, but with the player train now cleared over this section, the AI train start is further delayed.
In this process there is a little error - position only is checked, there is no check if the train is moving towards the AI train.
This will be corrected as soon as possible, but due to other work I cannot do it right now.

Manual mode.
In manual mode, signals will always be reset to danger. Furthermore, the deadlock protection processing is switched off when in manual mode. As the activity starts in normal mode, the AI train can not be placed and is kept 'in store'. The check for the AI train is repeated every 30 secs., so if you switch to Manual and clear the signal within 30 secs. there is nothing to stop the signal from clearing as the AI train is not there yet. If the AI train is so far out that it will not yet clear it's route over the first section the signal can always be cleared anyway.
As in Manual mode, the route is cleared only to the next signal, and the AI is further out, then the AI will be created despite the fact that the signal has cleared for the player train. Normally the deadlock protection prevents this, but this is switched off for manual mode.
In all, manual mode works correct - it should not be used on single track routes with AI traffic.

Finally - there is a very easy way to make it all work as you want.
Just start the AI train at least 11 secs. before activity starts - and all goes well.
As mentioned above, the update rate of 5 secs. means that a 10 sec. start will not work. That is something that is not going to be changed.

[Sid Penstone (penstone)]

Many thanks for the quick solution and explanation. In playing with my "copy" for the other route, I had noticed that initially the AI problem did not occur; it was only when I copied the start times into this 10 second window that the problems occurred.
Perhaps I should mention this timing difference between MSTS and ORTS to Steve Davis, the author of the Skyline Activity Generator that created the activity? It is a very useful utility for creating random setup and pickup activities, and it may be possible to change the program code to avoid the timing glitch.
There may be another source of signalling differences between MSTS and ORTS, in that the two simulators place the consists in different positions relative to the start of a path (Rear of the consist vs. front or middle) - is it possible that an AI consist may be created such that the initial signal states are different? That would require designing the activity slightly differently for the two simulators. I found earlier that one of the Kuju default MSTS activities for Marias Pass had to be modified for OR because the player train was started on the wrong branch of a switch, and collided with the AI train. Changing the player path start position fixed it.

I don't know whether anyone had found this problem but had not reported it - is it worth posting something about it on Elvas Tower?
Cheers,
Sid.

[Sid Penstone (penstone)]

Hi Rob-
RE: Bug 1249872
It's good to see that the work on this bug was completed. I have tried the original activity with recent versions (X2158) and it looks good: the oncoming train that collided with the player train is no longer created in the "Auto Signal" mode.

To get the same activity behaviour as MSTS, where the activity starts with a red signal facing the player, and two early traffic trains, either:
1) The player must switch to "Manual" as soon as the activity starts - the red signal appears immediately to hold the player train on the siding, and the oncoming traffic train (Traffic6) is created after several seconds (as seen in the F5 HUD). The subsequent signalling is correctly handled.
or:
2) The activity file must be modified so that the Traffic6 (oncoming) train is created at least 20 seconds before the player train. This gives an activity that appears identical to the MSTS performance - the Traffic6 consist (and also the Traffic1 consist) appear when the activity starts, and signalling is correct. The player can operate in either "Auto Signal" or "Manual" mode while travelling to the pickup siding. This seems to agree with your description of the handling and initialization of traffic within a few seconds of the player train.

I initially thought that I understood this, but now I am still somewhat puzzled by the ORTS handling of the TWO early traffic trains in this activity. There are two traffic trains (--Traffic1 "30F" and --Traffic6 "36F") that call for creation within a few seconds before the player train's creation time. Traffic1 which runs away from the player train has a start time of only 5 seconds before the player train, but gets created OK. The oncoming train (Traffic6) is set for creation only 10 seconds before the player train, and never gets created in "Auto" mode - presumably because it is "approaching", and according to your earlier explanation. But switching to "Manual" causes it to be created after 10-20 seconds and sets the red signal - which is interesting. Is that because the AI processing is repeated ?

Would it be reasonable for the OR code to shift the start times that are close to the player activity start time internally, to guarantee that they are all initialized correctly ? In this activity, I tried setting all both of the early creation times to 20 seconds before the player, and it worked fine.

An obvious fix is to create activities that start AI far enough ahead of the player time.

I'm not suggesting more work on this, but I would be interested in your comments (when you have time - I realize how busy the ORTS developers are...)

Cheers,
Sid.

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Extract from the activity file:
Player_Service_Definition ( SLG-CPMactierLOCALSSOUTH_2
 Player_Traffic_Definition ( 34200 )--------- 09:30
 UiD ( 0 )
)
NextServiceUID ( 15 )
NextActivityObjectUID ( 32875 )
Traffic_Definition ( CPMactierLOCALSSOUTHTraffic
 Service_Definition ( CPMactierLOCALSSOUTHTraffic1 34195 ----- 09:30:55
  UiD ( 1 )
 )
 Service_Definition ( CPMactierLOCALSSOUTHTraffic3 38700
  UiD ( 6 )
 )
 Service_Definition ( CPMactierLOCALSSOUTHTraffic5 37800
  UiD ( 8 )
 )
 Se...