Atomic Systems

OpenAL32.dll in TS20XX need some clarification
Geekish Score Very High!
A couple of years ago I experienced some sound issues with TS. Following advice on the forums I dl the latest version of OpenAL32.dll from Creative Labs and installed it into my main Railworks folder as per instructions. This was pre- the 64-bit version of TS20XX. That worked fine.

When the 64-bit version of TS was introduced, I updated this software using a soft_aol version both 32-bit and 64-bit, i.e. OpenAL32.dll and OpenAL64.dll. The last update was in early 2020.

Recently I experienced an issue with a scenario (in TS-64-bit and 32-bit) causing an OOM. Event Viewer and View Reliability history showed the cause of the crash was the version of openAL64.dll that I had installed earlier this year (both 32 and 64-bit).

So, I thought I will rename these downloaded 32 and 64-bit versions (in the Railworks folder) so that TS20XX had to use the default version in the \STEAM\steamapps\common\RailWorks\Install\OpenAL\32—bit and 64-bit folders.

TS failed to launch so I decided to copy the "32 and 64-bit" versions from the install folder into the Railworks folder – but that would mean that the 64-bit version would overwrite the OpenAL32.dll version from the install folder. The 64-bit OpenAL**.dll that comes with TS20XX is named by convention OpenAL32.dll, i.e. the same name as the 32-bit version.

I went ahead and did that anyway and TS failed to launch yet again. (TS starts fine with my updated downloaded 32-bit and 64-bit versions installed in the Railworks folder).

The questions.
Should TS20XX start just using the OpenAL32.dll versions in the INSTALL folder and with NO versions in the Railworks folder?
Does anyone know of stable robust versions 32 and 64-bit OpenAL**.dll and should they be installed in the Railworks folder or the INSTALL folder?
Any other thoughts would be appreciated.
pH

peterfhayes wrote: ↑Fri Dec 04, 2020 9:57 pm Should TS20XX start just using the OpenAL32.dll versions in the INSTALL folder and with NO versions in the Railworks folder?

Stuff in the Install folder is the installers for that given product.
The game uses the files in the ..\RailWorks folder when playing.

This works (for me anyway)

ahunter1984 wrote:Try this:

https://kcat.strangesoft.net/openal.html#installing. Under downloads, download openal-soft-1.19.1-bin.zip and extract the contents. Within that folder is another folder called bin and inside that folder are two folders called Win32 and Win64. Rename both dll's OpenAL32.dll and OpenAL64.dll respectively and then copy them to your RailWorks folder and overwrite when prompted.

(viewtopic.php?f=361&t=152063&p=1869972& ... d#p1869984)

If that archived pack\ge has been removed, openal-soft-1.20.1-bin.zip works too.

Gary
Thanks - I understand how it works now!!
Unfortunately, the link you show is "dead"

This site can’t be reachedkcat.strangesoft.net’s server IP address could not be found.
Try running Windows Network Diagnostics.
DNS_PROBE_FINISHED_NXDOMAIN

openal-soft-1.20.1-bin.zip

That is the one that I am using at present.

Back to further investigation as to why an OpenAL**.dll error can crash a scenario!
pH

Which scenario is it Peter?

Gary
This one was on the JT Metropolitan Line called (S7+1) "Train 473 1052 Baker Street to Harrow on the Hill", but it shows openal32.dll as the error in any of the JT metro scenarios that won't load (OOM) on ONE of my PCs.
It also shows in the WS scenarios N.S50 and N.S500 both give an OOM error due to OpenAL.
The plot thickens, event Viewer is recording an error due to OpenAL32.dll NOT the 64-bit version, how is that possible running windows and TS20XX in 64-bit mode why is it accessing the 32-bit version of OpenAL?
pKa

Peter,

You may recall that I had OOM errors with the Met Line route as well. I've just had "(S7+1) "Train 473 1052 Baker Street to Harrow on the Hill" crash as usual and can't see any entry in the Event Viewer or Reliability History that might be related to the crash. I may well be looking in the wrong place though! Any advice on which part of Event Viewer to search would be welcome.

Andy L

Andy
Unfortunately not all TS Errors are reported in Reliability History or Event Viewer. Some won't even show in Logmate.
If you haven't got the red circle and white cross in RH then it won't show in the EV.
It is possibly due to the way the TS base code interprets "internal" errors.
Like you, I get these OOM's in the JT Metro Line - the scenario starts to load - gets quite a way in, and then just as it is about to display the opening sequence - OOM. Running Windows in Clean Boot mode and the crash still occurs, so it's likely to be internal to the JT Metro Line code.
The last couple of JT Metro Errors did show OpenAL32.dll (NOT OpenAL64.dll) as the culprit. I installed several earlier copies - but that didn't work either. (I only run windows and TS in 64-bit mode)
The weird thing is if you run a JT Metro scenario and it crashes, then open TS again and run the same scenario it may sometimes load/run.
The other thing that I did is I copied a faulty scenario and in TS-Tools I removed the player train - that loaded OK - but of course, you can't drive anywhere - then I loaded the same original scenario and invariably it loaded and ran OK.
The scenarios that did load/run - with some just panning in the cab - OOM.
In some scenarios, if you changed the default S7+1/S8 DLC to say the "red buffer" variants via TS-Tools the scenario might load and run.
I ran a couple of QD's without issue.
All the OOM scenarios load OK in TS-Tools but not in the TS Editor.
I'd like to remove all consists except the player train and then if it ran load the other DLC back again one by one. Unfortunately, you can only remove one consist at a time in TS-Tools so it becomes a long tedious process, and I forget where I got to!

Any of those scenarios have a StartingSave.bin file in their folder?

Hi Gary
No all have InitialSave.bin.
pKa

peterfhayes wrote: ↑Wed Dec 16, 2020 7:40 pm Andy
Unfortunately not all TS Errors are reported in Reliability History or Event Viewer. Some won't even show in Logmate.....

Thanks Peter. I was wondering if OpenAL32.dll might be the cause as you'd found in some cases but apparently not if that would show in Event Viewer. As discussed in the past my experience is similar to yours in that sometimes the scenario will run after failing the first time and that if a scenario does load then panning the cab view or switching to an outside view can cause the OOM crash.

Andy L