TRS19 SP1 Beta Update 104017 (PC) and 104042 (Mac)

Intensive testing of Build 104017 indicates that the claimed fix for CTDs when nearby locos approach 64 MPH in external camera view is NOT working for this particular build.
Indeed, this (simulated Doppler effect?) 3D sound-induced crash sometimes occurs at lower speeds when the vehicle is approaching the camera. Tested using several sessions/ many different consists, etc.
Work-around 'fix' of turning off in-game sound still applies, but it is now quite annoying to run sessions in Driver mode with all sounds turned off to ensure continuity.
T:ANE release candidate SP4 build 102323 is not affected by this CTD issue in similar sessions/ scenarios.
So what has changed?
 
1. Signals are dark
2. Visible loads do not appear on a rail cars even when queues show loaded in info box and loads labels display over rail cars.
3. FT fixed track <kuid:-25:532> does not appear in surveyor and cannot be placed on route. Other track in this series has the same problems

John
 
Signals are dark
Known issue for JR signals. Fixed internally (relates to a unique way their signals are set up)

Visible loads do not appear on a rail cars even when queues show loaded in info box and loads labels display over rail cars.
Thanks for the report. Are the loads invisible in Surveyor only?

You can show/hide commodity labels in Display menu in Driver. This will then take effect in Surveyor

FT fixed track <kuid:-25:532> does not appear in surveyor and cannot be placed on route. Other track in this series has the same problems
Thanks for the report. (Workaround for now - move the track after placing it)

Intensive testing of Build 104017 indicates that the claimed fix for CTDs when nearby locos approach 64 MPH in external camera view is NOT working for this particular build.
Ouch - we only have one system that can/could repro this and it worked fine after the "fix".

[Update: If using Roaming camera and moving in front of the train the CTD can be reproduced].

Meanwhile, can you try turning off the 3D sound option in Sound Settings to see if that solves the problem.
 
Last edited:
Ouch - we only have one system that can/could repro this and it worked fine after the "fix".
The fix was also a workaround to a OpenAL bug rather than our code, but I'll see what our next options are.
Will continue to test using different sound cards/ sound sub-systems/ drivers, but would much prefer to use my high-end ASUS discrete PCIe sound card in any event.
BTW, Upon reflection, this problem manifested itself with earlier builds of TRS19 (but not the first, as I recall) then disappeared for quite a while (e.g. Builds 98149, 98299, 98592) until about Build 100240, when it reasserted itself.
Question: What is different in the OpenAL code for T:ANE SP4 RC and this current TRS19 build? Same session scenario/ assets, etc. in T:ANE do NOT have this CTD problem.

Edit update following further tests: Crash to desktop still occurs when 3D sound is turned 'Off' and sound volume is set to any level other than 'Off'.
Changing the sound card and drivers to either the (mobo built-in) Realtek or nVidia High Definition Audio resulted in zero CTDs under the same known trigger conditions (but execrable sound quality via the monitors' built-in speaker output!)
Interestingly, when moving it back to the ASUS Xonar HDAV 7.1 surround-sound system and fiddling again with the audio stream sample rate frequency, this also resulted in zero CTDs!
Will continue to test...
 
Last edited:
JR's MiJack worked perfectly in build 103443. Patched to build 104017 and the MiJack is non-responsive.
NO changes were made to the route or session, just the patch.
 
JR's MiJack worked perfectly in build 103443. Patched to build 104017 and the MiJack is non-responsive.
NO changes were made to the route or session, just the patch.

Are you talking about cab mode here? Checking the engine spec for <kuid2:45324:1151:2> MiJack 1200R engine it certainly looks way out of whack with a top speed of 8mph.

It looks almost like there is an incorrect decimal point in the throttle power setup. This should probably be 278 not 2.78. There is also no dynamic brake entry (perhaps prototypical?).

1
{
0.00 2.78
0.15 2.78
0.45 2.78

I'd be very surprised if it worked previously

Checking the DCC mode, it is set to max accel of 1500 whereas 15000 is a more normal figure.

Changing this and adding a 0 to the max decel meant it works fine.

Are you sure it ever worked correctly?
 
-There is no cab mode.
-Be surprised.
-Of course I'm just lying about it having worked correctly.

There is no cab mode.
>>
How so?

Of course I am not suggesting you are lying, but rather something in your testing does not match the information provided so far (since we cannot see the same problem you're seeing).

Which loco are you testing this in as our tests of the engine spec show no difference between any build. Perhaps it requires a uniquely set up loco as well (since the engine spec is clearly under-powered).

Update:
After QA have done further investigation, it appears "Mijack" is an engine spec for a crane, not a loco. (This type of information when reporting a bug is very useful to avoid QA trying to use a crane engine to move a loco).

Once we have found and installed the crane, it also works fine in 104017 (and it the release today 104261).

Please advise if it isn't working for you. If so, what is the KUID of the crane, the engine, do they show as modified etc.
 
Last edited:
That build failed the final QA internal testing so we decided to withhold it. Sorry we didn't update the table (now done).
 
Back
Top