[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);

[dennisat]

roeter, on 04 March 2014 - 11:57 AM, said:

... (which is in traveller.cs, by the way)....
Rob Roeterdink

Yes... You tend to lose track after continual "List all references" and "Go to definitions"!
When I was a full time programmer I used to be able to remember everything; I ought to make notes these days. I was starting to get "senior moments" - What am I doing here???
Tomorrow I'll do as you suggest and try to locate the track piece(s) in question.
Thanks for your suggestions.

Dennis

[dennisat]

I have now extracted details of the track piece involved at the time of failure:

	Dyntrack (
		UiD ( 250 )
		TrackSections (
			TrackSection (
				SectionCurve ( 0 ) 4294967295 0 0
			)
			TrackSection (
				SectionCurve ( 1 ) 42888 -1.49 196.28
			)
			TrackSection (
				SectionCurve ( 0 ) 4294967295 0 0
			)
			TrackSection (
				SectionCurve ( 1 ) 4294967295 0 0
			)
			TrackSection (
				SectionCurve ( 0 ) 4294967295 0 0
			)
		)
		SectionIdx ( 40780 )
		Elevation ( 0 )
		CollideFlags ( 583 )
		StaticFlags ( 00100000 )
		Position ( 450.505 6.57633 -597.492 )
		QDirection ( 0 0.194486 0 0.980905 )
		VDbId ( 4294967294 )
		StaticDetailLevel ( 0 )
	)

Does this look unusual? Is more information needed from the TDB or any of its related files?
Incidentally, I have tried the suggested patch from Peter Gulyas which solves the Track Monitor crash. Now I have a freeze up to try and solve - I'm fairly sure it isn't related to the Track Monitor crash.

Dennis

[roeter]

It is unusual but not wrong - it's a 85 degree curve with just under 200m. radius. One heck of a curve, but as it apparantly is on the Skegness line, it would not surprise me to find it is the former South curve at Firsby Junction (now the only track in the area) - that is a very sharp curve indeed (if you want to check it out on Google Earth : position is 53 deg. 08'56 N, 0 deg. 10'30 E).
Perhaps someone with a good head for mathematics can work out if the error has occured when the track was placed in MSTS, or whether there is some small error in the calculation in the traveller. Even on a full 90 degree curve one can ofcourse never have a delta-z value which exceeds the curve radius.

Regards,
Rob Roeterdink

[gpz]

roeter, on 05 March 2014 - 03:25 AM, said:

if you want to check it out on Google Earth : position is 53 deg. 08'56 N, 0 deg. 10'30 E

On the map it is rather a 110 or 120 degree curve. Really sharp and surprising. :sign_welcome:

[dennisat]

roeter, on 05 March 2014 - 03:25 AM, said:

...former South curve at Firsby Junction (now the only track in the area)...
Regards,
Rob Roeterdink

Absolutely right. The route (Mid East Plus) actually has most of the lines in the area "reinstated". The general era seems to be late 70s - early 80s.

Now the next problem. What would be the best place to try and trap the conditions that are causing my freeze on this route? It occurs just as a semaphore signal is passed and returns to red. I can re-create the conditions easily. I imagine I could work it out myself eventually :sign_welcome: but if you're familiar with the program flow perhaps you could save me some time?


Dennis