Zusi 3 - Aerosoft Edition (1040730)

[besentv]

Compatibility Report

• Name of the game with compatibility issues: Zusi 3 - Aerosoft Edition
• Steam AppID of the game: 1040730

System Information

• GPU: GTX 1660ti
• Driver/LLVM version: 455.45.01
• Kernel version: 5.9.11-3
• Link to full system information report as Gist: https://gist.github.com/besentv/464cc4aeedd8c33580e9d29aee9cce94
• Proton version: 5.13-4

I confirm:

• [x] that I haven't found an existing compatibility report for this game.
• [x] that I have checked whether there are updates for my system available.

steam-1040730.log

Symptoms

The game (Zusi 3) uses an external dotNetCore executable called ZusiDisplay.exe to show speed and information displays in game. On Windows it looks like this:

But using Proton they don't show up at all:

The game communicates with ZusiDisplay using Tcp/Ip. When multiple displays are running, only one (a master) directly communicates with the game and distributes data coming from the game to every other running instance also over Tcp/Ip. All displays send graphical data back to the game to show the displays.

Maybe this screenshot of htop helps:

When I run ZusiDisplay manually with Proton inside steam's prefix the program runs without crash when the main game is not running: STEAM_COMPAT_DATA_PATH="/run/media/bernhard/ManjaroVolume2/SteamLibrary/steamapps/compatdata/1040730/" "/run/media/bernhard/ManjaroVolume2/SteamLibrary/steamapps/common/Proton 5.13/proton" run "/run/media/bernhard/ManjaroVolume2/SteamLibrary/steamapps/common/ZUSI 3 - Aerosoft Edition/_Tools/ZusiDisplay/ZusiDisplay.exe"

Reproduction

• Install the game.
• Install .netCore (windowsdesktop-runtime-3.1.10-win-x86) into the game's prefix: protontricks -c "wine /home/bernhard/Downloads/windowsdesktop-runtime-3.1.10-win-x86.exe" 1040730
• Copy all fonts from Windows into the prefix (ZusiDisplay crashes without): /SteamLibrary/steamapps/compatdata/1040730/pfx/drive_c/windows/Fonts/
• Run the game
• Open a timetable. e.g. : /ZUSI 3 - Aerosoft Edition/_Zusidata/Timetables/Deutschland/Siegstrecke/Blankenberg_Au_Altenkirchen_2018.fpn
• Play a train using ZusiDisplay eg. BR 423/424/425

[sr-pimposo]

I've found a fix for ZusiDisplay not launching while the game is running. Following some tips from the r/steamplay reddit, following this instructions, I was able to get ZD opening together with the game. This disables Proton's soldier, so I guess is not recommended to do it.

This was only necessary if you want to launch a separate instance of ZD. If you go to settings on Zusi's launcher you can use one of it's tabs to set launch applications that seem to launch ZD normally.

But, although it launches, I still have the same problems, black screens, and crashes too. Just to get it launching I had to follow besentv instructions.

My specs at the present: Proton 5.13-5 Kernel 5.10.9 Mesa 20.3.3 OpenSuse Tumbleweed

[w-flo]

The "integrated/embedded" displays seem to generally work for me using Proton 7. Performance in some situations (in the FIS sub-menu of BR 422 for example) is less than perfect which makes it pretty hard to use the displays in those situations on older hardware, but other than that, it's perfectly "playable". Maybe performance suffers because the ZusiDisplay<->Zusi inter-process-communication apparently uses named pipes for embedded displays, and lots of very small named pipe reads (often just a few bytes each), which have to go through the wineserver every time.

Other than performance, I've noticed these remaining issues:

• Proton bundles a slightly larger "Microsoft Sans Serif" alternative font, so the ZusiDisplay settings menu doesn't really work (#5572)
• "Sharing Violation" / "Freigabeverletzung" errors when selecting a train, should be fixed with the next Proton release (https://github.com/ValveSoftware/wine/issues/136) (Edit: This is now fixed in Proton Experimental)
• When a train reverses at a station (e.g. at a terminal station), only the "bus master" embedded ZusiDisplay comes back up, other displays are gone (someone reported on the Zusi forums that this works for them, probably on upstream wine). ZusiDisplay logs indicate that other displays try to connect to [::ffff:127.0.0.1]:41801, probably to reach the ZusiDisplay "bus master", but nothing is listening on that port even though the "bus master" logs say "Server started". Something is listening on port 41811 though. Maybe I can somehow figure out what's going on.
• Pretty minor issue: While loading a schedule/scenario, the Zusi window pushes itself into the foreground all the time, which is annoying because load times can be long and I prefer to browse the web instead of looking at the Zusi window. This is caused by a wine-staging patch (corresponding bug report) and doesn't happen on Windows or upstream wine (probably). The bug report contains an alternative patch set for the same issue, but it apparently has other issues (and is probably outdated).

Other than that, things seem to work pretty well for me. I guess more things will break soon though, as the Zusi developer has plans to switch to 64bit binaries and it seems like lots of refactoring/code updating/dependency updating/… is going on right now.

[besentv]

• When a train reverses at a station (e.g. at a terminal station), only the "bus master" embedded ZusiDisplay comes back up, other displays are gone (someone reported on the Zusi forums that this works for them, probably on upstream wine). ZusiDisplay logs indicate that other displays try to connect to [::ffff:127.0.0.1]:41801, probably to reach the ZusiDisplay "bus master", but nothing is listening on that port even though the "bus master" logs say "Server started". Something is listening on port 41811 though. Maybe I can somehow figure out what's going on.

I looked into this a while ago and back then, not sure if it's still the case, it was caused by the fact that Zusi closes the Zusi Displays using TerminateProcess(), which force closes sockets on Windows but on Linux they are gracefully closed, which takes too much time and causes ZusiDisplay to not be able to rebind on that port. More can be read here: https://bugs.winehq.org/show_bug.cgi?id=50955

[eldomtom2]

With the most modern versions of Zusi and Proton Experimental, ZusiDisplay launches fine, but in my experience only if the following launch setting is set: "PROTON_LOG=1 DOTNET_BUNDLE_EXTRACT_BASE_DIR="c:/users/steamuser/test" %command%"

However, only the left display works, the centre and right displays do not. According to the Zusi Forums this is due to the Wine version Proton uses lacking support for TCP features ZusiDisplay uses; apparently Wine 9.4 fixes this but I cannot confirm that myself.

[w-flo]

Interesting! I've never used the DOTNET_BUNDLE_EXTRACT_BASE_DIR env var, and as far as I can tell, ZusiDisplay works fine. I recently removed the Proton prefix (the ....../steamapps/compatdata/1040730 dir) and that caused the prefix to be recreated and dotnet to be reinstalled like on a fresh install, so maybe that's why it works for me.

For the missing displays, this MR fixes it for me: https://gitlab.winehq.org/wine/wine/-/merge_requests/5195 It is included in wine 9.4. Maybe we can request a backport for Proton 9?

[eldomtom2]

It seems to vary depending on the user - for me, without that env var, dotnet tries to write temporary files to the main Linux drive and gets denied permission.

[besentv]

However, only the left display works, the centre and right displays do not. According to the Zusi Forums this is due to the Wine version Proton uses lacking support for TCP features ZusiDisplay uses; apparently Wine 9.4 fixes this but I cannot confirm that myself.

Zusi display uses .NET 6.0 now, but Steam still installs .NETCore, maybe installing the former manually helps?

[w-flo]

Zusi display uses .NET 6.0 now, but Steam still installs .NETCore, maybe installing the former manually helps?

Are you sure Steam still installs .net core? There's a file windowsdesktop-runtime-6.0.13-win-x64.exe in the Zusi _redist/dotNET/6.0 directory and I suspect that's .NET 6.0, and it's listed in the installscript.vdf file.

In any case, ZusiDisplay works fine for me after applying my merge request (linked in my last comment) to Proton 9's wine source and copying that ws2_32.dll and ntdll.so over to my Proton binary dir. No changes to the wine prefix, only the things Steam installs automatically on first start.

Some remaining issues in Zusi:

• Time formatting uses 12hr am/pm format, even though my system and Zusi itself (using the setup dialog on first startup) is set to German language with 24hr time format. I believe this was a regression in Proton 8. Related log entry: 0024:fixme:steam:setup_steam_registry Game language "english", defaulting LC_CTYPE / LC_MESSAGES to en_US.UTF-8. (can be fixed by manually setting LC_CTYPE and LC_MESSAGES to de_DE.UTF-8 in game startup options in Steam.)
• In "time jump" mode, moving trains can be heard for some reason. I investigated this for a bit and couldn't find anything obviously wrong with dsound in wine, i.e. Zusi actually creates these secondary audio buffers, puts them into "playing" state, and sets their volume to something that is not "silence" (depending on – I assume – the speed of the train, volumes for these audio buffers vary between silence and approx. -1000). If I remember correctly I can't hear them on Windows though, so something might be wrong, maybe related to 3D sound calculations, or there is some application-global "silence" option somewhere that wine ignores.
• Depending on hardware, gdiplus image resampling plus PNG saving performance is sometimes not good enough when looking at an "integrated" / embedded ZusiDisplay that takes up lots of screen space (i.e. huge display texture), e.g. when using the FIS menu of BR 422 on my old Ryzen 5 1600. In that case, ZusiDisplay won't be able to keep up with the required FPS and the display will start lagging behind simulation time, making it pretty much unusable until it catches up with real time again in a viewing mode where the display / texture is smaller (or Zusi pause mode).