Space Engineers - 244850

[MagicRB]

The latest version of Space Engineers from steam, with app id 244850 seems to require a patch which wine-staging has.

Yes, I did leave out my system specs as it's not important to this issue. (Proton 3.16)

I confirm:

• that I haven't found an existing compatibility report for this game. (Not specifically for this game, and not specifically this error, though it can be seen as a fixme)
• that I have checked whether there are updates for my system available.

Symptoms

Space Engineers uses the GetCurrentPackageId function. SE crashes with en error, which says that the function was invoked with an incorrect parameter. This is caused by a bug in wine which has been ignored, wine-staging does include a patch to solve this problem. I'm not experienced enough to submit a pull request, nor I'd be able to compile proton as I'm kind of incompetent.

Reproduction

Reproduction is really easy, download Space Engineers from steam, install .net 4.7 as described here. After a successful installation of .net and with transform feedback working, you should get an error message like this

Unhandled Exception: 00bb:fixme:ver:GetCurrentPackageId (0x53a800 (nil)): stub System.ArgumentException: Parameter is not valid. at System.Drawing.Image.get_Flags() at System.Windows.Forms.ControlPaint.IsImageTransparent(Image backgroundImage) at System.Windows.Forms.Control.set_BackgroundImageLayout(ImageLayout value) at Sandbox.MyMessageBoxCrashForm.InitializeComponent() at Sandbox.MyMessageBoxCrashForm..ctor(String gameName, String logPath) at Sandbox.MyErrorReporter.ReportGeneral(String logName, String gameName, String id) at Sandbox.MyCommonProgramStartup.PerformReporting() at SpaceEngineers.MyProgram.Main(String[] args) wine: Unhandled exception 0xe0434352 in thread bb at address 0x7b44b08c (thread 00bb), starting debugger... Unhandled exception: 0xe0434352 in 64-bit code (0x000000007b44b08c).

This can easily be solved by either getting the patch upstream to wine (there might be a good reason why it's not upstream) or we could apply the patch directly to proton.

[MagicRB]

BTW I can confirm that Space Engineers does, in fact, work with wine, as I was able to start SE with wine-staging 3.18 without dxvk. It does crash as the wined3d11 API was not capable of running SE for long enough to actually play, it seemed to crash at random points in time, but this does indicate to me that SE should be functional, once we patch proton.

[MagicRB]

I tried locating the patch that makes it work under wine-staging, but I was not able to do so. I'm either completely blind or it doesn't exist. It may be that the function not working is a bi-product of some other bug. I'll continue searching

[MagicRB]

Now I have figured out that SE does crash because of something different, and that function is broken on both wine versions, now I shall figure why does it crash in the first place.

[MagicRB]

I have decompiled SE and I have figured out where is the problematic code path, it seems that SE thinks that '-report' was passed as a command line argument, but from what I understand from the decompiled source, there should not be a reason for SE to think that.

[PeacheyMcKeitch]

Ive posted a link to this thread onto the official Space Engineers support page. Will see if anyone over there has any ideas.

Also go upvote that thread on there forum to try get there attention incase its a SE and not a wine issue!

https://support.keenswh.com/spaceengineers/general/topic/improve-compatibility-with-steam-play-and-proton-linux-mac

[MagicRB]

No, you misunderstood me, let me explain a bit more. SE uses .NET 4.7.1 which IS broken in wine, but it can be made to run with a workaround and a bit of luck. Here is the workaround needed. Then, SE uses Stream Output / Transform Feedback, which is a deprecated feature in DX11, and was probably carried over from the DX9 renderer, which SE has used in the past. Now, Vulkan has recently received this extension "VK_EXT_transform_feedback", which allows Stream Output to work in Vulkan, therefor DXVK now supports Transform Feedback, therefor SE should work in wine, but wine still needs patches to expose this extension. Proton has these patches already, I think, I'm not sure, don't quote me. Mainline wine will get at the next release at it has been already staged which means wine-staging will get it too. Now wine-staging has a patch in place which enables SE to start under opengl, it still crashes as opengl is not capable of sustaining the graphics engine. The problem in proton is not related to Transform Feedback. I can't identify the patch that is responsible for this, as I actually do not know what's the problem. I have decompiled SE and looked at the code which is causing the crash, based on the stacktrace provided by the .net runtime and do not see a clear reason why it crashes. I'll post the relevant functions later.

[MagicRB]

I know, it tries to notify the user that they should update their graphics drivers. That's why it tries to report something. But still, it does work in wine-staging, so we still need to find the relevant patch.

[MagicRB]

Can someone help? I'm not sure what to look for in those patches.

[MagicRB]

https://stackoverflow.com/questions/11796082/invalid-parameter-when-setting-an-image and this seems to be related, I'm not any closer to figuring this out tho.

[MagicRB]

line 914 seems to be the problem, that's the only thing that i can see, the GdiPlus.dll is a wine native dll as can be seen here

[MagicRB]

GetGdiImageFlags returns invalid parameter if image or flags are empty, as can be seen here, line 5219, so it's probably getting nullified either somewhere in .net or when being passed to the native library from wine.

[MagicRB]

I think I found it, if I'm understanding this correctly,

GpStatus WINGDIPAPI GdipGetImageFlags(GpImage *image, UINT *flags)
{
    TRACE("%p %p\n", image, flags);

    if(!image || !flags)
        return InvalidParameter;

    *flags = image->flags;

    return Ok;
}

this function should not check if flags is 0, as flags is the output variable, which can be whatever.

[MagicRB]

I am completely wrong in my last comment, I hate pointers. Anyways, I'm going back up the stacktrace trying to find out why image is null.

[SpookySkeletons]

I am not sure on the legal ramifications but Space Engineers provides a visible/ open EULA of their source code on github, if you can look through, so you don't have to decompile.
Might be worth a look through if it's kosher, to figure out what is blowing up and commit to wine.

https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/EULA.txt

Edit:
They do have an intertoperability clause which wine falls under as 'compatibility'

[aaronfranke]

Please wait a few months until Valve updates the version of Wine that Proton uses. Valve has some patches on top of Wine and needs to test for stability, so there are reasons that Valve does not immediately update the version of Wine that Proton uses.

@SpookySkeletons That source code has not been updated since 2016.

[SpookySkeletons]

@aaronfranke
This affects Vanilla wine as well as Proton, whichever arrives first can upstream it to the other.
Space Engineers has been a major pain for years in any sort of wrapper, even when it did work it was stable as a two legged stool.

Perhaps I just don't know how any of this works but this might be something to look into.

6421.401:0031:0032:trace:module:load_dll Loaded module L"C:\windows\assembly\NativeImages_v4.0.30319_64\mscorlib\386b8793866138dad77588a7399d11c3\mscorlib.ni.dll" (native) at 0x64478000000
The library loads up at 0x64478000000
Some kind of function turns and burns here, sharing a very close trailing memory space with mscorlib.ni.dll:

6421.486:0031:0032:trace:seh:RtlVirtualUnwind type 0 rip 64478454d69 rsp 53b5d0
6421.486:0031:0032:trace:seh:dump_unwind_info **** func 454cf0-454da3
6421.486:0031:0032:trace:seh:dump_unwind_info unwind info at 0x644785364bc flags 3 prolog 0x10 bytes function 0x64478454cf0-0x64478454da3
6421.486:0031:0032:trace:seh:dump_unwind_info 0x10: subq $0x68,%rsp
6421.486:0031:0032:trace:seh:dump_unwind_info 0xc: pushq %rbx
6421.486:0031:0032:trace:seh:dump_unwind_info 0xb: pushq %rsi
6421.486:0031:0032:trace:seh:dump_unwind_info 0xa: pushq %rdi
6421.486:0031:0032:trace:seh:dump_unwind_info 0x9: pushq %r12
6421.486:0031:0032:trace:seh:dump_unwind_info 0x7: pushq %r13
6421.486:0031:0032:trace:seh:dump_unwind_info 0x5: pushq %r14
6421.486:0031:0032:trace:seh:dump_unwind_info 0x3: pushq %r15
6421.486:0031:0032:trace:seh:dump_unwind_info 0x1: pushq %rbp
6421.486:0031:0032:trace:seh:dump_unwind_info handler 0x644783da000 data at 0x644785364d8

[Guy1524]

It looks like mscorlib.ni.dll is a component for the .NET framework, which is known for being unstable under wine. You might have luck using winetricks to fiddle around with dotnet, but hopefully Ethan Lee will devise a better solution in the future.

[FurretUber]

With Mesa 18.3.1 with patches applied from here applied to support Transform Feedback and using winetricks to install .NET 4.7.2 I got very close of having the game working using DXVK. The game reached the main menu, running at 120 FPS, and the mouse cursor loads. However, the game crashes before the background video and the menu buttons appear.

The log messages seem to be pretty relevant on this case. The DXVK warn seems closely related to what happened with Wine:

SpaceEngineers_dxgi.log

SpaceEngineers_d3d11.log

steam-244850.log.gz

SpaceEngineers.log

VRageRender-DirectX11.log

My system information. Please note this is showing a different Mesa version because the 32-bit and the 64-bit Mesa builds are distinct right now.

[MagicRB]

I've managed to get to gameplay with wine-staging, dxvk, proprietary nvidia drivers. All voxels were horribly malformed and i haven't managed to reproduce it since wine updated.

[SpookySkeletons]

@FurretUber
The latest version of the game locks up after a minute or more. Opt down to the multiplayer overhaul in the beta tab and it will work.

[steve7233]

I just upgraded my GC to NVIDIA GeForce GTX 1060 and all my steam games work via steamplay except SE. I press play and SE tries to start then stops. No error message, no sound, and no game window. I have tried all the proton versions that steamplay will run. After reading this thread I at least know that many people are trying to figure it out. Sounds like a new version of proton and wine are needed. I was hoping I could use wintricks or something but it might be more complicated. That's a bummer. Maybe a lib or several libs with winecfg?

[Maltahl]

This game can launch with wine 4.3 and DXVK 1.0 - But you will need .NET 4.7.2 as additional installation.
Lutris installer for the game works flawlessly for new installations.
If you have a current installation of space engineer it might not work, i have yet to figure out why that is the case.
After that you can play the game but minor errors will still be there such as:

• Crashing when you fly crafts into other crafts or rocks at 20+m/s (report tool for SE appears)
• After splash screen you have to click the mouse a couple of times to get to the main menu since the cinematic wont play else you just have a black screen.
• Minor audio stutters which was mostly fixed with wine 4.3 but will get better as faudio gets futher development.
• Slow loading screens in the beginning due to new shaders need to be cached.

Pastebin here of logs when running and crashing into a planet that crashes the game.
https://pastebin.com/tPC8y3tK

[jarrard]

I take it that the latest proton beta isn't wine4.3 yet? which is why it won't work via steam directly?

[FurretUber]

I managed to make Space Engineers working. It is definitively not on a good shape, but it works. I had to:

1. Install dotnet472 on Space Engineers WINEPREFIX;
2. Build FAudio with xWMA support and libraries on non-default directories. This FAudio build must work with Megadimension Neptunia VIIR;
3. Make the built libFAudio.so be used for Space Engineers, be replacing the Proton one from lib64 or LD_PRELOAD;
4. Make sure video drivers support Transform Feedback, as Mesa 19.1.0-devel for Intel Gen9;
5. Be sure the built FAudio library built WILL NOT work! It can't find the needed libraries when starting Space Engineers;
6. Space Engineers should work but with no sound.

There are a few bugs related to graphics as opening video that does not load, on edges that effect because of helmet is buggy, even then it is great considering the GPU is an Intel HD Graphics 520 and had bugs on Windows 10 until very recently.

A lot of bugs regarding terrain generation are happening, all planets and moons are hellish landscapes.

Images:

[jarrard]

I sort of got it working but fps was real slow at menu (never bothered to play) and audio is crackling. I used https://github.com/Kron4ek/FAudio-Builds but perhaps it failed to install correctly.

EDIT: Didn't install faudio this time around, and no sound so I must have installed it correctly. Perhaps the main menu just does that because it works but as you point out, the terrain generation is completely messed up.

[Maltahl]

If you install via Lutris ( yeah i know ) It has a tkg build of Wine 4.4 with F-Audio that works wonders.

…

On Wed, Mar 20, 2019 at 3:25 AM jarrard ***@***.***> wrote: I sort of got it working but fps was real slow at menu (never bothered to play) and audio is crackling. I used https://github.com/Kron4ek/FAudio-Builds but perhaps it failed to install correctly. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1792 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHuHtRix32b6V_NKrATqj1t79SVRJY1Kks5vYZwdgaJpZM4XyGNi> .

[MagicRB]

I'll try and report my findings, it's a shame you can't download wine builds from lutris, without lutris

…

On Sun, Mar 24, 2019, 15:09 Maltahl ***@***.***> wrote: If you install via Lutris ( yeah i know ) It has a tkg build of Wine 4.4 with F-Audio that works wonders. On Wed, Mar 20, 2019 at 3:25 AM jarrard ***@***.***> wrote: > I sort of got it working but fps was real slow at menu (never bothered to > play) and audio is crackling. I used > https://github.com/Kron4ek/FAudio-Builds but perhaps it failed to install > correctly. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #1792 (comment) >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AHuHtRix32b6V_NKrATqj1t79SVRJY1Kks5vYZwdgaJpZM4XyGNi > > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1792 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHonVxCEiLofIF2Jsbrz-HZMdIWpKfgyks5vZ4c2gaJpZM4XyGNi> .

[jarrard]

Copied wine4.4 faudio protonified into my custom steam compat folder, reinstalled game and dotnet472, loaded up, no audio.
Game looks like it might run better but it has this stuttering going on, maybe the non functional audio is to blame.
Anyway didn't seem to fix my audio issue, probably need to install precompiled bins from somewhere into the custom proton folder, I'm on arch so likely ones compiled on other distros won't work.

EDIT: I built custom faudio with ffmpeg support, still no luck with sound, probably doing something wrong, shrug. Anyway game is unplayable IMO, all planet bases maps don't work/broken, has stuttering & crashing.. Maybe one day.

[Sveske-Juice]

@Shijikori The following is from the linux chat in the keenswh discord server:

SE install guide, mainly for ubuntu based distros.
install SE using proton 5.0-10, you wont need to uninstall SE if you need to redo the entire process
(you may need to redo the entire process if it doesnt work with proton 8 or experimental at the end)
the point of this is to install dotnet48, which requires dotnet40. dotnet40 doesn't get along with recent proton...
proton 5.0-10 files can be edited/added to, after that version they can not be.
so you have to create the prefix with old proton, install dotnet, then switch to proton 8 or experimental.

• Install winetricks
• Install protontricks

U can try using protontricks to just install dotnet48 for space engineers, but if it doesn't work try this:

The Proton Dance

as an additonal step if dotnet48 alone doesnt help, you can use dotnet472 before dotnet48, but after dotnet472 you will have to manually locate the
file mscoree.dll copy it out safe and out it back in the same location after you install dotnet48, as for some reason, the dotnet48 installer
removes that file which is needed for SE.

delete the `244850` prefix folder (after copying saves/BPs out).
set your steam proton to 5.0-10 (not 5.13-6).
start the game once (it doesnt have to work).
THEN run protontricks line or winetricks line (env WINEPREFIX=<your space engineers pfx directory> sh winetricks --force -q dotnet48).
note: you will need to run this from the directory that you placed winetricks or protontricks app in.
for manual installation (not using apt repository version) of protontricks/winetricks, you will need to do the above line from that directory.
start the game again (it doesnt have to work).
reboot system.
then set steam proton to 8, or experimental.
run game and play

[Shijikori]

amazingly, this works. though it runs much less smoothly. there's micro stutters all around. better than not being able to play.

scratch that, it might have not loaded the shaders or something, it runs super smooth now it's impressive. just as good as on Windows. Thanks a lot. This is a decent bit more straight forward than what I've found looking around.

To summarize what I've done :

1. Run the game once with Proton 5.0-10 (fresh prefix, deleted any pre-existing prefix for the game)
2. Install dotnet48 using protontrick (protontricks 244850 --force -q dotnet48) and made sure to read the output to change the Windows version when requested (XP for the first request, 7 for the subsequent ones).
3. Changed proton version to Experimental
4. Run the game once, it might run like shit but it will work.
5. Run the game again, it should work better.

Observed caveat : sometimes it will still crash on login to a server... but it seems to semi-reliably connect.

[Shijikori]

After playing for a while, this workaround, while it does work, seems to have introduced significant instability. The game can crash randomly and after crashing a certain amount of times, it will simply fail to run and constantly crash on startup. Those problems were not present when solely using Proton Experimental without the workaround, though dotnet48 obviously can't be installed.

[erlking]

latest Proton Experimental and e.g. GE-Proton8-25 gives a version missmatch error in Space Engineers joining a dedicated server. Proton 8.0-4 and GE-Proton8-22 and 23 works.
generally many crashes at startup, once you are ingame it works fine though.

[Shijikori]

The SharpDX update broke sound. I no longer have any sound since the update. I ran sound tests in winecfg, it doesn't seem to be a problem with Proton Experimental, at least not wine.

[josh0x10c]

Having the same issue with sound. Reverted to a previous version and sound was working again so it has to be the SharpDX update. I have no idea how to work around this issue at the moment or what caused it specifically so I will suffer in silence until it is fixed. In addition to that I have the same issue as the comment above it as well with the server/client version mismatch on anything above the stated Proton versions.

[alasky17]

@josh0x10c @erlking We pushed a fix that we had hoped would resolve the server failures. Just to confirm - you are able to get into the dedicated server on Proton 8.0-5rc (which can be selected as a beta from the Proton 8.0 tool) and not current Proton Experimental (20240111c)? Could you please grab logs of the server failure on experimental and the server successfully connecting on Proton 8.0 with PROTON_LOG=+steam,+steamclient,+wininet,+winhttp,+winsock,+iphlpapi,+nsi,+bcrypt,+secur32 %command%?

[Teddy-Kun]

When I try to join my friends session online the game crashes with the following error log.
To my untrained and unknowing eye, this seems to be the issue.
15115.368:0128:03f4:warn:seh:handle_syscall_fault backtrace: --- Exception 0xc0000005 at 0x7c0dac41f702: /run/host/usr/share/steam/compatibilitytools.d/proton-ge-custom/files/bin/../lib64/wine/x86_64-unix/ntdll.so + 0x4a702.

The exact point it crashes at is the following:
Join a friend, game loads, get to the spawn point selection and when choosing a spawn it will crash. On subsequent runs (I assume if the game remembers what was chosen) it will crash immediately.

steam-244850.log

[alasky17]

@Teddy-Kun I'm specifically looking into regressive behavior with experimental vs Proton 8.0-stable. Assuming that you are not getting the same crash with Proton 8.0-4/5, could you please get a log of the crash with the official Proton - Experimental release and a separate log of the game successfully loading with 8.0-4 or 5rc instead? Please also add the extra logging channels - PROTON_LOG=+steam,+steamclient,+wininet,+winhttp,+winsock,+iphlpapi,+nsi,+bcrypt,+secur32 %command%

[Shijikori]

The game will crash when joining a server using Proton 8.0-4. I've been getting it to work with the workaround of setting up the prefix in Proton 5.0 and installing dotnet48 before going back to Proton 8.0 or Experimental.

[erlking]

@alasky17

i can confirm that. 8.0 RC5 is fine, experimental gives version missmatch error. attached the logs.
protonlogs.zip

[erlking]

another topic, i encounter frequent "random" crashes, often SE directly crashes after launching, you re-start it several times then it works for a while.
and ingame it crashes often too. (official dedicated server, working on a larger ship e.g. completely random things, opening G menu, setting up groups, welding/grinding,.. )
does it make sense getting a Proton Log for these issues to?

[Shijikori]

i can confirm that. 8.0 RC5 is fine

do you need to do the workaround for dotnet48 or does it just work with 8.0 RC5?

[alasky17]

@erlking Thank you for the logs! I have another thing for you to try in order to try to narrow this down. Could you see if putting the lsteamclient.dll from 8.0-5 into the Proton - Experimental build fixes the error?
cp -f ~/.steam/steam/steamapps/common/Proton 8.0/dist/lib64/wine/x86_64-unix/lsteamclient.dll.so ~/.steam/steam/steamapps/common/Proton - Experimental/files/lib64/wine/x86_64-unix/.
After testing, you can delete the file and then run "verify integrity of files" on your Proton - Experimental folder to reinstall the original version.

I also have a few more questions to try to reproduce locally - @erlking @josh0x10c

1. Are you using any workarounds like installing dotnet48 into the prefix?
2. Is there any publicly available server that I could test to reproduce the same problem? I have been assuming that you are using some private server(s) and I don't current have one set up which makes it hard to investigate locally. Any suggestions here on how I could try to reproduce more easily are greatly appreciated :) Unfortunately the logs were not enough to blindly guess at the problem :(

[erlking]

@alasky17
yes, replacing the file in proton exp fixes proton exp too, can join public server with it. (it also fixes Proton-GE-27 btw.)

1. i for sure created the prefix in 5.10 and installed .NET 4.8 and i think also vcredist19. (not sure about other things) - without .net 4.8 G menu and some other things like scenario tab were really slow.
2. yes, i'm on official server (search for Keen servers (i'm on DE 6 but this is usually really crowded) - they are vanilla, unmodded and as official as it gets.

[alasky17]

@erlking Interesting - fwiw I just tried with my non-modded prefix and I didn't get a crash on experimental when getting into the exact server you mentioned (I got lucky and there was space).

And thank you for the details! I also think I figured out why I wasn't seeing the failure. In my testing, the server mismatch happens when you click "Continue game" from the main menu, but not when you go into "Join Game" and manually select the server again. Hopefully we can get to the bottom of the regression now that I figured out how to repro locally - thank you for reporting :)

[alasky17]

@erlking This should be fixed in experimental-bleeding-edge. Please let me know if you see any remaining regressive behavior surrounding server connection (or anything else, but that is more likely right now) :)

[Zackey]

Currently getting server miss-match errors on proton latest bleeding edge trying to join Skunk works, a variant of the keen star server "stone industries"

Also, multiple people in my group are just crashing when trying to launch or enter a multiplayer server.

[josh0x10c]

The issue with the mismatch seems to be resolved on the current bleeding-edge. Still get frequent crashes however and I will attach the last couple thousand lines (because it is 300MB) from the Proton log using the
PROTON_LOG=+steam,+steamclient,+wininet,+winhttp,+winsock,+iphlpapi,+nsi,+bcrypt,+secur32 %command%?"
from above. I can play for a while usually but sometimes it just crashes nonstop seemingly randomly. If someone would like for me to do further logging with different arguments please let me know.
steam-244850-latest2000lines.log

Edit: Just realized that the last file was with the plugin loader enabled, this next one is without it but has the same issue.
steam-244850-latest2000lines.log

[slashgob]

Been having sound issues for a while. - intermittent music, no interface sounds etc. i found this post over on the steam forums which fixed it for me. Apparently the XAudio dll shipped with Proton is broken and replacing it with the Microsoft signed version fixes the issue. This worked for me...

https://steamcommunity.com/app/244850/discussions/0/4206993639697096038/

[GI3JMC]

Space Engineers using the current 9.0-1 Proton, or the experimental version runs reasonably well, but has an issue with the Mono .NET replacement that is used. A random time after starting a game, or loading an existing save, the players movement will slow dramatically and the simulation rate will drop to around 40% of normal.

After waiting for a period in a control station/seat/cryopod/etc the game may return to it's normal simulation speed, or may require a restart.

This behaviour is not present when playing in a prefix that has dotnet48 forcibly installed by either winetricks or protontricks.

Other aspects of the game work normally where the player can place blocks, adjust block settings, move the camera, etc, but moving the player or a player-controlled vessel is exceptionally slow.

[https://gist.github.com/GI3JMC/38a8d9ef8374f4f5802ac22e55142eab](system details)

[LtSich]

I fully agree on that !
I restart playing few days ago, but I didn't want to mess with protontricks (because most of the time installing dotnet48 is a nightmare) and my game work exactly like you say !
I would add that playing without experimental mod is far better, but the game feel really to empty without that.. Maybe with the next "pve update" we will be able to play without experimental mode...

[josh0x10c]

Been having sound issues for a while. - intermittent music, no interface sounds etc. i found this post over on the steam forums which fixed it for me. Apparently the XAudio dll shipped with Proton is broken and replacing it with the Microsoft signed version fixes the issue. This worked for me...

https://steamcommunity.com/app/244850/discussions/0/4206993639697096038/

That fix works for me as well with the caveat that it causes all system sound to stop working if someone in-game is talking in voice chat. The sound goes mute on the entire system and there is a high pitched tone that I hear. Audio resumes working the moment the other person stops talking. For now I have disabled voice chat. It also appears I have to have dotnet48 installed in order to join modded servers or at least the ones I have tried to connect to otherwise it never connects or if it does it will be unplayable and laggy. For the most part the game is playable at least. There are infrequent random seeming crashes and recently I have seen crashes where it states "Graphics device driver has crashed" even though they most certainly have not.

[alasky17]

@josh0x10c @slashgob If you could describe exactly which sounds weren't working and get fixed with native xaudio dll, that would be greatly appreciated so that we can try to improve that :)

@josh0x10c If you have any specific server names that required native .net, that would also be greatly appreciated :)

I've been running into a wall trying to improve support for the game because most of the bugs now seem tied to specific mods or sets of mods 😅

[josh0x10c]

@alasky17 It seemed to be the music in the menu, which I muted anyways, and any UI sounds in any menu. I think interaction sounds as well, not sure on that one as I haven't played without this fix in a while. Occasionally you could hear a single sound get through but it was rare. Doing the xaudio fix does break voice chat though for some reason as I stated in my last comment.

As for servers I know that the SkunkWorks server is one of them, you can join the lobby but not one of the actual servers. That and Draconis Expanse was another one I had tried and couldn't join until after installing dotnet48. If you do manage to get in the performance was awful until you installed dotnet48.

[MegaShinySnivy]

I want to note that Dotnet48 still has major performance issues, though not as bad as dotnet mono. Mono is 15% performance while 48 is about half if I compare between windows to linux.

[creeloper27]

Nowadays using Proton 9 the game runs well enough for me, both when using 1xxx Nvidia and 5xxx AMD GPUs, the only huge problem left happens when hosting a server, I can join any server hosted on Windows fine, even when using mods, but if I try joining a Linux server be it hosted from a Client or with the Dedicated Server app the game crashes as seen as you reach 100% loading or sometimes when you go past that as soon as you try to spawn, it's very unfortunate as for the rest it's quite usable already, this is the last big problem to fix personally.

[SpookySkeletons]

Post a proton log with the crash in it or the issue can't be helped

[alasky17]

@creeloper27 If you know an example Linux server name for testing purposes, that would be very helpful too (as well as a log).