[dennisat]

 roeter, on 03 March 2014 - 12:49 PM, said:

Can you tell me which method etc. you have put this patch?
Perhaps I can look a bit deeper and put you on the road to the root of the problem.

Regards,
Rob Roeterdink

The method is "splitSection" in "signals.cs". I added a test (float.isNaN) to the existing tests for very small numbers. The lists being scanned to calculate the distance of the train from a track object must be ultimately derived from TDB data. I haven't dug any further yet.

I'm still at the stage where I have to check the C# manuals to understand how a lot of the code works as well as work out how the TDB is arranged.

Dennis

[roeter]

 copperpen, on 03 March 2014 - 01:27 PM, said:

I am not sure my crash has the same cause. GetTrainInfo seems to be failing in this instance, possibly because OR cannot place train 23 and so fails on the total train count. The activity will run without the F4 window but without that, speed limits are invisible and signal aspects are not that easy to see.

I can assure you that the problem with train 23 has nothing to do with this, train 23 simply never becomes a real 'train'. There is also no such thing as a 'total train count'. The crash in F4 occurs when it attempts to sort the information on distance - an invalid distance value in one of the items in this list would cause this to crash.

 dennisat, on 03 March 2014 - 02:19 PM, said:

The method is "splitSection" in "signals.cs". I added a test (float.isNaN) to the existing tests for very small numbers. The lists being scanned to calculate the distance of the train from a track object must be ultimately derived from TDB data. I haven't dug any further yet.

If you throw an exception when an invalid value is found [ using throw new InvalidDataException("...") ], the program will crash but it will generate a call dump, which will tell where the method was called. This will indicate if the invalid position comes from a signal or a cross-over, as the method is called in the processing of both these items.
When it is known where the method was called when an invalid number occurs, trace statements can be added at that location which dump the ident of the item being processed to the log-file. The last item before the crash is the one which is probably causing the problems.

Regards,
Rob Roeterdink

[dennisat]

 roeter, on 03 March 2014 - 04:19 PM, said:

If you throw an exception when an invalid value is found [ using throw new InvalidDataException("...") ], the program will crash but it will generate a call dump..

Thanks, I'll give it a try today.

Dennis

[dennisat]

 copperpen, on 03 March 2014 - 02:15 PM, said:

Maybe, but this is right at the start of the activity, or any time after.

You'll find quite a few of these in MEP, many of them with AI that just shuffles up and down a platform. Presumably this is to give more activity at locations you pass or stop at. I've found that you can adjust the path slightly so that OR will accept it and it will still work in MSTS. It's a bit fiddly. However, because OR doesn't use the same algorithms as MSTS to time AI, you'll usually find the train has gone when you pass the point you're meant to see it.

Dennis

[dennisat]

 roeter, on 03 March 2014 - 04:19 PM, said:

If you throw an exception when an invalid value is found [ using throw new InvalidDataException("...") ], the program will crash but it will generate a call dump...
Rob Roeterdink

What a tedious day.

However I have now tracked back to method TryTrackSectionCurved in signals.cs. I am working from X2060.
In this method is a calculation var radiansAlongCurve = (float)Math.Asin(l.Z / trackSection.SectionCurve.Radius); which returns a non float number in the instance I'm trying to track because l.Z = 196.3618 and trackSection.SectionCurve.Radius = 196.28 which yields a value of 1.000416... which of course is too big to be a sine so radiansAlongCurve is left null.
This affects the subsequent calculations and tests and finally allows a TrackNodeCandidate to be passed back with a null parameter lon.
This ultimately crashes the Track Monitor and may cause other problems that I've not noticed yet.

The question is now how do I locate the relevant TDB entries and/or the Track piece causing this problem from this point.

I have to do some chores now for a couple of hours - it'll be a nice rest.

Dennis

[roeter]

Welcome to the world of bug chasing - it is often a tedious and slow affair and can really leave you completely dazzeld :party: .
Anyway - you're almost there. If you stop in TryTrackSectionCurved (which is in traveller.cs, by the way), take a look at the variable trackVectorSection - this is a class, which holds all information on the related track section : the section type, shape, the tile in which it is located, the tile UiD and it's position.
Interesting to find out what's going wrong here :derisive: .

Regards,
Rob Roeterdink

[gpz]

Based on Dennis' finding, it looks like the "if" test before the line Dennis mentioned is principally wrong:

// Compute distance along curve (ensure we are in the top right quadrant, otherwise our math goes wrong).
if (l.Z < -InitErrorMargin || l.X > trackSection.SectionCurve.Radius + InitErrorMargin || l.Z > trackSection.SectionCurve.Radius + InitErrorMargin)
    return null;
var radiansAlongCurve = (float)Math.Asin(l.Z / trackSection.SectionCurve.Radius);

The last part is: || l.Z > trackSection.SectionCurve.Radius + InitErrorMargin
With this condition the asin function can really fail. It should be just simply: || l.Z > trackSection.SectionCurve.Radius

[copperpen]

Removing the + InitErrorMargin as suggested has allowed the activity to run with the F4 window open. Thank you Dennis for ploughing through the code.

Next thing is to edit this activity and see why two consists are not appearing in OR.

[James Ross]

 gpz, on 04 March 2014 - 12:14 PM, said:

Based on Dennis' finding, it looks like the "if" test before the line Dennis mentioned is principally wrong:

// Compute distance along curve (ensure we are in the top right quadrant, otherwise our math goes wrong).
if (l.Z < -InitErrorMargin || l.X > trackSection.SectionCurve.Radius + InitErrorMargin || l.Z > trackSection.SectionCurve.Radius + InitErrorMargin)
    return null;
var radiansAlongCurve = (float)Math.Asin(l.Z / trackSection.SectionCurve.Radius);

The last part is: || l.Z > trackSection.SectionCurve.Radius + InitErrorMargin
With this condition the asin function can really fail. It should be just simply: || l.Z > trackSection.SectionCurve.Radius

AFAICT, removing that means there's no acceptable error margin any more on that edge, which makes the code much worse. If we need to clamp the values for the Asin calculation, that's fine, but do that instead of messing with the actual "are we on this curve" test, please.

[gpz]

Then modify it like this:

            if (l.Z < -InitErrorMargin || l.X > trackSection.SectionCurve.Radius + InitErrorMargin || l.Z > trackSection.SectionCurve.Radius + InitErrorMargin)
                return null;
            float radiansAlongCurve;
            if (l.Z > trackSection.SectionCurve.Radius)
                radiansAlongCurve = MathHelper.PiOver2;
            else
                radiansAlongCurve = (float)Math.Asin(l.Z / trackSection.SectionCurve.Radius);