[markus_GE]

I used autopilot to get to the location where the earlier freeze up used to happen. From there, I continued in normal mode for about 5 miles, and thru about the same number of signal blocks. IDK if that changes anything.

Cheers, Markus

[Csantucci]

roeter, on 20 May 2015 - 08:35 AM, said:

For AutoPilot, the train is of class AITrain, so the reference is to an instance of an AITrain.
When changing to normal control, the train changes to class Train.

Regards,
Rob Roeterdink

That's not exact. If you run with the autopilot option checked in the experimental options, your train will always pertain to the AITrain class, be it player driven or automatically driven. Pressing CTRL/A does not let your change class. Train changes only type (AI_PLAYERHOSTING or AI_PLAYERDRIVEN). To change class you have to uncheck/check the experimental option (that is you have to exit the game, change option status and restart the game).

[roeter]

Despite that, it still holds true what I stated above.
When processed as player train, the train calls the methods in Train.cs - and there, it cannot exist as AITrain, as all references to trains in method calls etc. are defined as Train class.
The train should not loose its identity because of this - it is only cast as a Train class within the methods but still 'lives' as an AITrain. But it very much seems that probably because of the different 'flow' through sets of different methods for AITrain compared with Train, it does end up as a different instance, or at least a different reference, in the call to the signal processing.

The warning as noted by Marcus has only one condition through which it can be generated :

if (enabledTrain != null && enabledTrain != thisTrain)
[etc.]

In this statement, enabledTrain is the instance of the train linked to the signal, thisTrain is the instance requesting to clear the signal.

So, the only way this warning can be issued is if there are two different instances of the player train.
Loop processing can - and indeed does - still have problems, but it cannot create two instances for the same train as its processing is consistent - it always calls the same set of methods. Only when changing from Auto Pilot AI-control to Auto Pilot player control is there an inconsistency in processing, because of different flows through different modules where different type casting is used.
So it does seem very likely that this problem is somehow linked with switching from AI to player control in Auto Pilot mode.

Finding the problem could well be quite difficult, as the (mis-)casting could take place anywhere within the many methods in both modules.

Regards,
Rob Roeterdink

[markus_GE]

As soon as I find time (and motivation) to do the run in manual mode for about th 20th time, I´ll try that (with Autopilot completely unchecked).

Cheers, Markus

[Csantucci]

You could run it also only with autopilot, if there aren't strange shuntings. Or, if your train is the only one in the activity, you can run it manually, but simply setting throttle at 100% and with increased clock speed.