[Csantucci]

Thanks Mervyn, I'll have a try. Without those wagons I wasn't able to reproduce the hangup.

P.S.: I got the hang: now I'll try to find out what is the reason.

[Csantucci]

The problem arises in this while(true) block (often risky construct) within SignallingDebugWindow.cs:

            while (true)
            {
                Train.TCPosition thisPosition = new Train.TCPosition();
                TrackNode tn = trackNode.TN;
                float offset = trackNode.TrackNodeOffset;
                int direction = (int)trackNode.Direction;

                thisPosition.SetTCPosition(tn.TCCrossReference, offset, direction);
                Train.TCSubpathRoute tempRoute = Owner.Viewer.Simulator.Signals.BuildTempRoute(null, thisPosition.TCSectionIndex, thisPosition.TCOffset, thisPosition.TCDirection, 5000.0f, true, false, false);

                ObjectItemInfo thisInfo = Owner.Viewer.Simulator.Signals.GetNextObject_InRoute(null, tempRoute, 0,
                    thisPosition.TCOffset, -1, ObjectItemInfo.ObjectItemType.Signal, thisPosition);

                var signal = thisInfo.ObjectDetails;
                if (signal == null)
                    break;
                if (signal.this_sig_lr(MstsSignalFunction.NORMAL) == MstsSignalAspect.UNKNOWN)
                    break;
                var signalDistance = thisInfo.distance_found;
                if (signalDistance < 0.001 && distance > 10000)
                {
                    var pippo = 1;
                }

                if (signalDistance > 0)
                {
                    distance += signalDistance;
                    trackNode.Move(signalDistance);
                    if (trackNode.TrackNodeIndex != nodeIndex)
                        break;
                    rv.Objects.Add(new TrackSectionSignal() { Distance = distance, Signal = signal });
                }
            }

(the pippo variable was added for debugging reasons). Well, the program continues looping because distance is = 13525.8105 and signalDistance is = 0.00048828125 . Due to precision problems adding distance to signal distance does not modify distance, and so the program loops endlessly. Trying now to find out which can be the most suitable way out.

[Csantucci]

OK, replacing the two attached runactivity .exes in release x3486 solves the problem of the NEC 4.0 hangup.
File removed as patch has been uploaded
Here the simple patch
 SignallingDebugWindow.cs.patch.zip (386bytes)
Number of downloads: 294

I hope this solves all hangups, even if this cannot be sure, due to the while(true) loop.

[James Ross]

Csantucci, on 24 March 2016 - 10:52 AM, said:

OK, replacing the two attached runactivity .exes in release x3486 solves the problem of the NEC 4.0 hangup.
Runactivities.zip
Here the simple patch
SignallingDebugWindow.cs.patch.zip

I hope this solves all hangups, even if this cannot be sure, due to the while(true) loop.

Ah, well figured out.

Another fix may be to make the "while (true)" be "while (distance < MaximumSectionDistance)" or some such. I guess it depends whether we can ever get a small enough "signalDistance" that it won't move "distance" even before it reaches 10000 (MaximumSectionDistance). Either way, checking distance before and after the += is good.

[Csantucci]

Patch uploaded in x.3487.

[Sid P.]

Carlo,
You were too fast for me!
I had been busy elsewhere, so did not see your request for the car downloads until now. I'm glad someone else found them for you.
Your patch works fine- nicely done!
(I had a very similar problem in some contract software I wrote years ago that simulated the downward forces due to long convoys of vehicles across a bridge span - for certain combinations of vehicle axle spacing and bridge span, the program would freeze the motion of the vehicles. Round-off in the digital world!)

Cheers,

[Eldorado.Railroad]

Tested X3487.....still crashes!

May I suggest using "Sid P." scenario, but add at least 25 different AI trains. The test I use has at least that many different AI trains.

Thanks for all the hard work,

Steve

[Sid P.]

Eldorado.Railroad, on 26 March 2016 - 03:37 AM, said:

Tested X3487.....still crashes!

Steve

Did it crash for you with the original version of my activity? That would be weird, since X3487 was completely OK for me.
(The new 1.1 release was also OK.)
Before the patch, I had found that with no AI traffic, the problem did not occur.

Cheers,

[Eldorado.Railroad]

Sid P., on 26 March 2016 - 07:48 AM, said:

Did it crash for you with the original version of my activity? That would be weird, since X3487 was completely OK for me.
(The new 1.1 release was also OK.)
Before the patch, I had found that with no AI traffic, the problem did not occur.

Well what I wrote is a matter of.....trying to replicate my problem on Kicking Horse Pass with your activity. I have not downloaded your .apk because I know I will have a devil of a time reconciling all of the rolling stock. But as I indicated in the original post, there are at least 25 AI trains, with most likely at least 12 active AI trains in the activity at any one time. Note, my test is not in timetable mode either. So when the activity starts, there is more than one AI train traveling down a specific common route, with about 20 minutes between each one. As the player train progresses new AI trains appear on the track.

Hope this clarifies what we are aiming for.

Thanks for all your hard work,

Steve

[Eldorado.Railroad]

Csantucci, on 24 March 2016 - 12:22 PM, said:

Patch uploaded in x.3487.

This patch does not resolve the problem here...Open Rails still crashes.

Thanks,
Steve