Trainz 2019 crashes when speed approaches 65 MPH.

ColPrice2002 - Problem only manifests itself if you are observing a nearby consist attaining or exceeding 63 mph using an external camera view. If in-game sound levels are set to zero (off) then no CTD occurs.
Actually there's more to it than that (which is why the "fix" for this issue has not resolved all problems). There are other factors required as well. Most users have no problems at any speed, camera or view distance. The one reliable test case we had internally was fixed, so we assumed that the problem was resolved. We are yet to find another reproducable case internally, so we may need further assistance to resolve this one. I'll get more information about what we require and let you know.
 
Great. Thanks Tony! Keen to find a resolution for this one as it affects quite a few of my DIY sessions.
Problem is NOT present in T:ANE SP4 beta build 102323 in the same session scenarios.
 
Last edited:
Actually there's more to it than that (which is why the "fix" for this issue has not resolved all problems). There are other factors required as well. Most users have no problems at any speed, camera or view distance. The one reliable test case we had internally was fixed, so we assumed that the problem was resolved. We are yet to find another reproducable case internally, so we may need further assistance to resolve this one. I'll get more information about what we require and let you know.

If you let me know what info you need and can provide guidance to help me give you what data is required I will try my best to help.
 
Ah, brings back memories of similar hardware/software dependent bugs. TRS 2006 ‘sound dropout’ bug (never fixed from memory) and the TRS 2012 ‘coupler breakage’ bug (fixed eventually). Trainz was due another such bug:hehe:.
 
Ah, brings back memories of similar hardware/software dependent bugs. TRS 2006 ‘sound dropout’ bug (never fixed from memory) and the TRS 2012 ‘coupler breakage’ bug (fixed eventually). Trainz was due another such bug:hehe:.

At least with this version the team is determined to fix the problem sooner than later. The sound dropout issue remained into TS12 though and is still an occasional issue. Windwalkr said there are plans to fix the sound subsystem at some point and there was talk of it in the Trainz Dev forum a year or so ago. I have found that some of this is content dependent as well as route-density dependent. If there are lot of sound-producing assets in close proximity to each other, things get messy and when you add in lots of content causing stutters, the sound is the first thing to give up.
 
It's actually fixed but missed the integration for SP1 by an hour or so. (i.e. it will be in the next update).
 
The game program does not support 64MPH (103-104kph) variables

103kph=64.0012245mph
104kph=
64.6225956mph
 
Does not happen when you drive slower.

I drive at yard switching speeds of 1 mph - 5 mph, with a top mainline speed of 10 mph - 35 mph max.

Your trains running at 104KPH (64MPH) will be an absolute blurrrrrr zooming by !

Have fun, and learn to drive slower, or enjoy crash to desktop all the time.
 
Interestingly the problem is/was totally related to OpenAL (https://en.wikipedia.org/wiki/OpenAL). Our code was correct as per the OpenAL documentation, but not as per the OpenAL headers. This suggests that the OpenAL implementation itself has a bug (i.e. doesn't match its own formal specification). Since we can't do anything about that, and since clamping to the range specified in the headers appears to resolve the issue, that's the fix we've implemented. (To be included in the next update).
 
Interestingly the problem is/was totally related to OpenAL (https://en.wikipedia.org/wiki/OpenAL). Our code was correct as per the OpenAL documentation, but not as per the OpenAL headers. This suggests that the OpenAL implementation itself has a bug (i.e. doesn't match its own formal specification). Since we can't do anything about that, and since clamping to the range specified in the headers appears to resolve the issue, that's the fix we've implemented. (To be included in the next update).

Don't forget game "Pause" in surveyor fix, please.

John
 
Hey, just wondered, as the thread has gone a bit Q since the 10th, is there any further progress reports?

cheers.

It could be the devs are busy. It's been said here, by Tony Hilliam by the way, that when we don't hear from anyone in management it means they're busy. With the issue being related to the Open/AL, it could mean they need to find a workaround to get past the bug in the code that's not even their fault because they based the work on the specs given. Tony will update us at some point, I'm sure.
 
Back
Top