ATS .dll Failing to Load on 1.8.x.x+

[m2jest1c]

Description

I have a couple of trains where the ATS DLL is failing to load claiming it will only load on Microsoft Windows. Here's the catch: I've tried this on both Linux (wine) and Windows, and in both cases, the DLL fails to load with the exact same error. On 1.7.x.x or earlier, this DLL works perfectly fine. I suspect it has something to do with the Win32PluginProxy, although I'm speculating because it's far too late for me to sit here and figure out what exactly's going on.

The problem with the ATS DLL not loading is that the destination signs (controlled with number row keys 0, 9, 8, 7) do not work. Instead, they seem to be controlled by the keys used to control the throttle. For obvious reasons, this is problematic.

Reproduction

Train

https://drive.plausibility.cloud/s/q9xBtdckdSpbSsm I know the link is a bit shady. It's my self hosted Nextcloud.

Logs

https://gist.github.com/m2jest1c/5537f254b7a104ea85009d92aed41638

Related information

• Fedora 35: kernel 5.15.18-200.acs.fc35.x86_64, wine version lutris-fshack-6.14.3-x86_64
• Windows 10 Enterprise 19133 21H1
• Keyboard, Joystick

[leezer3]

OS_ATS1.dll randomly failing to load is somewhat of a known issue, and has been ever since 64-bit windows (well before 1.8) It's not specifically version related (although I'll look into it later to be sure) The x32 version may work (OpenBVE-x32.exe), but it's a complete lottery.

TLDR: OS_ATS was compiled with an extremely elderly version of Bloodshed Dev C++. (Windows 98 era!) If the base address space assigned to the DLL is too high, something somewhere inside gets an invalid pointer, and the whole thing dies a death. Essentially as far as I've ever been able to tell, the compiler never expected more than about 512mb of RAM.

There's a couple of later compiled versions floating around which are immune to this, but the real 'fix' is to replace with BVEC_ATS: http://www.bvecornwall.co.uk/wordpress/bvec_ats-design-details/

This ought to be a straight dropin replacement & will read the original configuration etc.

[m2jest1c]

Thanks for the quick response! Greatly appreciated. I'm assuming it's version related because of the switch to x64 in 1.8.x.x. Did some more of my own research and like you said, OS_ATS is old old.

BVEC_ATS does not seem to do anything in terms of the destination system. It's still controlled by the throttle. I'll need to do more diagnosing this evening (it's 02:30 right now). Configuration file for the new ATS system seems visually similar to the old OS_ATS one, but I didn't run a diff or anything, just checked visually. Some things may have changed.

I'll let you know more later.

[leezer3]

Just tested on the dev box (Windows 10 Pro 21H2), and as somewhat as expected the supplied OS_ATS DLL works perfectly here. US stuff like that is unfortunately going to cause this more than not, as it's got some terminally oversized textures (the train itself is taking up well over 300mb of RAM, ought ti be a fraction of that) ;/

---

I can see why it doesn't like the custom indicators in BVEC_ATS: It's a longer, non-standard list of custom indicators with some odd key assignments, which the code I wrote to convert the list obviously didn't handle :/ (10 odd years ago....)

This version / config should work properly: BVEC_ATS.zip

Note: I don't believe this has any game breaking bugs, but it does have an incomplete implementation of OS_SZ_ATS (Italian fork), hence why it didn't make it to the public site. Source for that is here: https://github.com/leezer3/bvec_ats

Essentially though, work on the plugin ended up getting dropped in favour of actually fixing some of the root problems within the sim itself.....

[m2jest1c]

Hey, did a bit of testing last night and seems like this works mostly fine, although there are weird issues with AWS and some of the other British safety systems that aren't supposed to be in use. Those are more likely than not configuration issues and I'll look into it more tonight.

Thanks for this version regardless.

[leezer3]

Ack, you're right :/

We still seem to be missing the LU trainstop safety system, and have assumed that the train has TPWS / AWS if the config file entries are present.

However, it doesn't look like your train actually uses this (the config file is oddly enough a mess.....) Deleting the TPWS and AWS sections in the config file will get rid of the unwanted interventions. I'll take a closer look at LU trainstop later.

[leezer3]

Further investigation shows that your train definitely simply doesn't use the trainstop features. (Neither the panel indicies or the sound indicies are mapped to anything. It's also got a windscreen / drops defined in the ATS config, but not present in the panel & exterior)

You can safely delete the AWS / TPWS sections from the config, and as far as I can tell it'll work as designed.

I've also largely integrated the trainstop into BVEC_ATS (just requires hooking up the config file properly and some testing + cleaning up), but it can definitely be ignored completely with this, as if you try it on LU routes, you'll get safety interventions.

[m2jest1c]

Yeah, the train doesn't use any safety features. They exist in real life, I've seen them in use, but none of the openBVE route/train developers for the MTA system have modeled them, as far as I'm aware.

Anyway, I found another issue where if I apply power the side and interior overhead displays start moving. The side display stops moving after I start braking, but the interior overhead display continues moving regardless. I'd have made a video, but OBS is acting up, so I can't.

To summarize:

• The setting which controls the "Last Stop"/"Not In Service"/"Testing" displays, controlled by the 7 key, works as expected.
• The front display, controlled by the 8 key, works as expected. Perfectly fine.
• The side display, controlled by the 9 key, works as expected, unless you apply power/brakes. When power/brakes are applied, they start moving on their own.
• The interior overhead display, controlled by the 0 key, does not work as expected. It does not seem to respond to the 0 key, and moves when power/brakes are applied.

I'll do more investigating tomorrow. It's the weekend, so I have a bit more time to look into it.