Proton: Space Engineers - 244850

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.

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

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.

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.

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

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.

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.

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

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.

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

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.

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.

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.

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'

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.

@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

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.

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.

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.

@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.

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?

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

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

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:

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.

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 notifications@github.com 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
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-474658732,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHuHtRix32b6V_NKrATqj1t79SVRJY1Kks5vYZwdgaJpZM4XyGNi
.

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 notifications@github.com 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 notifications@github.com 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
<
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-474658732
,
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
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-475963063,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHonVxCEiLofIF2Jsbrz-HZMdIWpKfgyks5vZ4c2gaJpZM4XyGNi
.

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.

I doubt that bins from other distros wont work. They will, just install
wine the arch way to get all the dependencies and that should do it.

On Sun, Mar 24, 2019, 23:59 jarrard notifications@github.com wrote:

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.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-476010132,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHonV0PNKjPrMbFLzUDFBzbXqp2ZjOUNks5vaANBgaJpZM4XyGNi
.

Yeah it's just a install issue at my end, I also seem to only be able to build 64bit libs, can't see the 32bit ones unless their the same file (no idea).

When I copied my libFAudio.so file to the proton_wine custom folder and loaded SE it just set all my volume settings to zero, and would not save them if raises so something is a miss.

BUT like I said, the game has major issues under Linux, so not like I could realistically play atm unless its pure space survival with no moons or planets!

The main problem is terrain generation. I'm puzzled as to how such hellish
landscapes can be created

On Mon, Mar 25, 2019, 06:51 jarrard notifications@github.com wrote:

Yeah it's just a install issue at my end, I also seem to only be able to
build 64bit libs, can't see the 32bit ones unless their the same file (no
idea).

When I copied my libFAudio.so file to the proton_wine custom folder and
loaded SE it just set all my volume settings to zero, and would not save
them if raises so something is a miss.

BUT like I said, the game has major issues atm so not like I could
realistically play atm unless its pure space survival with no moons or
planets!

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-476063606,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHonVxB8URy1FGMFsPoU2eRKq1dVFeg6ks5vaGP8gaJpZM4XyGNi
.

Yeah if someone can figure that out it be great,.
What I'm thinking is the game is detecting maybe limited memory or limited cpu cores hence it can't do the job.

If you look in the in-game error log it says the terrain is too complex etc in those instances, check it out.

yeah, wine with reporting available memory, cores, and stuff isn't great.

On Mon, Mar 25, 2019 at 6:55 AM jarrard notifications@github.com wrote:

Yeah if someone can figure that out it be great,.
What I'm thinking is the game is detecting maybe limited memory or limited
cpu cores hence it can't do the job.

If you look in the in-game error log it says the terrain is too complex
etc in those instances, check it out.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-476064274,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHonV9U7V6QwDB69qwGpkGR_avGmUh7Jks5vaGTdgaJpZM4XyGNi
.

I have a i7 4790k, 16 GB of RAM and GTX 1080. The game runs using the lutris script with wine 4.4, FAudio and DXVK and performance is good, 1440p@60FPS however:

• planet maps don't work neither in single or multiplayer
• music is absent
• there is a periodic, very regular stuttering while playing that is very annoying
• the game freezes 30-60 minutes into play, seemingly at random, and then crashes

I don't think it's playable at this stage

I may have found out why the terrain is generated improperly. It appears that the heightmaps used by the game are not being read properly by the game or wine/proton or something… I got the terrain to generate on the Alien Planet by opening the terrain heightmaps( the files named front.png back.png left.png right.png up.png down.png Located at ~/SpaceEngineers/Content/Data/PlanetDataFiles/Alien/) and without modifying the actual image saved them with new options. I used Gimp version 2.10.6 to overwrite the files with the following Options.

Strangely when using the spectator cam to go to the local moon(which I did not apply the fix to) the game just froze instead of generating the spiking terrain.
The Following are screenshots from the working game:

My knowledge about this is very limited, so if someone could figure out what is going on here it would be much appreciated.

Note: My game constantly crashed while trying these fixes, but the times I was able to get into the game did not crash during the play session, with the exception of when I went to the moon and the game froze. After that I could not get the game to load the save game or start a new world without a lockup. Once I deleted and recreated the prefix the game started working again.

Very nice trouble shooting there. So we need proton/wine to look into why it can't read these PNG files correctly. Could be related to a nasty bug in wine itself not being able to read specific settings for those files!

I wish this could be bumped to a dev to be looked into, really would love this game to work better. The height-map issue is not the only problem sadly, we have sound stutter and frame stutter to deal with next, but that could be partially related.

@Linux74656
How could the png stuff possibly interpret the png wrong?

That would explain the crazy high-low thing going on... Perhaps it's just being truncated from 16 to an 8 bit int...

What happens with 8bpc vs 16 bpc & compression off vs max compression?

Might be worth asking for a quick fix from the KSH devs as this doesn't seem to impact the base game any by making this tweak. However it will be worth fixing this in upstream wine now that we know the issue.

Most importantly for his fix what png lib does wine use?

I am not sure what png lib wine uses, but if you install MS Windows Imaging Component (windowscodecs) with winetricks into the games prefix; most of the games images(icons, thumbnails... etc) are pink and the terrain renders completely flat.

I tried the suggestion from @SpookySkeletons Attached are images from the compressed 8bpc GRAY and 16bpc Gray (Uncompressed as compressed made no difference in either case). It appears that the 16bpc is performing in a similar way to the original images provided with the game.

Strangely when testing the 16bpc Gray(both compressed and not compressed) the game would not start the Alien Planet scenario, it kept freezing while loading. I got around this by starting and Empty World scenario in creative mode and spawning the planet.
After this I decided to compare the original file to the modified ones. I used a tool called tweakpng (windows only but runs in wine without issue) to look at the header data of both the png provided with the game and the one I modified with 8bpc.
The file that comes with space engineers does indeed use 16bcp grayscale.

While the modified one, as expected, uses 8bcp grayscale.

I think they(Keen Software House) are using 16bcp because it would allow for more gray scale color depth and perhaps provide smoother terrain, although without being able to test 16bcp terrain generation in the game i can not say for certain.

So does the game load up with just WINED3D (dxvk disabled) and does it read 16bcp terrain correctly then? If that can't be done then perhaps DXVK can be tested under windows10 to see if it's the culprit or if Wine itself is to blame.

Its important to know if DXVK or WINE team should get the bug report.

The game crashes when using DirectX(PROTON_USE_WINED3D=1) with an error message.

When i click on the empty box before clicking on the error message, i can hear the Space Engineers main menu music and the button sound.

If someone can get DXVK to run this game in Windows that would be great. In the mean time i will continue to try to get PROTON_USE_WINED3D=1 to return positive results.

Try spoofing to AMD custom settings flag which I think is possible with wines regedit or variables somewhere using vendor and product ids. There are a few tricks that can be done. (I can't remember them off hand atm)

I think Keen chose 16 bit specifically to fit the height gradient as closely to the 2048x2048 image as possible, compared to the 256 gradations of 8 bit.

I'm not seeing any lack of precision in the height mapping though by using this workaround... Perhaps the engine itself expects a downsample from 16 to 8 in the first place or one is implicitly applied that causes this in the first place.
Keen seems to be applying precision in excess to a process which throws out the extra precision.

Either way if we could get in contact with keen and ask if it's a good idea to ship 8 bit heightmaps it might make for a nice band-aid for inching toward proton support. And very definitely upstream a real fix for Proton as this is an issue with wine itself...

@jarrard I tried setting the card to an AMD RX480 VideoPciDeviceID to 10de(hex) and the VideoPciVendorID to 1002(hex) and still got the same error. I was however able to start the game by running the SpaceEngineers.exe with wine 4.5 and d3d11_43 installed. The game got to the main menu but, it locks up when trying to load a scenario.

@SpookySkeletons I will send an Email to Keen support, with a link to this thread and see if i get a useful response. Maybe we will get lucky and they will look into it.

In the mean time i will keep trying to get Space Engineers to run with d3d11.

I got WINED3D to work but not through steam or proton. I deleted the old prefix and created a new one with steam. I then installed the entire dx11 redist from Microsoft, as well as the usual dotnet472 and xact. I also had to force Space Engineers to run in windowed mode as it was constantly freezing and crashing otherwise. I was able to get past the loading freeze by starting a new empty world instead of straight onto the Alien planet. I used the spawn menu to add the alien planet in for both worlds.(Results in pictures below)

The 16bpc did not work in WINED3D, and the 8bpc still did.

EDIT: I was looking at WineHQ for similar issues, when i stumbled across this bug report:
https://bugs.winehq.org/show_bug.cgi?id=46558
Comment 8 References this thread, and the temporary fix, so they are definitely aware of what is going on. Let's hope they can figure it out! :smile:

As for the stuttering issue I have been trying various things to see if i can narrow it down.
The stuttering issue exist in both WINED3D and in DXVK (I noticed DXVK uses fewer CPU resources compared to wines D3D implementation). And the issue seems to take place at the same intervals no matter what graphics settings I use.

I have tried various CPU settings with the following results.
I set my cpu(i7 4770k) to only start with one core(used bios to disable all but one core and no hyper-threading). The game took longer to load but once in the world, the stuttering seemed unaffected.

I then underclocked (4.2Ghz is what i usually run it at) my cpu to 2.5Ghz (with all cores and hyper-threading re-enabled). The stutter still happened at the same same interval, but the duration of the stutter was noticeably worse, rather than the stutter lasting a fraction of a second, it seemed to last a second or more.

So I then overclocked my cpu to 4.5Ghz and the stutter still took place at the same interval, but was marginally less noticeable than the 4.2Ghz speeds it normally runs at.

So could this be a game update thread issue? Is the game performing calculations at set intervals and overwhelming the cpu? If so what would cause this to be noticeable on Linux/wine/proton, compared to unnoticeable on windows?

I contacted Keen support and told them about the issues we are experiencing. I gave them the three main problems to getting this working on Linux (the terrain, the stutter, and the audio), and explained what the issue is with the terrain. I also linked them this thread. They responded with something along the lines of they are keeping an eye on Linux, but are not planning any changes at the moment.I think for the mean time we are on our own.

Maybe you can record a apitrace and post it over at the DXVK forum? might still be fixable at DXVK's end you think?

OK i opened an issue and referenced this thread.

UPDATE: It is not DXVK causing the issue. Which means our problem is most likely not related to the graphics.

Quick note for anyone wanting to get rid of the annoying black screen and, the need to click to get the game to start the main menu: you can rename(just add .old to the end of the file) the file here :~SpaceEngineers/Content/Videos/KSH.wmv and the game starts more normally. I even get some startup images when the game starts full screen.

Interesting development: Now that DXVK and graphics issues have been ruled out, i have turned my focus to the audio. And I think I may be onto something.

If you convert the main menu music (~/SpaceEngineers/Content/Audio/MUS/se_mainmenu1.xwm) to an mp3 format(but make sure the file name and extension are the same as the original, IE se_mainmenu1.xwm) then there is no lag in the main menu, although the music does not play. If you simply delete the file the lag in the menu still exist and the does not play. So if you give the game engine a sound file type it can not recognize it seems the menu lag issue is solved.

I tried to see if this fixed the stutter in game, but when I convert the other music the same way, the game enters an infinite loading loop when trying to start a game. I also tried disabling sound in wine and in the game, but that had no affect in either case.

If you open the original se_mainmenu1.xwm in VLC, the same kind of stutter happens as in the game.

isn't XWM files some crappy microsoft file format?

Yeah fallout4/skyrim, all the games that have had issues in the past with audio used this format of xaudio2.

I have had extensive issues with Fallout 4 especially with audio. But it has gotten better over time, and i don't see the same kind of stutter in Fallout 4 as I do in SpaceEngineers. Now the question is... Why is this seemingly causing an issue in Space Engineers while not having the same issue in Fallout 4?

Have you tried ditching FAudio and just installing MS xact or xaudio whatever it is via winetricks? that is what I use to do to get fallout4 audio working (it would eventually cut out)

Might be worth a try.

I am currently using xact for space engineers. I was never able to get space engineers to load just using Faudio(Winetricks or Kron4eks customs builds.)
I just checked, fallout 4 main menu music dose not have any stuttering in game, but if you extract the MUS_MainTheme.xwm from Fallout4-Sounds.ba2, and play it with vlc, the same audio stutter that is in space engineers is present.

I am no longer sure if the in game stutter is an audio issue. After getting to far too frustrated to deal with the audio, I instead tried to go back and see in what version of the game the issue started. The in game stutter exist all the back to version1.172(which is as far back as the steam beta tab goes). But the audio issue on the main menu does not exist in this version. In fact the main menu audio issue only started in version 1.188 of the game. But the in game stutter is present in all versions available in the betas tab.

Here is something pertaining to Space Engineers, hopefully it will entertain you. While we wait for a solution.
https://gist.github.com/Linux74656/6093bd3fe9457f29f2f544681a262572

The voxel bug is a windowscodecs bug in wine. I've described the bug and attached a fixing patch at https://bugs.winehq.org/show_bug.cgi?id=46558. Tested working for me on steam under wine. I presume Proton would work the same as well with a updated windowscodecs wine-dll.

Yes but what about the stutters and sound distortion issues?

@jarrard works for me using https://github.com/Kron4ek/FAudio-Builds -- I assume the bundled in wine and proton versions are too old.

@kainz do you have anything left malfunctioning in the game with the recent FAudio builds and your windowscodecs patch? Or is it working well?

@fazo96 shadows dont work well, so I play with those disabled, and I get occasional dotnet crashes still.

So still a while to go.
I hope future wine versions can look at resolving these remaining issues.
Its good to have games like this that clearly point out problems in the wine compat layer, hard cases but fixable.

Here's a precompiled windowscodecs.dll.so with the patch from the linked bug. Drop this into your Proton 4.2/dist/wine/lib64 directory overwriting the existing file.

There is a side effect: scenario and savegame preview images don't load, they're just magenta fill. It's entirely possible this is due to an oversight on my part when building it. I haven't noticed any other ill effects.

windowscodecs.zip

Game doesn't start via steam for me. Do you still need .NET 472 to be installed with latest proton? also is faudio still outdated with proton?

Is that what prevents it from loading? why doesn't Faudio have WMV support
enabled by default? is there negative side effects?

Again is .net still needed?

On Fri, 26 Apr 2019 at 16:57, lucifertdark notifications@github.com wrote:

I build Faudio from source to add the wmv support, it's really easy &
quick.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-486956240,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEE7DLTBNX7CLOZAPUK3FYDPSKVFNANCNFSM4F6IMNRA
.

--
-- -- -- -- -- -- --
I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

You still need dotnet472 yes. I needed to specify -q when installing it via protontricks.

The latest FAudio build isn't working for me either, just crashes all the same. xact seems to fix it ish but no sound.

And I'm also seeing that periodic stutter.

This is only partially related, but is anyone experiencing crackling with
faudio? Restarting pulseaudio fixes it for me. This happens with Fallout4,
I want to know if something similar happens with SE. Also if I open and
close FO4 multiple times without restarting pulse it gets worse.

On Fri, Apr 26, 2019, 10:27 roothorick notifications@github.com wrote:

You still need dotnet472 yes. I needed to specify -q when installing it
via protontricks.

The latest FAudio build isn't working for me either, just crashes all the
same. xact seems to fix it ish but no sound.

And I'm also seeing that periodic stutter.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-486973608,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB5COVZBOCGLBILENE4RB3DPSK4GRANCNFSM4F6IMNRA
.

periodic stutter, yeah until that is resolved I'm not touching this.

Is that what prevents it from loading? why doesn't Faudio have WMV support enabled by default? is there negative side effects? Again is .net still needed?
…
On Fri, 26 Apr 2019 at 16:57, lucifertdark @.*> wrote: I build Faudio from source to add the wmv support, it's really easy & quick. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1792 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AEE7DLTBNX7CLOZAPUK3FYDPSKVFNANCNFSM4F6IMNRA .
-- -- -- -- -- -- -- -- I've noticed that when I strive to achieve and succeed, I distance myself from the moment.

Ignore what I wrote (deleted now) I'm not sure what I was blathering on about.

I can't even get Faudio working with this, neither self compiled or the Kron4eks dll's as both crash with a "no associated application" error. Xaudio native works but the stutter is unbearable and seems to affect graphics performance also, upping pulseaudio latency does help a bit though.

Also tried the windowscodecs fix linked above for the ground, while it does fix the issue I get pink skyboxes.

Sounds like you're missing dotnet472. That's still required.

On May 6, 2019 2:57:47 AM CDT, fls2018 notifications@github.com wrote:

I can't even get Faudio working with this, neither self compiled or the
Kron4eks dll's as both crash with a "no associated application" error.
Xaudio native works but the stutter is unbearable and seems to affect
graphics performance also, upping pulseaudio latency does help a bit
though.

Also tried the windowscodecs fix linked above for the ground, while it
does fix the issue I get pink skyboxes.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-489537313

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Sounds like you're missing dotnet472. That's still required.

No I got dotnet472 installed correctly, the game wouldn't even run with xaudio set to native otherwise.

Issue is Faudio enabled the game crashes after the splash screen. Using standard xaudio it runs but with the stutter.

Running Space Engineer now works with minor audio glitches and small stutters but no more graphic errors and draw errors.

I had to change to Wine 4.8 with DXVK 1.2 after using the Lutris installer

Freezes do happen if you hit ground/ships/rocks with 30 m/s or faster
Log of crash including system info and driver info here:
https://pastebin.com/yTV7FcBa

Hello @Maltahl, this commit should help the GPU hangs on impact. Please retest with mesa 19.0.4 or mesa git master.

Proton 4.2-4 has a new terrain issue, the base in mission 3 of the first scenario is floating in the air.

If you're able to test does it happen on wine 4.7 or wine 4.8?

On May 14, 2019 4:13:59 PM CDT, fls2018 notifications@github.com wrote:

Proton 4.2-4 has a new terrain issue, the base in mission 3 of the
first scenario is floating in the air.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-492412089

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

If you're able to test does it happen on wine 4.7 or wine 4.8?
…
On May 14, 2019 4:13:59 PM CDT, fls2018 @.*> wrote: Proton 4.2-4 has a new terrain issue, the base in mission 3 of the first scenario is floating in the air. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1792 (comment)
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Unsure, will have to compile a fresh TKG proton however I'm basing my report on Proton 4.2-4 released today which was meant to fix these terrain issues. So far it's only fixed the spiky ground on mission 2.

Also note I don't get this issue with the wincodecs fix posted above in this thread (only the pink sky/thumbnails).

Unfortunately even after renaming the file here:~SpaceEngineers/Content/Videos/KSH.wmv (just add .old to the end of the file) I still crash after the Space Engineers logo.

Manjaro
Kernel: 5.0.9-2
Nvidia driver: 418.56

https://gist.github.com/Evernow/6c6b02c027a4df3cb114037460b73ff2

Unfortunately even after renaming the file here:~SpaceEngineers/Content/Videos/KSH.wmv (just add .old to the end of the file) I still crash after the Space Engineers logo.

Manjaro
Kernel: 5.0.9-2
Nvidia driver: 418.56

https://gist.github.com/Evernow/6c6b02c027a4df3cb114037460b73ff2

I confirm it, the game crashes immediately after start.
OS: Archlinux
NVidia drivers: 418.74

It looks like 4.2-4 fixed the corrupt terrain issue. Shouldn't need my special DLL anymore. dotnet472 and xact still required.

The stutter is still there. I'm fairly certain it's not audio-related; it's too irregular for that. It seems to get worse as you approach voxels (planets/asteroids) and improve a bit if you sit still. My gut says locking/synchronization related to streaming. I wouldn't know where to begin chasing that down.

It looks like 4.2-4 fixed the corrupt terrain issue. Shouldn't need my special DLL anymore. dotnet472 and xact still required.

The stutter is still there. I'm fairly certain it's _not_ audio-related; it's too irregular for that. It seems to get worse as you approach voxels (planets/asteroids) and improve a bit if you sit still. My gut says locking/synchronization related to streaming. I wouldn't know where to _begin_ chasing that down.

Can you try Mission 3 "Ruined Camp" of scenario "The First Jump"? The first planet in mission 2 might not be spiky anymore but it hasn't completely fixed the issue here.

@FurretUber made a guide to getting the game to run a few months ago in this thread, but has that changed since? I.e. replace faudio with xact? Is protontricks required or can installing dotnet472 through normal winetricks work? (feeding it the right WINEPREFIX?)
I tried to follow those original instructions with 4.2-4 and was still left with the black splash screen crash.

dotnet472 and xact can be installed normally via winetricks, use the --unattended flag (or -q), I just use sppfx scripts.

PROTON_PATH="$HOME/.steam/steam/steamapps/common/Proton 4.2/" sppfx 275850 winetricks --unattended dotnet472 xact

I tried running WINEPREFIX="/home/[user]/.steam/steam/steamapps/compatdata/244850/pfx/" winetricks -q dotnet472 xact
But then the game still does not launch, in winxp mode (that winetricks sets it to) or win7. I have the most recent release of winetricks

your scrambling your prefix if you do it that way, which is why I use SPPFX

Use the latest protontricks. Using winetricks directly can cause issues because it may invoke the wrong version of Wine. Recent protontricks sets up the environment so winetricks will be using Proton bundled Wine.

protontricks 244850 -q dotnet472 xact

(This takes a very long time; be patient.)

Yeah basically what I was saying. SPPFX is a set of scripts that is like protontricks, but will work with any other commands also.

If you only ever intend to use tricks scripts then protontricks is fine but sometimes I want to manually install something or run winreg etc..

protontricks 244850 -q dotnet472 xact

By running that, and after renaming the file here:~SpaceEngineers/Content/Videos/KSH.wmv (just add .old to the end of the file) I was actually able to not only get to the main menu, but load up a game! The frame rate is actually acceptable(hitting high 90s) but the annoying part is the stuttering, making the experience far from enjoyable.

But it actually does run! And it didn't crash either, only weird issue I experienced is similar to the one fls2018 reported with the terrain! Wonderful work Valve, CodeWeavers, doitsujin and really everyone involved! We're getting so close!

Unfortunately even after renaming the file here:~SpaceEngineers/Content/Videos/KSH.wmv (just add .old to the end of the file) I still crash after the Space Engineers logo.
Manjaro
Kernel: 5.0.9-2
Nvidia driver: 418.56
https://gist.github.com/Evernow/6c6b02c027a4df3cb114037460b73ff2

I confirm it, the game crashes immediately after start.
OS: Archlinux
NVidia drivers: 418.74

Try installing protontricks and running this:

protontricks 244850 -q dotnet472 xact

Then rename the file here:~SpaceEngineers/Content/Videos/KSH.wmv (just add .old to the end of the file)

I was able to get the game to work

I:

1. Installed SE
2. Ran it once to generate the prefix
3. Ran protontricks 244850 -q dotnet472 xact
4. Renamed the KSH.wmv file
5. Tried to run SE with the play button under 4.2-4
   But the game just stays on "running" and never launches. No exe file even shows up in the task manager.

The log file is very short and has this key line in it:
313044.458:0027:0028:err:module:fixup_imports_ilonly mscoree.dll not found, IL-only binary L"SpaceEngineers.exe" cannot be loaded 313044.458:0027:0028:err:module:LdrInitializeThunk Importing dlls for L"Z:\\home\\james\\.local\\share\\Steam\\steamapps\\common\\SpaceEngineers\\Bin64\\SpaceEngineers.exe" failed, status c0000135
steam-244850.log

Sounds like .NET didn't install correctly.

What causes .NET to install incorrectly?

Winetricks has a problem with the dotnet476 verb and he 'bug workaround'. Try flagging the verb to not workaround' on wine 4.0 or newer.

On May 16, 2019 2:23:41 PM CDT, pipnina notifications@github.com wrote:

What causes .NET to install incorrectly?

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-493199360

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Unfortunately even after renaming the file here:~SpaceEngineers/Content/Videos/KSH.wmv (just add .old to the end of the file) I still crash after the Space Engineers logo.
Manjaro
Kernel: 5.0.9-2
Nvidia driver: 418.56
https://gist.github.com/Evernow/6c6b02c027a4df3cb114037460b73ff2

I confirm it, the game crashes immediately after start.
OS: Archlinux
NVidia drivers: 418.74

Try installing protontricks and running this:

protontricks 244850 -q dotnet472 xact

Then rename the file here:~SpaceEngineers/Content/Videos/KSH.wmv (just add .old to the end of the file)

I was able to get the game to work

Yes, I succeeded to run the game. I couldn't install dotnet472 without -q parameter, it gave error. But the game is still unplayable for me. FPS is too low, stuttering audio and graphic artefacts (for example, black space colored pink). I set graphic quality to low, but with the same result. My videocard is NVidia GTX 770, drivers are 418.74.

FPS is fine for me, however there's audio and graphical stuttering (every time the audio stutters the graphics do too).

(Arch linux and AMDGPU driver on Gigatebyte RX 560 4GB OC)

I have now played and tested the game for about 2 hours and found some additional bugs:

• Particle effects don't work. This includes tool effects, smoke, etc.
• Postprocessing also seems to not work
• Engineer headlights do work, but just result in a solid cone of light, no fading on the edges etc. spotlights and interior lights seem to work fine.

This is in addition to the stuttering everyone else is experiencing. None of this is game breaking, but it's bugs none the less.

What graphics engine does SE use? unity?

Space Engineers uses an in-house-developed engine called VRAGE. The same engine is used in Medieval Engineers and Miner Wars 2081.

probably explains allot, lots of non conformant hacks most, probably.

I did not needed the rename to make it work. Only the stuttering is left as an actual problem.

The menu background won't display the videos. That could be looked into, might solve other things as well.

Not sure but the game seems better now, still seems slow even though the fps is high but the big stuttering seems to be gone.

Although the fps drops a lot when saving it seems. Still needs improvements to make the experience fully playable, but it's getting there fast. Goodjob everyone!

What you did to get rid of the stuttering (which is a 100% audio related, as it's gone when I hit the mute button)? latest proton?

Hmm, all I get for a while now is this error message:

Any idea how to fix that?
I am using Proton 4.2-7 and have xact, dotnet472 installed

What you did to get rid of the stuttering (which is a 100% audio related, as it's gone when I hit the mute button)? latest proton?

I don't think I did anything, I mean the stuttering is still there, it's just much less prevalent than before, at least for me. maybe the new nvidia driver(on430.14 right now) and Proton updates?

Hello @kellerkindt, DXVK needs a working Vulkan driver stack to translate DirectX 11 to Vulkan. Does any vulkan application like vulkaninfo work?

Please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

Hello @kellerkindt, DXVK needs a working Vulkan driver stack to translate DirectX 11 to Vulkan. Does any vulkan application like vulkaninfo work?

Please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

Here you go:

vulkaninfo
steam-info

At a glance, that looks like it's fine. Please add PROTON_LOG=1 %command% to the game's launch options and drag and drop the generated $HOME/steam-244850.log into the comment box.

At a glance, that looks like it's fine. Please add PROTON_LOG=1 %command% to the game's launch options and drag and drop the generated $HOME/steam-244850.log into the comment box.

Here it is

Looks like wine-mono is having trouble with a couple variants of Mono: DllImport error loading library 'd3d11': 'Datei nicht gefunden. throughout the log.

11121.045:0025:0026:trace:module:get_load_order looking for L"C:\\windows\\system32\\d3d11.dll"
11121.045:0025:0026:trace:module:get_load_order_value got environment  for L"d3d11"
11121.046:0025:0026:warn:module:load_dll Failed to load module L"d3d11.dll"; status=c0000135

This indicates that d3d11.dll has been disabled by the WINEDLLOVERRIDES environment variable.

11121.045:0025:0026:trace:module:get_load_order looking for L"C:\\windows\\system32\\d3d11.dll"
11121.045:0025:0026:trace:module:get_load_order_value got environment  for L"d3d11"
11121.046:0025:0026:warn:module:load_dll Failed to load module L"d3d11.dll"; status=c0000135

This indicates that d3d11.dll has been disabled by the WINEDLLOVERRIDES environment variable.

Well, its not set (by me):

$ echo ">> $WINEDLLOVERRIDES <<"
>>  <<

Since the latest version of proton, I've been encountering this error message in other games. Sometimes they run still after clicking ok, such as war thunder in proton. This makes me wonder if it's a bug. I've tested proton on both arch linux, and openmandriva lx4 znver. I'm not sure if it would matter any, but I personally use a RX 560 with AMDGPU drivers... Not sure if the other commenter here uses AMD too.

I'm unable to install dotnet472.
My winetricks --version is 20190615-next.
when i try:protontricks 244850 -q dotnet472 xact It's failing on dotnet 40 with
dotnet40 install completed, but installed file (...).steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

I'm unable to install dotnet472.
My winetricks --version is 20190615-next.
when i try:protontricks 244850 -q dotnet472 xact It's failing on dotnet 40 with
dotnet40 install completed, but installed file (...).steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

I am having the exact same issue. No idea how to solve it. I'm using Ubuntu 18.04 and protontricks 1.2.2 with an AMD R9 Fury GPU.

I'm unable to install dotnet472.
My winetricks --version is 20190615-next.
when i try:protontricks 244850 -q dotnet472 xact It's failing on dotnet 40 with
dotnet40 install completed, but installed file (...).steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

I am having the exact same issue. No idea how to solve it. I'm using Ubuntu 18.04 and protontricks 1.2.2 with an AMD R9 Fury GPU.

I used Protontricks GUI with no issues, maybe try that?

I'm unable to install dotnet472.
My winetricks --version is 20190615-next.
when i try:protontricks 244850 -q dotnet472 xact It's failing on dotnet 40 with
dotnet40 install completed, but installed file (...).steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

I am having the exact same issue. No idea how to solve it. I'm using Ubuntu 18.04 and protontricks 1.2.2 with an AMD R9 Fury GPU.

I used Protontricks GUI with no issues, maybe try that?

I just tried and still getting the following error:
dotnet40 install completed, but installed file /home/username/.steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

I'm unable to install dotnet472.
My winetricks --version is 20190615-next.
when i try:protontricks 244850 -q dotnet472 xact It's failing on dotnet 40 with
dotnet40 install completed, but installed file (...).steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

I am having the exact same issue. No idea how to solve it. I'm using Ubuntu 18.04 and protontricks 1.2.2 with an AMD R9 Fury GPU.

I used Protontricks GUI with no issues, maybe try that?

I just tried and still getting the following error:
dotnet40 install completed, but installed file /home/username/.steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

What distro are you on? Maybe a package is out of date?

What distro are you on? Maybe a package is out of date?

I'm on Ubutntu 18.04. I made sure to check for updates to protontricks before running the command. As I wrote, the latest version available for me seems to be 1.2.2.

What distro are you on? Maybe a package is out of date?

I'm on Ubutntu 18.04. I made sure to check for updates to protontricks before running the command. As I wrote, the latest version available for me seems to be 1.2.2.

Go to Steam, Help, System information, select it all (CTRL + A) and then copy it all (CTRL + C) and paste it into pastebin.com if you can pls

Hi, I experience exactly the same error as @bwyan86 and @LordJABA . Here is my system information https://pastebin.com/7Ab8CY1Q

protontricks 244850 -q dotnet472 xact required a PRECISE combination of winetricks 20190310 and protontricks 1.2.2, no more no less, as then it would fail on installing dotnet40.

Planet-based worlds crash on higher than low graphics settings. Speaking of planets, the terrain is completely broken (Proton 4.2-9):

Thanks for the hint @LunaSquee . I had to run protontricks 244850 -q --force dotnet472 xact though. I cannot confirm the broken terrain on planets, though. Ingame I experience annoying short freezings/stuttering in 1-2 seconds intervalls. But this covers with the current experience of other users regarding the posts on protondb. Hopefully this will be dealt with! Looking forward to.

What distro are you on? Maybe a package is out of date?

I'm on Ubutntu 18.04. I made sure to check for updates to protontricks before running the command. As I wrote, the latest version available for me seems to be 1.2.2.

i am having the exact same issue as you, i'm on ubuntu 16.04

@EduardoGodoy did you try @LunaSquee 's suggestions with protontricks 1.2.2 and winetricks 20190310?

The terrain and shadows now working properly...

The could pass as a silver rating if we could just nail down the cause of the in-game stutter. It averages about 110-150ms on the DXVK frametime counter.
Is there some way to profile dotnet applications under wine to spot the hangup?

did someone say it was related to audio? perhaps remove all audio drivers and components/files and test again?

The game crashes immediately when the audio folder is missing.
Turning all audio settings off doesn't seem to change anything.

@fwillo If you are determined and have a few hours of time my dirty workaround was to:

• open /usr/bin/winetricks in text editor
• look for load_dotnet472()
• few lines below is a call to previous dotnet version like w_call dotnet462.
• I followed the chain and removed the 4.0 from the last one
• tried again
• it failed on some later version
• every time that happened found a download link and arguments for the installer in the winetricks script and installed it inside the wine prefix by hand. (4.0 seems to be integrated in wine?/not needed, the newer ones are needed )
• after that remove/comment call to just installed dotnet version in winetricks script and try again

After 2 or 3 hours I got space engineers working smoothly... maybe except the starting part - you will have only a blank screen, you need to wait at least ~15s and click the mouse for the menu to appear.
After that the performance is the same as in windows for me, but if I install any mods it won't work in steam offline mode- not sure if that's the game or my setup

EDIT: to be clear im running not under proton but via

lutris wine steam runner
wine version: ge-protonified-nofshack-4.9
DXVK:1.2.3

You can get proton GE for steam precompiled with 4.11 at the latest. Works with spengies.
So what you're saying is:
You used Proton's inbuilt mono for dotnet 4.0 and under but installed the Microsoft binaries for everything past that and it worked without stutter?

Could you ~zip and upload your wine bottle or~ be a little more concise on how you accomplished this?

Moderator note: Above line partially struck out because it would contain copyrighted libraries from the workaround.

@LordJABA I'm willing to try your instructions. Nevertheless, I have to agree on @SpookySkeletons notes: Your instruction are a bit foggy. Could you write a detailed list of steps in order to reproduce your workaround? Also from what I have read: shouldn't this approach work with steam and protontricks as well instead of Lutris + winetricks? The only thing you did was installing the dotnet472 without dotnet40, just to install that manually after winetricks? Looking forward to your answer.

@SpookySkeletons I'm sure I got mono turned off, despite that dotnet 4.0 installer claims that I already have never version installed and refuses to install.
@fwillo Sorry for unclear instructions- I was hesitant to even post them like that. I wandered here few days after I figured it out so no bash history or fresh memories.

will do my best to clean it up for you below assuming fresh system.

• First Install wine make sure it also installed wine32:i386 - it did for me,
• install Lutris https://lutris.net/downloads/
• In lutris click the cog near "Runners" in the top left to get to runner manager,
• Find "Wine" on the list click blue "Manage Versions" button and make sure you got ge-protonified-nofshack-4.9 on the list and enabled
• Just below "Wine" on the list should be "Wine Steam" click "Runner Options" next to it and add %command% -no-cef-sandbox in "Arguments", set the correct wine version, and mark stop steam after game exits
• Click Install Runner

It should install just fine. Now the tricky part.

Install winetricks via bash script as described here https://github.com/Winetricks/winetricks
this way you can always run update_winetricks to unf... restore your /usr/bin/winetricks

In console type
export WINEPREFIX="/home/<user>/.local/share/lutris/runners/winesteam/prefix64"
You can check it in lutris runner options
Now you are working inside the winesteam prefix

I Will use dotnet 40 as example on how to remove dependency in winetricks as we need to do that one for sure,
Make sure mono is off by typing winetricks remove_mono
Try typing winetricks dotnet472- it will try but for me it fails at the beginning trying to install 40 claiming its already up to date - this prevents winetricks from installing never ones.
So open /usr/bin/winetricks in text aditor and find "load_dotnet472"

```
load_dotnet472()
{
w_package_warn_win64

if w_workaround_wine_bug 42170 "Running un-official repacked .NET 4.7.2 setup until the official version is fixed.", 3.1; then
    # Un-official slim version. See https://repacks.net/forum/viewtopic.php?t=7
    file_package="dotNetFx472_Full_x86_x64_Slim.exe"
    w_download "https://drive.google.com/uc?export=download&id=1aLBCH0Yt2-6ROpWRBxZ01kqGMyhc_8hM&confirm" a36da041b8f46079f8e16647312d642953cde520f4a600ad5b3f4f90a23495a7 $file_package
    unattended_args="/ai /gm2"
else
    # Official version. See https://www.microsoft.com/en-us/download/details.aspx?id=53344
    w_download https://download.microsoft.com/download/6/E/4/6E48E8AB-DC00-419E-9704-06DD46E5F81D/NDP472-KB4054530-x86-x64-AllOS-ENU.exe c908f0a5bea4be282e35acba307d0061b71b8b66ca9894943d3cbb53cad019bc
    file_package="NDP472-KB4054530-x86-x64-AllOS-ENU.exe"
    unattended_args="/sfxlang:1027 /q /norestart"
fi

w_call remove_mono

w_call dotnet462
w_set_winver win7

```

There is few things to note here:

• you see w_call to dotnet462 so you need to goto load_dotnet462 and repeat that untill you get to the one that has call to the failing one - so in our example w_call dotnet40is in the load_dotnet48 and needs to be removed to go forward.
  You will need to do this for every installer that wont install automagically via winetricks (you installed it by hand)or if it installs successfully but winetriks wont mark it as installed.
  Things you need if installer fails:
• in w_set you have needed win version for installer
• in w_download you got 2 urls(in this case) which you can paste to web browser to download installer
• in unattended_args you have arguments to run the installer with

assuming you removed call to dotnet40 and saved the file you can try again.
It will fail few installers after that -

• if installer claims that install was successful but winetricks complains about missing files at the end and wont install the next one remove the w_call to it - it probably installed fine but check failed.
• if does not even start try if the url is working - if not search on microsft page or google for .exe name
• if the url is ok download it,
  set win version according to winetricks part for that dotnet ex.winetricks win7
  try running it wine <installer>.exe <arguments from winetricks>
• If it fails try without the arguments - you will have to click next ;)
• If it fails and you got more than one url/installer try the other one
• if it wont install anyway remove the w_call and hope this one is not needed -at least one of them failed no mater what I did but the game runs.

After you get dotnet472 finally installed you just need to add few things (i have them not sure they all needed)
winetricks xact vcrun2013 vcrun2015 vcrun2017 faudio d3dx9 d3dx10 corefonts - i got no issues here
xact-this on is needed for sure

Then in lutris click on Wine steam on the list of runners and + sign above the list to add the game.
Type in a name and under "Game options" tab the steamid 244850 for space eng
Icons and rest are optional,
Check runner options
Arguments: %command% -no-cef-sandbox
wine version: ge-protonified-nofshack-4.9
DXVK:1.2.3 and enabled
Start it from the app list and it should run steam and start the download

Hope it works!

Mention me if you need help ... or [email protected] - its public anyway

I wasn't able to run the game with lutris (Steam say that I don't have network), but I have installed on Steam with protontricks 1.2.2 and winetricks 20190310. Proton 4.9.2.
I have install dotnet472 xact vcrun2013 vcrun2015 vcrun2017 faudio d3dx9 d3dx10 corefonts.
I have renamed the intro video and start the game with : PROTON_NO_ESYNC=1 %command%

And honestly the game run fine. I have around 100 fps on planet with high graphic settings. I was able to start a game with a lot of mods. I didn't play for hours atm, I have to take time to make more test.
Mining on rocks was ok, mining was fine on planet or asteroids. I started with the star system map.

I have a sound bug like everyone, but it's ok after few minutes. The bug continu less noticeable, but you can play. I have to make test if I join other game, without hosting myself the game.

It seem that the game is close to be playable without problem, except thtat sound bug.

Thx for all the tips on this page !

@LtStich Did dotnet472 installed fine without any problems for you?
If yes that's a great news, they finally fixed the script. I confirm a
little sound stutter just after start. I also noticed that shadows
sometimes strangely flicker but I don't know if it's the game's fault or
proton

czw., 18 lip 2019 o 11:26 LtSich notifications@github.com napisał(a):

I wasn't able to run the game with lutris (Steam say that I don't have
network), but I have installed on Steam with protontricks 1.2.2 and
winetricks 20190310. Proton 4.9.2.
I have install dotnet472 xact vcrun2013 vcrun2015 vcrun2017 faudio d3dx9
d3dx10 corefonts.
I have renamed the intro video and start the game with : PROTON_NO_ESYNC=1
%command%

And honestly the game run fine. I have around 100 fps on planet with high
graphic settings. I was able to start a game with a lot of mods. I didn't
play for hours atm, I have to take time to make more test.
Mining on rocks was ok, mining was fine on planet or asteroids. I started
with the star system map.

I have a sound sound like everyone, but it's ok after few minutes. The bug
continu less noticeable, but you can play. I have to make test if I join
other game, without hosting myself the game.

It seem that the game is close to be playable without problem, except
thtat sound bug.

Thx for all the tips on this page !

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1792?email_source=notifications&email_token=ABSXEL3A4XGGNMQUHZ4NSITQAAZNVA5CNFSM4F6IMNRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2H4LLQ#issuecomment-512738734,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABSXEL6J4HFRILSQPK5FHVLQAAZNVANCNFSM4F6IMNRA
.

@MagicRB It's was fine but with protontricks 1.2.2 and winetricks 20190310.
Newer version of winetricks seem to have issue, I should try again, but now that the game is working I don't want to break everything :)

I will play a little more and see if everything is fine.

Yeah I cant get game to work because protontricks (1.2.3-1) won't install dotnet because it thinks its already installed. This is with a fresh arch install also so there is a major malfunction in recent wine versions or something. Quite a pita, who knows if it will ever be fixed..

If only MONO emulated dotnet 472....

Those issue should be documented and installed by Steam directly for the game...
It's annoying to need to play with prototricks and winetricks...

Wich version of winetricks do you use ? You know that you can make a manual install to use a specific version...

wget http://winetricks.org/winetricks -O /usr/bin/winetricks

So latest, whats the command to install the correct working version?

Here's an interesting bit I've noticed.
The very same stutter that's normally present in game becomes super frequent if you pull out any hand tool.

DXVK render passes also seems to make a leap into the triple digits on stutter.

In other news, how soon will wine mono be ready to run dotnet 4.7.2 applications? Anyone know what it's implemented so far?

wget http://winetricks.org/winetricks -O /usr/bin/winetricks

So latest, whats the command to install the correct working version?

Go here : https://github.com/Winetricks/winetricks/releases
Download : 20190310
Decompress, go to src to get wintetricks.

Uninstall the Winetrick that you have.
And place the winetricks you have downloaded in your path (/usr/local/bin for me on Debian).

After that try to reinstall from scratch SE and try to reinstall all what you need.
Don't forget to rename the intro video.

ok installing dotnet now appears to work. WHY would the winetricks maintainers cripple .net support? anyone know? seems nobody notices even tho its essential for so many things, that's like releasing a wine update that prevents .exe from running..... madness!

Anyway I left a issue on the github about it, who knows maybe someone will notice....

About the game, well it appears to load up now, the sound stutters a fair bit, I loaded a custom game on earth planet and it loaded up fine except lots of stutters and pauses, likely related to the sound engine having issues, it also warned about performance issues a few times but that seems to go away.
I would say the issues relate to the sound engine causing the stuttering problems etc...

I'm not sure the problem is linked to ths sound engine, but more probably about performance affecting the audio. I had another game like this, the sound stuttered, but once I got a new CPU it run fine.

On my side I have play few hours now, the game run fine generally, but the sim speed don't go over 0.8.
I have disabled music, but that doesn't change the performance.

Few crash, but in general the game is playable if you accept some lags / stutter and crash.. I have around 100fps in medium graphic setting on Earth.
I will test my atmo miner today probably, will see if the game doesn't crash. Actually I have only a small rover...

I have installed dxvk 0.96 with protontricks, but that doesn't change anything.
My CPU is not really used, the load is small, but the game seem to not being able to use all the core or performance from the computer.

As I say before, for me the sound problem is the consequence of the global performance issue (probably CPU side) and not the reason the game stutter... Don't know what we can do about that...

ok installing dotnet now appears to work. WHY would the winetricks maintainers cripple .net support? anyone know? seems nobody notices even tho its essential for so many things, that's like releasing a wine update that prevents .exe from running..... madness!

Anyway I left a issue on the github about it, who knows maybe someone will notice....

About the game, well it appears to load up now, the sound stutters a fair bit, I loaded a custom game on earth planet and it loaded up fine except lots of stutters and pauses, likely related to the sound engine having issues, it also warned about performance issues a few times but that seems to go away.
I would say the issues relate to the sound engine causing the stuttering problems etc...

I doubt they would do it intentionally, it's more likely Microsoft changing the .Net installer in some way so the version number is different to what Winetricks was looking for, they do love to tinker.

the dotnet installers have not changed

the dotnet installers have not changed

Well with things like this all it takes is a single spelling mistake on a single line to cause all sorts of problems, I seriously doubt the maintainers of Winetricks would do something like this to screw with us, what would be the point?

It seems Wine 4.12.1 installs .Net in such way it works with Wine 4.12.1, while Wine 4.2 installs it such way it works with 4.2. Setting WINE and WINESERVER environment variables pointing to the Proton binaries made winetricks work reliably.

Regarding the game, I get serious stuttering because of sound: Simulation Speed is 1 but thanks to sound effects it reduces to 0,73 and return to 1 later. If I use the welder Simulation Speed drops to 0,53 until it recovers. The problem happens regardless if I remove FAudio libraries or if I use winetricks xact, even with sound disabled it happens, really noticeable with the welder.

It seems there is a graphical bug on helmet's corners and light sources, but this is minor.

System information

With Proton 4.11-1 it works out of the box if you have renamed the video file. But there is quite a stutter, for audio and visually. Installing dotnet472 and xact did not seem to solve that. Any tips?

I haven't figured out how to resolve the stutter either, if it wasn't for the stutter then it be just fine, even at 4k on my 1080TI it gave 50-60fps which is quite nice, except for the stutters...

No performance change for me with 4.11.
I continu to think that the sound issue is a performance problem and not a sound issue (see the sim speed). The sound stutter because of the bad stability / performance.

Switching to kernel 5.2 give ma little boost performance. But the sound issue is always here.

I also cannot confirm a performance improvement for me with Proton 4.11. I also tried out the FSync function on Arch Linux with the provided linux-fsync kernel. Verified that the correct kernel is loaded and cannot confirm an improvement here as well, unfortunately. The stuttering is still there.

One minor question: The game was started with DXVK_HUD=full %command%. The frametimes graph shows red bars when the stuttering occurs. I assume this has no special meaning other than that no frames are rendered?

I did notice the "idle" simulation speed got a bit higher here, from 0,73 to 0,87 consistently. The performance problem that happens, apparently, when sounds are played is still present. It's strange that it keeps running at 0,87 simulation speed even when there are, supposedly, enough CPU spare cycles.

I noticed that often the game seem to recreate the sound streams. pavucontrol shows the game stream is the stream 2, but later it's stream 6 and later it's stream 10 when using pulseaudio.

Also, every time I close the game it opens the Wine Debugger and then open the window saying the game crashed.

I recorded a video showing a bit of the game status, including the sound problems: https://cdn.discordapp.com/attachments/457747189616214019/606572169886957577/se-sound000.webm

The winetricks command I used for the current prefix is winetricks -q xact dotnet472 vcrun2013 vcrun2015 vcrun2017 faudio sound=alsa. And the current system specifications.

Interesting, I clearly have better performance and I don't have this issue when using tools (at least not that much). My sim speed is between 0.7 and 0.9.

When I play if I run htop I can clearly see that my CPU is not fully used, I have a lot of "spare ressource" available. They can probably do something about that... Like change the video for the start menu and don't use that wmv format... Maybe that all the things about the sound is the same problem... Very "windows like" files and tools...

[EDIT]
Quick test in space, no mods. Small sound issue, but really small.
Sim speed between 0.9 and 1. Don't go below 0.8 even when I use tools.
Around 100 fps with high graphic setting.

Performance will probably drop if drone spawn, I have big issue with that in my game with mods on earth. As game can't probably manage to use all the core or spread the load.
[/EDIT]

Have we confirmed that a apitrace for this game isn't going to help with this particular issue? sounds like it could be a wine related issue and not dxvk.

Theres actually 3 or 4 rollup issues as i understand them:

1. audio needs some rather bleeding edge FAudio stuff to work. This is not merged either as of Proton 4.11. Even with FAudio you will see a significant amount of audio stuttering which may lessen depending on your machine/cpu/framerate/etc.
2. dotnet472 is required. I think Proton 4.11 fixes this?
3. ingame video doesnt work. Probably a media framework problem like a bunch of other games have.
4. Haven't been able to test yet with Proton 4.11, but on 4.2 at least, the 'windowscodecs' PNG parser (or code upstream from it) doesn't correctly handle the byte-order of 16-bit grayscale PNGs, which is what VRAGE (the space engineers engine) uses for its planetary heightmaps. This might be fixed, but I moved from a nvidia machine to a Vega so I'm getting hit myself with GPU hangs seen as in https://github.com/doitsujin/dxvk/issues/252 when I try to run SE on a planet. I can go back and check on the nvidia machine some time later, but if you're seeing 'spiky' planets, see https://source.winehq.org/git/wine.git/commit/0c0def962f2b86f44625f11d8d9d2013aaffa46a if you want to try backporting that fix.

@kainz
Are the missing Faudio bits causing the stutter in-game?
Any open issue or patches to try them out that you're aware of?

I know for a fact it's been profiled before and the stutter was not a result of any DX calls.

I'm not dev, but on my opinion the issue we have with SE is more linked to the multi thread and performance.
Probably what they are working on : https://lkml.org/lkml/2019/7/30/1399 and with the esync replacement : fsync : https://steamcommunity.com/games/221410/announcements/detail/2957094910196249305

This need a very recent kernel, maybe someone on Arch can make some test... I will look as I use the Liquorix kernel on Debian...

For fsync instruction : https://steamcommunity.com/app/221410/discussions/0/3158631000006906163/

The game launches with just Mono, but I get this message (which clicking closes the game):

Surprisingly I had no menu music stutter when this popped up, maybe the stutter is due to dotnet itself on wine?

Whoa! Neat! How'd you get it to launch with Mono?
@LtSich
Gentoo user here, fsync doesn't help. If it's mono like @fls2018 says above then this could be a nice fix.

depends if it stutters ingame.

Whoa! Neat! How'd you get it to launch with Mono?
@LtSich
Gentoo user here, fsync doesn't help. If it's mono like @fls2018 says above then this could be a nice fix.

Just a fresh prefix with the mono proton installs by default, I also had to change xaudio dlls to native as faudio makes it crash. I'm guessing the popup is because either mono needs wpf or maybe it's checking for .Net, finding mono instead and refusing to continue. In the logs I see it recognizes mono as the environment: Environment.Version: Mono 6.3.0 (tarball)

I also installed dotnet472 again it allowed me into the game but menu stutter returned, also using fsync kernel.

Then you say that there is no stutter with mono, but the game refuse to continu without dotnet...
Is that something that KSH could directly change in their game to help us ?
Same as changing the video format to avoid renaming the intro video and to be able to see those video in the background in the menu...

This may be something KSH could change. If they remove the dotnet check in the presence of wine it may assist but this is of course a: DO NOT from the advice of the wine developers.

We should open a bug report on WineHQ and get some assistance same as the terrain spike issue. Where can I find this bleeding egde mono binary?
Going to test a nightly build.

Now that I've tested this out it may actually be worth asking the developers to ungate the useage of mono. They check the enviornment variable to see if you're running old buggy dotnet to tell you to update but it seems that it doesn't account for a null value and just drops the game altogether.

The log states: 2019-08-03 11:07:01.985 - Thread: 1 -> Error occured during enumerating environment information. Application is continuing. Exception: System.ArgumentNullException: Value cannot be null.

In this instance if we can ask up KSH to drop the check Proton may work with a Gold rating that quickly on protondb!
Where's a good place to get a hang of Keen?

Then you say that there is no stutter with mono, but the game refuse to continu without dotnet...

Just to be clear I'm talking about the menu music stuttering, which seems to be related to the ingame stutter. It may be it's not audio or graphics that's the problem but the fact this game relies more on .Net than some other titles and .Net via winetricks is flaky at best.

It may be it just needs mono not to be blocked by the check and all is well, however if the game uses other stuff from .Net like WPF then it might be the case it's giving the popup because it can't use it because it's not available in mono (yet).

@SpookySkeletons

Here probably: https://forum.keenswh.com/

1 dev from KSH should really join us here and look into this...
This and the video format to use something else that would work on Linux to avoid the need to rename the intro video...

I can't get a confirmation email for my old account it seems so someone else will have to make the thread. As @LtSich said point them to our git so we can get a dialog going here as well!

I know KSH is also active on Discord if anyone has a link to their channel you could direct message them there.

Here's the official discord: https://discordapp.com/invite/KeenSWH

We need to ask if the game requires WPF or other DotNet specific components.
Unblocking mono wont be worth much if they're using unimplemented features.

Proton 4.11-1 adds a regression that reintroduces buggy terrain generation

Proton 4.2-9 works fine but still have stuttering but that seems to be DotNet as SpookySkeletons and fls2018 mentioned

It seem that the 4.11 version add a lot of problem.
Empyrion and Frostpunk doesn't start anymore but work fine with 4.2-9.

Apparently SE have some issue back with the terrain generation.
Didn't see that myself but I only played few minutes to test if the game start.

tried running with 4.11-1 with d9vk enabled. gives an error that .net framwork is out of date and to use a windows hotfix and then crashes.

tried running with 4.11-1 with d9vk enabled. gives an error that .net framwork is out of date and to use a windows hotfix and then crashes.

The game is not supposed to run on DirectX 9 unless you rollback a few patches.

DXVK and Proton 4.2-9 with DotNet 472 is currently the only know way to run the game.
It will however stutter and that is currently not avoidable.

I have try : https://twitter.com/LtSich/status/1158672187022348288

Its more of a performance glitch then anything, something is hitching, if that something was resolved the game would perform and run fine at good fps..

Fist of all, GREAT JOB.
You've come a long way that only true engineers can follow. That's some real dedication right there. :+1:

Now back to the subject.
Regarding the performance issues number of you mentioned, I'd recommend you to switch to a "Modding build" which we distribute along with the vanilla build in Steam.
Besides bunch of goodies for modders, it comes with our internal profiler enabled so you'll be able to see exactly what's slowing down your game. It's always easier to _fix it_ when you know what's the issue.

You'll find all you need here:
https://github.com/malware-dev/MDK-SE/wiki/Advanced-Profiling-The-Game

When it comes to the ".NET version check", the game does not enforce any specific version of the .NET as long as all components start and run properly.
After a quick look into the code, it looks like this message-box is triggered by failure in script compiler initialization. If that's the case, you should see following line in the game log:
"Error during ModAPI initialization: SOME MESSAGE HERE"

The compiler is not essential for the game as long as you don't require mods or in-game scripts, so you can knock it off for test. You know how to fiddle with MSIL binaries, right?
https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/Sandbox.Game/MySandboxGame.cs#L1401

@InflexCZE
Thank you for the information.

I'm not that experienced at IL editing but managed to edit that value and get through to the menus with mono:

But on attempting to load a game it crashes with this error:

Here's the log:

SpaceEngineers.log

Chances are I might not of edited the dll correctly, it's showing errors about there being a duplicate of whitelist something or other.

Based on the log, the marriage of Mono and our compiler is not particularly happy one :stuck_out_tongue:
That's fine, we don't need it.

Unfortunately there is no single point to disable the compiler (yet) so you gonna have to gut out 2 key places I've identified and hope for the best.

1) Get rind of all stuff in this ctor.
https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/MyScriptWhitelist.cs#L47

2) Make this method return null (prevent it from invoking the compiler core)
https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/MyScriptCompiler.cs#L154

@InflexCZE is there an understanding what fails and why? Or a way to create a small test that fails in similar fashion.

Every .NET runtime (.NET FW, Mono, .NET Core, Xamarin, ...) comes with base class library (BCL) of its own. While the implementation and functionality is very similar across the board and program compiled with one specific BCL in mind is usually fine when given different implementation at runtime, some differences are still there.

In this case it's distribution of certain BCL types among the BCL binaries that's throwing the compiler off. Few quick adjustments would probably resolve the issue and make the compiler fully functional on Mono BCL too, but that would be a bit harder then knocking the compiler off and testing if the game runs on Mono-Linux better or not. If so, then we can focus on polishing.

I hope that answers your question in an understandable matter :smile_cat:

Well, I tried going the other way and trying to get the profiler build working, but I had less luck with that. I installed the Mod SDK and tried to run the game by both installing dotnet472 and xact into its prefix and symlinking the Contents folder into its path (that's how I actually ran Mod SDK on my Windows install) and by copying the Bin64_Profiler folder into my regular install (where everything is already working and I can start the game). Neither approach really worked.

I set all the environment variables wine might need and used wine found in ~/.local/share/Steam/steamapps/common/Proton 4.11, tried running proton run from that directory, but every method yielded the same results:

• I got a warning about running without the Steam runtime and instructing me to change the value of the MyFakes.ENABLE_RUN_WITHOUT_STEAM variable, which I cannot do without editing the assembly, as I understand it at least.
• It then complained about running Windows and graphics card driver updates
• After all that, all I get is a crash, with the following stack trace

Unhandled Exception: 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 VRage.Platform.Windows.Forms.MyMessageBoxCrashForm.InitializeComponent()
   at VRage.Platform.Windows.Forms.MyMessageBoxCrashForm..ctor(MyCrashScreenTexts& texts)
   at VRage.Platform.Windows.Forms.MyMessageBoxCrashForm.ShowDialog(MyCrashScreenTexts& texts, String& message, String& email)
   at Sandbox.MyErrorReporter.ReportGeneral(String logName, String gameName, String id)
   at Sandbox.MyCommonProgramStartup.PerformReporting()
   at SpaceEngineers.MyProgram.Main(String[] args)

Which is not that useful anyway because that's the crash report message failing to load...

If anyone has an idea on what I'm doing wrong and can get the profiling build working proper instructions would be appreciated, more eyes on the problem the better :)

Please provide game log. It should contain the original exception.

Log attached:

SpaceEngineers.log

Since it's mentioning DX9 in some of the namespaces I tried running it without DXVK thinking that might be tripping it up, but it does not seem to have helped.

The issue is actually somewhere in internals of this method (Windows Forms) as it failed to load image of the game cursor.

https://github.com/mono/mono/blob/master/mcs/class/System.Drawing/System.Drawing/Image.cs#L154

at System.Drawing.Image.FromStream(Stream stream, Boolean useEmbeddedColorManagement, Boolean validateImageData)

Hopefully someone knows what's going on, cos this is where my field of expertise ends.

Well, I was doing something wrong as well when manually messing with the prefix, os I tried just dropping the Bin64_Profile folder into my regular install and renaming it to Bin64. This helped somewhat (got the splash screeen), but it's presumably failing due to additional bits included in the profiling build. First, it fails to get the OS name (using Mono, doesn't complain with actual MS dotnet installed) but seems to get past that (with seemingly correct OS name too, so, yeah...) but fails at trying to initialize the graphics (this happens with both DXVK active and when setting USE_WINED3D).So, it seems that the profiling build won't load for now.

SpaceEngineers-Mono.log

Mono log attached, the actual crash is the same with dotnet, this just demonstrates the flaw in Mono as well.

Drop here render log too please

Ah, never noticed that gets written by it. Here it is:

VRageRender-DirectX11.log

Failing at shader compilation it seems. Is there a way to get precompiled versions of those somewhere?

Interesting. Game already comes with precompiled shaders in %SE_install_dir%/Content/ShaderCache.
Check if they are in tact, not corrupted or anything.

Alternative cache dir for by-game-compiled shaders is %dir_where_you_found_the_logs%/ShareCache2.
You can try copying the cache here to see if game has better luck finding it here.

Tried verifying the files, tried copying it over to %appdata%/SpaceEngineers/ShaderCache2, even tried %SE_install_dir/TempContent/ShaderCache just in case the profile build tries that one as well, same result in all cases :(

Hm, it is possible that profiling build adds some profiling code to shaders too which will render the provided cache unusable.

You've said that you have SE running on Win too, right?
Maybe you could try running profiling build on Win and then copy generated shader cache over to Linux?

are you guys trying to get this running without dotnet (with mono), or trying to resolve the stutters? (or both).

Well, on the profiling build side, I'm trying with dotnet since we know that loads completely and is playable, so hopefully we could pin down the stutters on that front. Given that the current problem with mono is that the compiler doesn't work, which means scripts and mods won't work even if we trick it into loading, I think that might be a better course of action for now, both on the front of getting the game fully functional and we may pin down a problem in Proton that, if fixed, might affect other games as well and make them work.

Sadly, I'm currently stuck on that front - I accessed my Windows partitions and tried copying over shaders from there (there was a lot more files present), but no luck, exact same crash. I planned on also completely clearing out everything in my Windows install and just starting the game in profiling mode from a blank slate to make sure that the shaders are compiled, but my Windows install is currently not booting due to me doing some partition and HDD shuffling recently and I have not managed to fix (or reinstall) it yet.

If anyone else has a working dual boot (or an extra PC with Windows installed) and can re-trace my steps to see if it runs with compiled shader files copied over that would be great. Meanwhile, I'll try to get my Windows install working again when I get some free time to do it.

I should have a working windows 10 install, havent used it in a while but it should work. When I get home I'll try to do that shader thing.

@InflexCZE thx for helping us Linux folk! Not to be rude or anything, but we've been asking for help for a long time now, what changed?

So, I managed to get fresh shaders off from a Windows install (it involved family share, a roommate and bribes, still less hassle than reinstalling Windows).

Well, no dice, it seems it's intent on recompiling those shaders no matter what. Tried installing Visual C runtimes as well (all of them from 2010 upwards, but 2015 failed to install and I didn't really bother with trying to get that one going as well) in hopes it's just missing some C++ runtimes, but no luck with that either.

So unless vcrun2015 in particular would help (which, given the errors, I doubt), I'm fresh out of ideas, this involves both shaders and VRage specific stuff that are way above my head. I case someone else can get it going, please do post your results.

@Onyx47 what do i need to do in order to get into the state you have at?

@MagicRB All I did was install it as we all did so far (including protontricks 244850 -q dotnet472 xact), installed Mod SDK version from the tools page, then copied over the Bin64_Profile directory to the regular SE install dir and renamed it to Bin64 after renaming the original one to Bin64_bak.

Launching the game from Steam will then attempt to run the profiling build. For reference and to spare you digging through directory structure (you should be just able to copy-paste the paths into your file manager / terminal):

• SE install should be in ~/.steam/steam/steamapps/common/SpaceEngineers/
• Mod SDK install where you should get the Bin64_Profile directory from should be in ~/.steam/steam/steamapps/common/SpaceEngineersModSDK/
• SpaceEngineers.log and VRageRender-DirectX11.log should be in ~/.steam/steam/steamapps/compatdata/244850/pfx/drive_c/users/steamuser/Application Data/SpaceEngineers

Son of a Klang, it runs! All we needed was d3dcompiler_47 package from winetricks. And there I was installing XNA and VC runtimes to try and see if any of them contain the missing headers (float.h and xnamath.h) it was complaining about...

Well, it starts now but sadly crashes on creating or loading a world. I can confirm the profiler does work in the menu at least (and the stutter is present even there, so might be something we can work with regardless).

I'm attaching my latest logs from the moment it started up to trying to load a world (after which it crashes). I'm noticing that the last line in SpaceEngineers.log is

External debugger: listening...

Might be what's crashing it, might be not, but... I'm not familiar with remote debugging in .NET, is that just a socket like gdb provides, and is there a chance we could attach to it using MonoDevelop or something? Or is there at least a way to get some meaningful info from it even in the menu alone even without that? Like dumping some profiling logs in a file somewhere? I don't see anything about that in the linked Wiki.

cc: @InflexCZE

NOTE (mostly for Inflex): Don't mind the video errors, we're aware it doesn't load and don't really care anyway, the game runs after clicking through it.

SpaceEngineers.log

VRageRender-DirectX11.log

Edit: Some screenshots of the profiler in the menu at least, the main culprits seem to be MyAudio-Update (as was at least partially suspected) and GuiManager - Update Screens, which is not really what I expected.

https://imgur.com/a/S1O435i

Great news :+1:

Unfortunately logs doesn't contain any useful information that would help me determined cause of the crash. Most likely problem in native code resulting in segmentation fault and OS shutting down the process immediately. Usual way to debug this is to instruct OS to take mini/full dump of the process before tearing it down. If you manage to capture one and resolve stack track from it, I'd prolly be able to tell you what's going on. Since the shutters are present in main menu too tho, I wouldn't bother with it now and proceed directly to profiling.

To do do that:
1) Start the game into main menu
2) Open up profiler with Alt+[NumPad Dot]
3) Switch profiler to deep profiling mode Alt + E
4) Collect one full profiling window of data (Wait 1024 frames)
5) Save to slot #1 with LCtrl + Alt + 1
6) Locate and share file in %appdata%/FullProfile1

All this info is in the manual I've posted before:
https://github.com/malware-dev/MDK-SE/wiki/Advanced-Profiling-The-Game

Edit:
"MyGuiSandbox::Update3" updates game input (Collects mouse, keyboard and joystick states from OS). We have number of profiling blocks there too, I wonder why they don't show up. Please enable the deep profiling if they show up in that mode.

@InflexCZE: Ok, so rewriting my whole post because you finally forced me to try and learn how to use the Wine debugger and actually found the crash cause immediately: missing VC runtime 2003, I assume that it's a requirement when installing ModSDK but due to the way Wine works it wasn't installed in the prefix (prefix being a full Windows install as far as the application within it is concerned) I was running the game in. After installing that the game actually runs in profiling build.

So, ignoring the menu for now, here is a profiler dump I took on an otherwise empty Solar System map.

FullProfiler-1.gz
(renamed due to GitHub being picky)

And here's the menu as well in case it's the same problem and menu dump might have less noise in the signal:

FullProfiler-2.gz

Hope I didn't forget something crucial here.

From what I can see in the profiles, there is no single system being affected that would be slowing down entire game. All system and all threads are affected equally across the board. Unfortunately this means that there is no single system that we could optimize and/or fix to help you with the shutters. What it tells us on the other side is that the issue is on system side of things.

I recognize the pattern in the profiles very well. When I see it on Windows, 9 and half times out of 10 it's GC (.NET garbage collector). Either there is something affecting its normal functionality and causing it to stall the game for enormous amount of time during every work cycle or, since it's self tuning machine, it got terribly miss-configured due to invalid info being given to it by improperly ported OS function.

Alternatively, there could be some very basic OS function, something as common as malloc for example that all systems over entire game (or .NET Framework for that matter) use. Having one such function poorly performing upon a call, it could explain the findings too.

In any case the game won't be able to profile itself and find the issue. It will need to be profiled from outside and cause found by external tool that will be able to identify either the slow OS function or convict the GC of guilt. In such case knowing what in the GC is slow might tell us how to address it too. I'm not familiar with profiling on Linux so I won't be able to assist you there.

As for the second option the Mono seems to handle the game with more stability so alternatively we could proceed with Mono and see how well it will perform under some more workload. My last instruction regarding this matter showed how to gut out the in-game compiler so now you should be able to start a session. If you encounter any further issues there and if it's within my field of expertise, I'd be glad to assist you there.

It's quite likely that resource querying functions have been stubbed and are feeding .NET bad information, perhaps in WMI or an NtQuery* function in ntdll.

First of all, thank you very much Inflex for taking the time to look into this at what I'd assume is your off-work time.

Well, while not great news for a quick fix we hoped for, at least it puts us on the right track instead of chasing ghosts. I messed around myself a bit looking at the graphs and I did notice that the spikes happen all over the place, so even as an outsider to the codebase (and someone with very superficial .NET knowledge) I find the explanation of GC issues very compelling.

I'm going to look into whatever I can on both Mono and native .NET fronts over the next few days and try to provide as much info here or see if it would be worth opening a new issue. In the long run, it would probably be the best if we could fix it properly and get it patched upstream because if the GC is acting up that means there are potential performance gains to be had in a wide array of applications, not just games. But, baby steps :)

I hope this is at least somewhat helpful, i really have little experience with this kind of thing.
setrace.zip
This is a copy of a system trace gathered from perf. It should be openable from PerfView in windows. Or you could alternatively drop the fileperf.data.txt into SpeedScope
I tried looking at the traces in SpeedScope, but as I said I basically have no idea what i am looking at.
Hopefully someone else can make use of this. If more information or a different trace is needed I will do my best to provide what I can.

Hi @kisak-valve just for information Space Engineers doesn't work with Proton 4.11-2 but work with Proton 4.2-9.
It was starting with 4.11 but with strange bugs, and with 4.11-2 he doesn't start at all.

And we continu to suffer from bad performance, with the help of @InflexCZE to find what is the problem but at this time we don't make any progress as it's very complex.

If you need any help to find what is causing the problem with 4.11-2 just post here we will try to help.
And if you can work with @InflexCZE to improve the game performance that will be amazing :)

Hello @LtSich, friendly reminder that I'm a moderator for Valve's issue trackers on Github and not a Proton dev myself.

Looking over the recent history, it looks like multiple devs have dropped in and are pondering the game, so there's not much I could contribute. This seems like the first clear mention of a Proton 4.11-1 -> 4.11-2 regression. Can you please add PROTON_LOG=1 %command% to the game's launch options and drag and drop the generated $HOME/steam-$APPID.log into the comment box.

Sorry for my mistake @kisak-valve.

Here is my log for Proton 4.11-3 https://dl.cafe-philo.net/steam-244850.log.gz
The install for dotnet 472 failed.

Any updates/progress?

No updates I think.

The install for dotnet 472 failed.

Make sure winetricks is updated, if not try downgrading a couple versions, this was a bug in their previous release which I was told might be fixed with latest build. (yet to try it myself)

Here is a apitrace of the game loading up into a new alien world under Win10 with wrapper injection method (d3d11, dxgi). No overlay is enabled. 1080TI used.

Win10-trace[1.6GB]: https://www.dropbox.com/s/2yxl18f7a2l126o/SpaceEngineers.7z?dl=0
_Linux-trace[]: would this help?_

Maybe this will help further investigations into the performance issues.

I have looked into the performance recordings some more. I still have little idea what is going on, but I noticed that Inode mismatch seems to occur frequently and is the item that is taking up the most CPU performance during a lag spike.(See attached image)

I also noticed that during the lag, a single core spikes to 100%, and the other cores decrease in usage. I am not sure what to make of it. Perhaps the rest of the game is waiting on something that is single threaded.

Here is an image with more of the spike selected.(There are a lot more items below the screen, but I did not want to post a dozen screen shots.)

Below is a slightly narrower selection of a different spike shows similar issues.

I have no technical knowledge of this, but I hope it is of some help though.

AFAIK inode mismatch is a warning of sysprof that the file has changed on disk. In your trace this might mean, that the Proton and steam binaries have changed on disk since you recorded the trace. So, no actual symbol of the executables which caused the spikes can be displayed.

Alright… something in MS Dotnet is causing the lag issue. I got SE working with wine-mono 4.9.3, after I took @InflexCZE advice and disabled the DotNet Version error dialog. The main menu had no lag after I disabled the check. The game kept crashing on world load, with script compiler errors. After I gutted the script compiler, the game world failed to load a few more times, but eventually let me into the Crashed Red Ship world.

The game ran flawlessly… no stutter at all. There was only a faint occasional audio fade out (probably some issues with faudio as the same audio fade is in Fallout 4), but no lag or stutter to accompany it. I can confirm that the stutter does exist with MS DotNet, even with the gutted script compiler. So I am not exactly sure what is wrong with the script compiler, which means no mods… but this does mean that mono will be able to run the vanilla game very well if the script compiler is disabled.

If anyone needs logs or other information I will do my best to help.

Alright I created a video showing both the DotNet and Wine-Mono versions of the game. The mono version runs so much better!

Here is a link to the Video:
https://youtu.be/LwqRLCQR6aM

Now all we need to do is figure out how to get the script compiler to cooperate with Mono, and the game will be, close to if not just as, playable as on windows!

That's a big difference !
Thx for your test !

With mono it's without mods and without scripts ?
Or just vanilla game without mods ?

How do you make to run the game that way ?
Any docs anywhere ? (I'm' really not good at such things).

@LtSich Both the dotnet and the mono versions are plain vanilla without scripts or mods.

In order to get the game to run I had used the advice of @InflexCZE and cut out the script compiler.
From Aug 10th post from @InflexCZE :

Based on the log, the marriage of Mono and our compiler is not particularly happy one stuck_out_tongue
That's fine, we don't need it.

Unfortunately there is no single point to disable the compiler (yet) so you gonna have to gut out 2 key places I've identified and hope for the best.

1. Get rind of all stuff in this ctor.
   https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/MyScriptWhitelist.cs#L47

2. Make this method return `null` (prevent it from invoking the compiler core)
   https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/MyScriptCompiler.cs#L154

Looks butter smooth @Linux74656 . Your hard work paid off after all, CG 👍
I may be able to take a look on the compiler in the evening, maybe we'll be able to make it work too so you can enjoy mods too.

Btw, I did take a look on the trace @Linux74656 provided, but it was either my incompetent usage of the PerfView or it was missing symbols or something, but in either case I wasn't able to open the trace and see any useful info there. Since mono seems pretty stable tho, I think we can continue with it and leave .NET FW debugging to someone else :)

I could not get any useful data from performance tracing either,,, that is why i gave up on dotnet and started working on getting mono to work. I am pretty sure the traces are incomplete, because i can't figure out how to resolve missing symbols.

Damn if the game can run with mods and scripts that could really be awesome...
Thx a lot for your work guys !

Here are the logs and the minidump file from the game as it tries to load a saved world.
This is using wine-mono, and the only code modified is to disable the dotnet popup, so the script compiler code is untouched.
SpaceEngineers.zip

After a brief look at the compiler it looks like we could get around the issue pretty quick, at least this one. We'll see what/if some other will jump on us afterwards.

In the VRage.Scripting.MyScriptWhitelist there are 6 guards that ensure whitelist compatibility with provided BCL (More on that here: https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-520141233).
Those need to go.

Replace following IL.thows with IL.pop followed by immediate IL.ret.

MyScriptWhitelist#RegisterMember(MyWhitelistTarget, ISymbol, MemberInfo):
    (2x) throw new MyWhitelistException("The member " + member + " is covered by the " + namespaceKey + " rule");
    (1x) throw new MyWhitelistException("Duplicate registration of the whitelist key " + whitelistKey + " retrieved from " + member);

MyScriptWhitelist#Register(MyWhitelistTarget, INamespaceSymbol, Type):
    (1x) throw new MyWhitelistException("Duplicate registration of the whitelist key " + whitelistKey + " retrieved from " + type);

MyScriptWhitelist#Register(MyWhitelistTarget, ITypeSymbol, Type):
    (1x) throw new MyWhitelistException("The type " + type + " is covered by the " + namespaceKey + " rule");
    (1x) throw new MyWhitelistException("Duplicate registration of the whitelist key " + whitelistKey + " retrieved from " + type);

After this change we risk that whitelist checker will miss-function a bit, either allowing scripts to do more than they should or prohibiting something that should be allowed. We can deal with that when we get there. For now I'd be good to make it start :)

Let me know where this gets you, if you get to the game or some other issue stops you.

That go me into the game with Experimental mode enabled. Before i would get an error message.

Unfortunately I do not think the scripts are working. I was able to get a few basic mods (DX11 Door pack DX11 Shutters... etc) working, but things like Easy Inventory do not function.
I found somthing very intereesting, the games campaign missions do not seem to work either... i assume they rely on scripting. You can see the error in the video below.
Video Link: https://youtu.be/aP7FdE4L6-M

Here are the log files from this event:
SpaceEngineers.zip

Yes, campaign runs on scripts too.

There is a special screen for mod-loading-errors. (Ctrl?) + F11 after you load into a game. If something went wrong during the load, it should be there.

For a quick compiler test, try pasting programmable block + battery in empty world and load in following script. It should either print the message in block detailed info or throw some compilation errors at you if it fails. This should tell us if the compiler works and just needs some tweaking or if it's totally broken.

void Main() 
{
    Echo("Yay works");
}

I created an empty world and placed a battery and programmable block with the code above. This was the result after i hit check code:

Nothing else popped up.
When i closed it an went back to the Control Panel i hit run, it says assembly not found...(Results below)

Clicking recompile does nothing.

I guess this falls into the "totally broken" category :)
Anything in log?

Here are the logs: SpaceEngineers.zip I included the Proton generated log as well.

Alt + F11 gets me to this screen:

and clicking open in new window shows this:

I have 4 mods loaded in this test: Easy Inventory(Failed), Text HUD API(Failed), DX11 DoorPack(Some Texture issues but functional), and DX11 Shutters(Fully functional no issue.)
So it seems mods without built in scripts will function.

No error message, nothing in log, I not sure how this happens but looks like you've found hole in our compiler error reporting.

I think I'm gonna have to debug this on my own. Could you write down steps to make SE work on mono for me. What Linux to use, what packages to download, ... I'll setup VM and try to narrow down what's going on.

Alright @InflexCZE I made a quick guide from start to finish. I don't think i forgot anything crucial and i made the guide geared toward everyone. It is incomplete however the parts that are missing don't really apply to you as it involves modifying the code.

NOTE: I would avoid a VM, i could never get the game started using one. A VM might work for limited code debugging... but it would probably be much easier in the long run to install Ubuntu onto a _blank and separate_ (to minimize risk of data loss) SSD. An HDD would probably work, but I have noticed more stutter in the game while it is installed on an HDD.
Good luck! I hope this helps.

Guide.docx

Well, seems like stuff is happening in my absence, I kinda never managed to continue debugging using .NET but if Mono works that's even better!

I assume this is the regular build, wouldn't running the ModSDK version make more sense here? That should log exceptions from mods to the log file, IIRC?

I'll try that later and post logs if anything comes up.

Guide.docx

Thx for your doc... But damn, you just stop at the most important part :(
This is probably something that KSH have to do directly in the game.
Bypass the dotnet check if there is any way to detect that the game run on Linux...

The dotnet check should stay for windows users but should also check for mono support in the same statement

If you're talking about game modification to add proton/wine specific checks, please don't do that.

@Linux74656 while I understand your apprehension about writing a guide on how to modify the code, could you at least tell me which tool you used? MonoDevelop's Assembly Browser doesn't seem to allow any modifications to be made (or I'm just failing at using it properly), and I can't seem to find any other readily available Linux tools kicking about. I do have a licenced copy of Rider on my work machine which might help, but I'd try to avoid messing with this at work.

Read again, _the tool_ is in the guide :)

@Linux74656 Btw please add step of "Enabling SteamPlay for all other titles". Took me an hour to figure out why basically all games in my library offer direct download, just SE offers only streaming from other machine (I know, I'm dumb)

@InflexCZE I have indeed seen that but I hoped for something that runs properly on Linux, since my Windows install is currently hosed and I didn't have the time nor the inclination to fix it yet... I'll get a VM running I guess and keep going tomorrow if needed, but with you now on the case it might be superfluous. Still, will try to lend a hand where and if possible :)

@Onyx47 Ah, sorry I didn't realize. I'm not used to working with .NET on Linux so I don't know the tooling there :(

I bring some good news tho. I managed to make the compiler run, compile dynamic assembly and execute it too. So far tested only on .NET FW tho. It's almost 1am so I can't be bothered trying to switch to Mono now :stuck_out_tongue:
In any case, here goes the fix. Try it, if you encounter any issues on Mono I'll continue debugging it tomorrow.

Our engine calls Roslyn here:
https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/MyScriptCompiler.cs#L204

The code in link is a bit outdated, in reality there is one more argument (pdbStream) in current version on the game. Gut out this argument (pass null instead) and compiler should comply. (So basically revert it to this old version of the line that is in the link.)

Ofc apply this change on top yesterdays' changes. If whitelist checker complains (as I've said the BCL is not fully compatible so it may be miss-configured a bit now) you can shut it down very simply by putting immediate return at the beginning of this method:
https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/Analyzers/WhitelistDiagnosticAnalyzer.cs#L43

Sorry @InflexCZE I missed that entirely! Thank you for pointing it out! I have updated the guide link with a revised version!

@Onyx47 Unfortunately I tried looking for tools that ran natively in Linux. I failed to find any that worked. So I used the tool mentioned and ran it in a wine prefix with vcrun2015 vcrun2017 and dotnet472 installed. it seems to work fairly well.

Seems like a fair bit of work still for common steam users to get this game working. I do hope that some of these solutions can make it in a update for SE sometime so people can just press play and be done with it. I can tell you now not many will be bothering with compiling their own scripts :)

@InflexCZE That got it!!!!
The in-game script you gave me from before compiles!

void Main() 
{
    Echo("Yay works");
}

Easy Inventory works as well!

@InflexCZE
Oh WOW!

Are we going to see these changes upstreamed to the game, albeit in a slightly less hacky form, any time soon? I'd love to start playing again, it's been too long.

Let us know what the Linux player count bump looks like on your end once this hits reddit!

As a temporary workaround, would creating a patch file / patcher script that makes the relevant changes automatically be frowned upon from the legal standpoint? I'm not a lawyer, but it seems to me that various widescreen patches and similar for some games never bothered anyone and this seems like the same kind of modification to me...

To be clear, I'm not suggesting distributing a modified executable, just a simple binary diff that would patch the existing game that would still have to be downloaded from Steam.

Maybe @InflexCZE could check this for us with Keen legal/leadership for us? Of course, I'd hope that there's a good change we can just get these changes into the game itself and make all of this moot, but as an alternative (in case this might cause problems upstream) it might be viable (and could be made into a Lutris script for less tech savvy players).

Another option is, of course, updates to Wine/Proton that would make the game work properly with MS .NET, but since it seems it's a GC issue, that might be a long way away since it's undoubtedly a tricky problem.

It's good to see that there's at least some love for the game on linux, I would love to be able to play it, even through proton.

@Onyx47 If it's possible to create a diff containing only the required changes it wouldn't really have any legal problems, considering you're not redistributing any part of KSH IP. In essence it would be no different from a regular mod

I have contacted Keen about the legality of redistributing a patch like this, and the person they forward the email to said that they would bring it up to the CEO at their meeting on Monday.

That being said... I have created a Diff patch and applied it to the game on my sisters computer. It seems to have no issue and worked fine. We are even able to play a Direct Connect lan game. without any issue.
I do have a concern with multiplayer though, and maybe @InflexCZE can enlighten me. Since I have modified a couple of the games DLL files to get this to work. What are the chances that the game/steam will be able to detect that and think that it is a form of cheating if the game connects to an official/public server? And also what would be the potential other ramifications of having client side players run modified game code that lets some scripts through the whitelist filter?

If this is something that can happen, and I get permission from my Keen contact to distribute such a patch, I would need to make sure people understand not to connect to multiplayer games over the internet, and rather only play local LAN games while this is patched.

You have done a very good work !
Big big thx you for that !

I hope that you can distribute the patch.

As I only play single player I have no problem with the multi player aspect of the game.

I'll leave legal part on ppl responsible for this and focus only on technical aspect of the deal in my response.

As you've had a chance to see on your own, fiddling with the game to make it do something it was never intended to is very easy and for this reason clients can't be trusted. That's philosophy we very strictly follow and entire game is coded as such. Result of that is that servers do all the simulation while client is just an graphical interface that connects human player and server. Clients never compute anything "for server" and never tell it what to do either, they merely relay requests from human. Server will verify each request, perform it and send you back result (or kick you on spot if you do something you are not allowed to).

This applies to requests originated from client-side modes as well. For programmable block scripts the situation is even simpler, they run only on server.

To sum it up, as long as the animal the server observes on the other side of the connection follows protocol and makes valid queries it will be accepted and treated as legitimate client no matter what it _actually_ is.

One thing I'd like to point out tho, there is fixed table of MP queries that both client and server build upon startup. If you modify your game too heavily, you might throw this table off on your side and server will refuse to let you connect. In that case you'll be told that you're using different version of the game than server is running. If you encounter it, you know what's going on.

Well, I'll wait for the potential diff it seems, I'm either doing something wrong with my IL editing or there is another subtle thing happening somewhere, having a confirmed working modified game would probably be a better idea than chasing ghosts. I'm just getting stuck in a loading loop when creating a world. That being said, attaching logs just in case:

SpaceEngineers.txt

Note that it stops at MyDefinitionManager.LoadData() - START, the last line is after I closed the game forcefully. Given that it's mentioning scripts there (though I didn't even enable experimental mode, I wanted to test it without that first) I'm having high hopes that it's just me making mistakes when doing the edits, rather than it being sensitive to Mono versions or whatever.

EDIT: might not be the game, found out yesterday that my HDD is giving up the ghost, so yeah... who knows...

@Linux74656 I have a question. In this video (https://youtu.be/LwqRLCQR6aM) you show the game running pretty smooth on Mono, tho there are some spikes in the frame time graph.

Just out of professional curiosity, could you switch to Modding build (build with profiler) and measure for me what is causing the spikes on render thread and how large the spikes are.

@InflexCZE
It could be due to unoptimized LLVM shader code output. RADV, the free and vulkan driver, uses LLVM by default to compile shaders in game and it's rather prone to stutter.
It may be worth doing a repeat with valve's new ACO branch and seeing if the stutter is still present. Had a similar microstutter in killing floor 2 that ACO fixed.

Space Engineer render captures have been mulled over on the dxvk hit issue tracker before without apparent issue in the API calls.

I would need to get a hold of the diff to test, myself. Waiting on the legal yes/no I guess.

@InflexCZE I have tried the profiler(With the code modifications) in wine-mono without success. It crashes with no error message once I load a world. I have tried it(With the code modifications) with dotnet and I get the same result. I tried both a pre-saved world with experementail mode, and a brand new Crashed Red Ship World without experimental mode.
Logs are attached for the pre-saved world for both mono and dotnet:
LogDOTNETProfiler.zip
LogsMonoProfiler.zip

I also received a response from my Keen contact, and he says since these modifications are being made as a community driven activity, keen has no issue with it. He did emphasize that they have no official support for Linux at this time.
So I would like to take the time to thank @InflexCZE for helping us, in his free time, to get this far. It would have ever been possible without his help!

I am in the process of build a guide to explain how to install these patches. I will post an update when it is done!

Alright I made a simple repository that contains a readme explaining how to install the patches, and the actual patch-files zipped into and archive.
You can find it here:
https://github.com/Linux74656/SpaceEngineersLinuxPatches

@SpookySkeletons If it's something on GPU (poor shaders) or DX API (Proton wrapper) we'd see spikes in "Present" stage (swap-chain) or some specific API call. My guess tho is Mono GC as it's not that well optimized as .NET GC (we did measurements quite recently) and the game is quite heavy on managed object count at this point.

If that's the case, you can expect quite nice improvements in future releases because of optimizations we've made for XBox.

@Linux74656 Quite unfortunate that it's hard crash without any stack-trace. I guess I'll let it go, you'll see if it improves in next releases.

One thing you could try tho is setting environment variable "MONO_GC_PARAMS" for the game process to nursery-size=32m or minor=simple-par or nursery-size=32m,minor=simple-par and observe if that makes any difference in frequency and/or size of the spikes respectively.

In any case it was pleasure to work with all of you and I hope you'll have some quality time with SE 👍
If you need any help in future don't hesitate to ping me.

Thx a lot @Linux74656
But for me atm the game start fine, and when I try to start a map the game crash.
And after that game crash everytime I try to start it...

I have to delete the %appdata% folder to restart...

I will make more test to find what is the problem...
Maybe graphic configuration or something like this.

At least I have no sound issue or bugs on the main menu.
Enabling vsync seem to slow down performances.

That's a big step forward to us to be able to play on our game :)

@InflexCZE I tried your suggestion. It definitely made a difference!
This is nursery-size=32m

This is minor=simple-par

and this is nursery-size=32m,minor=simple-par
(Taken from in game because the menu did not have any spikes. NOTE this spike does NOT have stutter associated with it.)

So it appears nursery-size=32m,minor=simple-par will reduce the spikes quite effectively. I am not quite sure what this means. But I assume it is good.

@LtSich I had a similar experience, only I always got stuck in an infinite loading loop instead of a crash, couldn't load a single map.

I'll give this another try as soon as possible, need to fix my PC tonight though, failing hard drives suck :(

@LtSich Are you running the modSDK build(profiler)? If so use the normal game. I have only seen crashes on load when the bin64 is using the modSDK build

@LtSich Are you running the modSDK build(profiler)? If so use the normal game. I have only seen crashes on load when the bin64 is using the modSDK build

Hum, I remember that I have made some test with that.
I will make a full clean install and try again.

BTW how do you change the MONO_GC_PARAMS variable ?

[EDIT]
And other question, should we continu to use the PROTON_NO_ESYNC=1 %command% to start the game ?
[/EDIT]

You place MONO_GC_PARAMS=nursery-size=32m,minor=simple-par %command% into your steam launch options for the game. Right click Space Engineers, click properties, click SET LAUNCH OPTIONS... then paste it in the box.
I do not have PROTON_NO_ESYNC=1 in my command line, and it seems to work fine.

Thx :)
I'm currently downloading the game after removing everything.
I will be able to tell if this make any difference.

[EDIT]
For me the game is very unstable... Even after removing / installing the game.
Most of the time I can't start the game without removing SpaceEngineers.cfg
And even if I can start the game, I'm unable to start any map / game without crashing...
I will make more test later... To try to find some configuration who don't crash...
[/EDIT]

@Linux74656 Here is a very high level documentation for that magic I suggested before :stuck_out_tongue: You might find it useful, although don't expect wonders
https://www.mono-project.com/docs/advanced/garbage-collector/sgen/working-with-sgen

@LtSich Please provide us with game log so we know what's going on

@InflexCZE I'll take a look at it thanks!

@InflexCZE : I have found the problem to start the game.
I have to disable the anonymous tracking.
If I enable it I can't restart the game.
As long as I say no (I have to say no each time I start the game) I can start the game.

Now I have to try to start a game, or try to join a custom server :)

Do you want some logs when I crash with the anonymous tracking activated ?

I do remember seeing in the logs that it complains about not being able to get the GDPR consent and just timing out on that when I was picking no (that should be visible in the log I posted above). Possibly some web APIs in Mono not being up to snuff / not 100% compatible?

So trying out Linux74656's patch it seems to work, with a few notable exceptions.

1. The intro movie doesn't play (? I guess, donnow) and as a result I spent the first 10mins staring at a blank screen because I thought it was hanging. I clicked and it "skipped" the intro and to the GDPR message (hit no)
2. It will work fine for a while, then suddenly (need to test it more) the game crashes to the desktop, but runs fine Otherwise.
3. A good number of "low sim speed" warnings
   Running Arch Linux with a RTX 2070 and a 8750H (Should be plenty eh?)
   Should be noted that it makes the Laptop sound like a Jet Engine, though that's never shocking :P

@StripedMonkey If you remove or rename the video located at SpaceEngineers/Content/Videos/ksh.wmv then it will skip the intro video and take you to the main menu.
I have had an occasional crash, but I have had it running for several sessions lasting more than 4 hours without issue(Once it starts). The next time it crashes if you could drop the logs here we may be able to figure out what is happening.
Some performance loss is expected when running the game through Proton and DXVK... I have seen some performance issues on a gtx960 and a 4770K, though the slow downs are less noticeable on an rx580 and a R5 2500x. A RTX2070 should have no issues with graphics on medium to high settings, and a 8750H should be able to do gameplay with some basic mods.
When you press Shift + F1 what in particular is it complaining about?

Specifically it says "Reduced Quality of deformations and Voxel changes because of adaptive simulation quality". IIRC the SE logs just have a frequent GC message, but doesn't seem to be related to the instant of a crash. Next crash I generate I'll post the log of.

Personally I think it has something to do with the Sim as the first crash I've really associated anything with was me trying to do a 180 at max speed in the tutorial world. almost as soon as I turned it died. Need to do more proper testing to figure that out though.

I get that message a lot as well. Less so on the RX+R5 computer but still rather frequently. Since you are running a mobile processor... I do not think there is too much you can do to improve performance other than ensuring it is well cooled and properly turboing up to its 4.10Ghz speed. You can also try unchecking some of the in-game settings like air-tightness, and see if that has an impact.

SpaceEngineers.log <- Crashed
Overall the preformance seems fine, ignoring the crashes. So I'm not too concerned about improving that in the short-term. This crash was specifically generated after I went kamakazi on a NPC enemy ship. I crashed almost immediately after I died, (though note I don't always crash on death) I'm not sure what exactly causes it.

The log ends when you died. It seems it did not record the crash.
I quickly tried loading into a world and seeing if I could get it to crash. I slammed three ships into the ground and killed my self four other times with no issue. I have noticed my sister has more issues on her RX+R5 system. If I can figure out why hers crashes more often than mine does... I'll see what I can find out.

I think i got it. Try installing vcrun2005 with winetricks and see if that solves the crashing issues. Also ensure you set your prefix windows version back to windows 7.

I was really hoping to give this a try, but it seems I get a segfault while trying to load up a new world
https://pastebin.com/E7Ha8aCK - steam-244850.log

EDIT//
Pretty dumb, should probably give some kind of details.
Log is cut to just the seemingly interesting bits, most of the log after is just symbol not found messages a billion times over.
System is Slackware64-current, Proton 4.11-6, ran through the posted guide (thanks Linux74656!), including vcrun2005 and setting windows version to Windows 7, though it would crash before that as well.

So with this fix can it be confirmed if mods and multiplayer gaming with windows users works?

@Aerol Try verifying the integrity of your game files then reapplying the patches.

@jarrard Mods will work. Multiplayer with other Linux users will work. I have not tried playing a game with a windows user... but it should work.

@Linux74656 Installing vcrun2005 and Windows 7 resulted in some really bad stuttering, switiching back to winXP seemed to fix it? At any rate I managed to play a good bit longer than I have in the past, although in the end I still managed to crash. Maybe it has something to do with traveling? I really don't know. I was salvaging a station and had a few instances where the sim speed dipped below norm, but then went back. As soon as I left the station and was about to board an abandoned ship I crashed again. This was probably my longest run without a crash, but then again I wasn't moving around a ton, just grinding stuff down and trying to rebuild the ship.

I tried following the steps in your guide and game loads (menu has a small sound spike now and again), however starting a new Earth based world causes the game to fail to start the world and a hang to happen for the process.

Shrug. I followed to the T, https://github.com/Linux74656/SpaceEngineersLinuxPatches

_There was a error while loading the world, check log file._

@StripedMonkey I have win7 on both and I only noticed stutter on my computer. I set it to winxp and the slight stutter vanished. For uniformity i changed the guide to set to WinXP.
Let's try a blanket fix and get everything installed in your prefix that is installed on mine, : I think this is everything I installed in the prefix over time: vcrun2003 vcrun2005 vcrun2015 vcrun2017 xact d3dcompiler_43 d3dcompiler_47 see if installing all of these help.

@jarrard That error message should have been disabled by the patch files... try verifying the integrity of your game files and reapplying the patches.

I did verify before apply patches, guess I'll do it yet again (yes the files were modified by date)

I figured it out, your instructions have a small case insensitive issue.

bspatch VRage.Scripting.dll Vrage.Scripting.dll $HOME/Documents/SpaceEngineers/VRage.Scripting.dll.patch

See the issue :)

@jarrard Thank you! I got, and it has been corrected in the guide!

@Aerol See if this is related to your issue. Reapply the VRage.Scripting.dll.patch using the corrected command bspatch VRage.Scripting.dll VRage.Scripting.dll

Well it seems to progress but sits at 4-5GB memory usage and %50 cpu usage forever, am I to wait half a hour for it to load or something? or just keep trying? certainly the game has stability issues.

Yes this is a known issue. Do not bother waiting for it, it'll never load. Just force close it and try reloading. It will work about 50% of the time. I am working on figuring out what is causing this.

Ok I managed to load into a already saved world from when I was messing around a while back. That seemed to work, maybe just some hangups on creating a new world is the problem, perhaps if I kept trying it would work.

None the less, very playable framerate now, only issue is the crashing/stalling on creating worlds and in my case there is a small audio crackling still, might be some work arounds with pulseaudio I can try there.

Game runs quite well at 4k even with 10k tree's set, just turn off fxaa (use reshade smaa if needed), set shader/shadows to medium, all good. Might even be smoother then windows because under windows I have a weird fps chop even tho its at 80fps or so. (could be fast sync or something doing that).

Also if anyone figures out howto resolve the small audio crackle that happens let me know, I've tried a few pulseaudio settings so far without much luck.

UPDATE: PULSE_LATENCY_MSEC=90 in the command line helped allot for my USB OMNI sound card, now there really isn't any crackling except for the very faint occasional sound hickup which is not annoying. YAY

Unfortunately verifying game data didn't fix anything other than downloading videos again, and I had already ran the proper bspatch commands. :/

If you've verified the game data you will need to reapply the patches if you have not already.

I'm getting the same load screen stall other people are getting and beyond that, too, the very same stall seems to pop up in-game moments after loading an offline world. It runs the CPU at about 40%.
The rendering does not stop and particles still move but the physics engine stops dead, reports low simulation quality, and stalls frame wise for brief periods while it sits and does nothing physically.

No input for menus is accepted at all, I cannot move the character but everything else still renders.

I'm getting the same load screen stall other people

Yes this seems to happen often on generating a new world, if you keep trying it seems to progress differently each attempt. What I found to work %100 is loading up a EXISTING world you made previous, I think you can even download them. But yeah, the hang seems to be largely related to generating a new world atm.

applied the patches on a proton prefix on steamplay,
managed to get to the menu but the game crashes once i try to start any game, i'm also having no sound and unable to alt-tab the game.

where are the .log files located?

Arch lin4.19.69-1-lts
GTX-1070
intel I5-7600K

More than that, loading existing worlds freezes at the screen very very often.

If I do manage to get in game, the entire physics engine just halts and I can't try any of the menus but the frames keep coming and effects keep moving.

Here is a world you can use, goes into your save folder location _(not sure if the number is unique to me, but the folders inside can go into any existing one you have)_. This has worked 100% of the 4 or 5 times I've tried to load it. The file is actually a 7zip file fyi.

spaceengineerssavedworld.zip

@StripedMonkey Done, of course, sadly still segfaults.

@EduardoGodoy Can you add PROTON_LOG=1 to your launch options, run game and check ~/steam-244850.log? Game log is at ~/.local/share/Steam/steamapps/compatdata/244850/pfx/drive_c/users/steamuser/Application Data/SpaceEngineers/SpaceEngineers.log

Managed to get into your save same as mine but same in-game freeze of the physics engine before the suit GUI could load. Is the compiler breaking?

Curious what would stall it out like this...

Hmm, well you can try my compiled files but I don't see how it could go wrong or be any different.
compiledfilesfortesting.zip

If that doesn't work then something else is crashing it for you. Perhaps video drivers? I'm using just the nvidia ones on pop_os plasma5 atm for my 1080TI. (if your using AMD, try forcing proton vendor to NVIDIA)

"The Compiler" should have nothing to do with this.

@EduardoGodoy They're located in the Steam prefix. ~/.local/share/Steam/steamapps/compatdata/244850/pfx/drive_c/users/steamuser/Application Data/SpaceEngineers/SpaceEngineers.log
In order to get this thing installed and running I:

1. Installed winetricks, wine-mono, and bsdiff (Literally never installed Wine before this)
2. Before even running the game for the first time ran WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" winetricks --force -q vcrun2015 xact
   and
   WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" msiexec -i "Downloads/wine-mono-4.9.3.msi"
3. Verify the gamefiles and run

bspatch Sandbox.Game.dll Sandbox.Game.dll $HOME/Downloads/Patches/Sandbox.Game.dll.patch
 ```
and

bspatch VRage.Scripting.dll Vrage.Scripting.dll $HOME/Downloads/Patches/VRage.Scripting.dll.patch
```

1. (Optional) Delete SpaceEngineers/Content/Videos/ksh.wmv to prevent a black screen on loading.

As far as I know this is everything I've done to get it running on arch.
Proton Version 4.11
Wine Version 4.16
wine-mono 4.9.2
winetricks 20190912-1
nvidia driver 435.21

here is the log:
https://pastebin.com/zZ7MzreW

"The Compiler" should have nothing to do with this.

@EduardoGodoy They're located in the Steam prefix. ~/.local/share/Steam/steamapps/compatdata/244850/pfx/drive_c/users/steamuser/Application Data/SpaceEngineers/SpaceEngineers.log
In order to get this thing installed and running I:

1. Installed winetricks, wine-mono, and bsdiff (Literally never installed Wine before this)

2. Before even running the game for the first time ran `WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" winetricks --force -q vcrun2015 xact`
   and
   `WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" msiexec -i "Downloads/wine-mono-4.9.3.msi"`

3. Verify the gamefiles and run

bspatch Sandbox.Game.dll Sandbox.Game.dll $HOME/Downloads/Patches/Sandbox.Game.dll.patch

and

bspatch VRage.Scripting.dll Vrage.Scripting.dll $HOME/Downloads/Patches/VRage.Scripting.dll.patch

1. (Optional) Delete `SpaceEngineers/Content/Videos/ksh.wmv` to prevent a black screen on loading.

As far as I know this is everything I've done to get it running on arch.
Proton Version 4.11
Wine Version 4.16
wine-mono 4.9.2
winetricks 20190912-1
nvidia driver 435.21

here is what i ran to install the patch:

Proton version 4.11-6
NVIDIA-SMI 435.21
wine-4.15 (Staging) (i didn't use wine though)
winetricks 20190615 (i didn't use winetricks too)

from what i see the only difference from my system to yours is that i didn't run "vcrun2015 xact", i'll do it and see if i get this error.

LOG:
https://pastebin.com/zZ7MzreW

Tried cleaning the prefix several times and my md5 matches the patched files.

I load in game and then the same freeze in the load screen takes hold but in-game. Sometimes the first person GUI has a chance to load in and other times not. Can't make any keypresses, look around, physics stops if I am drifting in place it stops dead, no menus, and application eats CPU.

Gentoo with AMDGPU.

Hmmm, you don't happen to have a Zen2 CPU by any chance? Ryzen 3xxx

It's a 4th gen Intel, soon to be a 3rd gen again as I pull out my coreboot laptop. It doesn't have any of the new CPU instruction issues.

Some other (software) component of my system must be messing with this.

from what i see the only difference from my system to yours is that i didn't run "vcrun2015 xact", i'll do it and see if i get this error.

You 110% need to have vcrun2015 et al. Installed.

NVIDIA-SMI 435.21
wine-4.15 (Staging) (i didn't use wine though)
winetricks 20190615 (i didn't use winetricks too)

Your Winetricks version is 3 months old, while it might not have anything to do with the issues we're having It's probably best to have them as identical as possible eh? You also didn't mention a mono version, I assume you installed that too?

@StripedMonkey i ran WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" winetricks --force -q vcrun2015 xact
and then:
WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" msiexec -i "Downloads/wine-mono-4.9.3.msi

this time when i started a game it didn't crash immediately, however i got stuck into the loading screen for 15 minutes (started generating the world at 01:30 local time), no crashes but i conjecture that the game was going to be stuck in the loading screen forever
still had no sound and still wasn't able to alt-tab, had to leave XFCE and kill the process in the terminal.

i didn't mention mono because it's supposed to be installed by default isn't it? also i don't have protontricks to check the mono version on the steam prefix (winetricks shows the version for wine i supose?)

i'll update winetricks to the latest version and check the mono version.

here is the new log:
https://pastebin.com/YNLAK9We
update:
mono version is "mono-6.0.0.319-1"

Try these patches:
NEWPatches.tar.gz
You will need to put the original DLL's into the SE directory before you apply these patches. IE verify integrity of game files if you did not make backups.

If this works I will update the repository with these patches in the morning.

i didn't mention mono because it's supposed to be installed by default isn't it? also i don't have protontricks to check the mono version on the steam prefix (winetricks shows the version for wine i supose?)

Mono != wine-mono. You don't need protontricks installed in order to check it, and (Linux74656's guide specifically mentioned it) it asked for 4.9.3

I can tell you for certain that that mono isn't correct simply because the versioning doesn't match the current release of wine-mono, which released 4.9.3 a week ago

i didn't mention mono because it's supposed to be installed by default isn't it? also i don't have protontricks to check the mono version on the steam prefix (winetricks shows the version for wine i supose?)

Mono != wine-mono. You don't need protontricks installed in order to check it, and (Linux74656's guide specifically mentioned it) it asked for 4.9.3

I can tell you for certain that that mono isn't correct simply because the versioning doesn't match the current release of wine-mono, which released 4.9.3 a week ago

how do i check wine-mono? from searching on google i only see questions related to "mono not found" errors.

Try these patches:

If this works I will update the repository with these patches in the morning.

What changed?

@Linux74656 With this new patch I'm getting a "Please update your .net runtime with this hotfix:\nhttps://support.microsoft.com/kb/3120241\n\nThe game will not run correctly otherwise

ok, I have try a lot of things, but I can't go in any game :(
Can't create a new game, can't join a game on a windows computer, can't try to load a saved game (downloaded here).

Here are some logs when I try to create a new game : https://dl.cafe-philo.net/logsse.tar.gz
I didn't find anything usefull in thoses logs, but maybe that I don't look at the right place.

The prefix is configured as the doc say, have try winxp or win7.
Try to add other component (crun2003 vcrun2005 vcrun2015 vcrun2017 xact d3dcompiler_43 d3dcompiler_47)

I have notice the small error on VRage and Vrage and reapply the patch.

I have try to start a game with a lot of different options (experimental, sound, scripts, etc).

I have installed mono-devel, but this doesn't change anything.

I will come back later, maybe I have miss something...

I have installed mono-devel, but this doesn't change anything.

as mentioned previously wine-mono != mono-devel. did you install it from https://github.com/madewokherd/wine-mono/releases ?

I have installed mono-devel, but this doesn't change anything.

as mentioned previously wine-mono != mono-devel. did you install it from https://github.com/madewokherd/wine-mono/releases ?

Yes yes, I have install that with wintetricks as mentionned in the documentation.
But to be sure I have install mono-devel as my game continu to crash when I try to start something.

I was able to start a new alien world this time around, all fine. So I decided to try and join a MP server (local no mods) and it appeared to be loading but ended up crashing after 20seconds :(

SpaceEngineers.log

@jarrard Have you've tried loading into a windows server? The log says clearly, the MP table is off (the issue I mentioned before)

Regarding the game freezes, if you manage to take a dump of the game while it's in this state (or anything else you usually do on Linux to inspect internal state of a process) it might tell us what's going on.

the MP table is off (the issue I mentioned before)

Sorry no idea what your talking about, it was the Australia server 2 which worked under windows.

[...] there is fixed table of MP queries that both client and server build upon startup. If you modify your game too heavily, you might throw this table off on your side and server will refuse to let you connect
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-536186685

Or it's just another problem with different BCL that comes from Mono. In either case it looks like it's not gonna be so trivial to make cross-play work.

Alright. @SpookySkeletons

What changed?

The new patches are from the correctly modified binaries. Let's just say I was TheBigDumb<sup>tm</sup> and took a short cut when modifying the decompiled code, by actually modifying the C# code methods and recompiling it(Without the full source... I know right!). This time I just used the Intermediate Language editor to modify the binaries. It seems to have fixed many of the startup hanging that has occurred. I learned my lesson. No more shortcuts if I do not know exactly what I am doing!

@StripedMonkey

@Linux74656 With this new patch I'm getting a "Please update your .net runtime with this hotfix:\nhttps://support.microsoft.com/kb/3120241\n\nThe game will not run correctly otherwise
You can try just reapplying the patch to Sandbox.Game.dll. Though I would just reapply both patches to new original copies of the dll files.

@LtSich The new patches will probably fix your issues with world loading. Also I do not think the mono version will make a difference(so long as it is newer). I just included it in the guide for uniformity, to ensure everyone would be running the same version if errors occurred.

@jarrard Unfortunately it looks like multiplayer with windows computers will be unavailable at the moment. But i can confirm that if you play with other Linux computers that have this patch the game runs pretty well.

I have updated the guide repository here: https://github.com/Linux74656/SpaceEngineersLinuxPatches to include the new patches. Everyone should re-follow the guide and apply the new patches. Make sure you apply the patches to the original DLL's(IE verify game integrity, or copy the backups you made back into the Bin64 directory)

I nearly flipped my desk until I realized space engineers just had an update :smile: If your game updates to the newest version the patches will not work. I will compile so new one PROPERLY! and put them on the repo.
@InflexCZE is there a way to tell which version of the game is on the computer without running the the game? This will be helpful to ensure people are apply the correct patches.

Unfortunately it updated behind my back :sweat_smile: Guess I gotta wait for those new patches.

I'm afraid that game version is baked into the binary and there is no extra "Version.txt" or anything like that.

@Linux74656

cat $HOME/.local/share/Steam/steamapps/appmanifest_244850.acf | grep buildid | cut -f 4 | sed -e 's/"//g'

A bit clumsy, probably a nicer way to do it using awk (I should really lean awk!), but it works to get the current installed build number. The newest build number can be retrieved using steamcmd if your plan is to write a launch script to check on each run or something, see: https://steamcommunity.com/app/346110/discussions/0/530646715636738547/

I'd recommend requiring some sort of JSON parser if you're going that route though, grepping through that is far too fiddly, for my taste at least. Come to think of it, Python should work nicely for this, it's installed on pretty much every distro anyway.

Alright i uploaded the new 1.192.103 patches. If your game has updated you need to apply these patches instead of the others.
@Onyx47 do you think a simple checksum verification on the dll's would be effective enough? I could try writing a script to compare the users DLL's to a list of pre-generated checksum, that should in theory correspond to the version of game installed. Perhaps it then could automatically run bspatch and install the correct version for the user.

@Linux74656 would work I guess, but I was honestly thinking something simpler might work:

1. A script for generating patches that:
   
   
   
   • Takes the original DLL, modified DLL, creates a patch and puts it in an archive named something like SE_Linux_$buildnumber.tar.gz
   
   
   • Uploads the file somewhere, whether it be GitHub or some other server
   
   
2. A script for the user that:
   
   
   
   • Reads the current installed version and checks if a file called SE_Linux_$buildnumber.tar.gz exists on a server / GitHub.
   
   
   • If it 404s the patch doesn't exist yet
   
   
   • If it exists, download it, apply it, write a file somewhere (SE data dir would probably be safest) that contains the latest patch number that was downloaded. This can be used in the future to check if anything needs to be downloaded on the next run.
   
   
   • If everything is fine (or no patching is required), run the game through Steam
   
   

Some verification of the files is still an option somewhere in the whole process, of course, but this seems like the smallest amount of work required on both sides of the equation once the scripts are written. The only downside of this is that it wouldn't handle updates, so maybe the launching part is something that's better to keep in Steam, so it updates in there and the user can just run the patcher if an update lands.

I have a server with enough free space and unlimited bandwidth I can provide for the cause if we decide not to use GH for them, just need to set up an FTP account for the upload part and it should be fine.

I can probably bang out something usable tonight, as soon as I get my machine back in running order.

well, new patch or not my game continu to crash...
Using Debian testing... Well... That sad for me....

@LtSich I have a hunch on the crashing issues. Try deleting you wine prefix. Reinstall the mono version listed in the guide. Then only install vcrun2017 and xact.
I checked the space engineers steamdb page and vcrun2017 is the only listed vcruntime. I have it(and many others) installed on my system and have very rare crashes.

is there already a solution for scripts? i can not connect to any server where scripts are running.
the update works very well. thx

@LtSich I have a hunch on the crashing issues. Try deleting you wine prefix. Reinstall the mono version listed in the guide. Then only install vcrun2017 and xact.
I checked the space engineers steamdb page and vcrun2017 is the only listed vcruntime. I have it(and many others) installed on my system and have very rare crashes.

Thx for the tips, but that doesn't change anything... Well, I will just sit in the back and wait for God blessing, maybe this will work :)

I hope multiplayer with windows machines can happen at some point. Seems bit of a shame really.

I've bought and installed Space Engineers to see if it would finally work. I followed the instructions to patch the game.

I was able to get to the main menu as expected, but I was unable to actually start a Scenario or a Custom Game. The game got to the loading screen, did some loading for maybe about 5 to 10 seconds and then the process stopped running. I'm not sure where to look for the issue. Here are some log files but I can't really seem to learn anything from them:

SpaceEngineers.log
steam-244850.log

@dsge do me a favor. Verify the integrity of your game files.
Save a copy of this file : https://github.com/Linux74656/SpaceEngineersLinuxPatches/blob/master/autopatcher.py to your desktop or downloads folder. Then open the terminal/Konsole in the same directory and run:
python3 autopatcher.py

It is not complete but it should at least be able to patch your game for now.
Let me know of the results.

I'll be contributing to the autopatcher in a bit if you don't mind @Linux74656. At least python I know I can help with :P

Well, turns out a big chunk of what got corrupted on the old HDD was Steam stuff so I'm redownloading the game just in case. Started some work on basic stuff in the patcher while I'm waiting, we'll figure out pull requests and merges as we go since I see @StripedMonkey is helping as well.

@StripedMonkey, check my fork if you don't mind, see that we don't duplicate the work if not needed ;) (Note: I don't really do Python ever other than fixups like this so some of my stuff might not be best practices). We should probably start tracking that stuff in that project too so we don't pollute this issue thread any more.

Well, you certianly had some of the same issues with it :P although you went about it a different way. I'll actually create an issue on the Patches page so we can leave here for dealing with SE troubleshooting itself.

I welcome the help from anyone when it comes to this! I have very little experience in python.

@Linux74656 I've verified the game files and ran the py file (version 7f742ac1):

$ python3 autopatcher.py
Please insert your install location for Space Engineers. Should look somthing like this /home/USER/.local/share/Steam/steamapps/common/SpaceEngineers/ 
/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/
b6d168be7e38640817f8d7f1de523346
cf4b860b7917fa53d8c95e0c6a377451
VERSION FOUND: 1.192.103
https://raw.github.com/Linux74656/SpaceEngineersLinuxPatches/master/V1.192.103Patches.tar.gz
Program End!

I did not touch my wineprefix, it's still in the same state as it was after the original instructions.

This time the game is really unstable. Previously (when I installed the hacks manually) I could get to the main menu and the loading screen on every try and it only crashed after that. This time I had multiple places where the game crashed (aka the game window and the process just disappears) on subsequent runs:

• after the splash screen
• after pressing "No" on the data collection dialog
• and after the loading screen.

I did about 15 tries and I was unable to actually go past the loading screen. I have not managed to get ingame at all, not once.

These logs were made when I managed to get to the loading screen before the game crashed:
SpaceEngineers.log
steam-244850.log
( Should I even post these? I have no idea what to post that would help )

This is actually known issue, when you say "No" to data collection the game starts crashing (Linux only).
Delete game appdata (to reset the decision, backup any worlds or BPs if you have), agree next time game asks and you should be good to go.

It was my understanding it's actually the opposite. Hitting "yes" makes it crash. :thinking: (as someone who always has hit "no")

@InflexCZE If I say "yes" then I get the same result after that (process disappears after loading screen), however on the next run the game crashes on the splash screen with the actual crash reporter:

See the end of this message for details on invoking \njust-in-time (JIT) debugging instead of this dialog box.\n\n************** Exception Text **************\nSystem.ComponentModel.Win32Exception (0x80004005): Sikeres.

  at System.Diagnostics.Process.StartWithShellExecuteEx (System.Diagnostics.ProcessStartInfo startInfo) [0x00102] in <f508ff7dc2d3475abfc25b6b60600edf>:0 
  at System.Diagnostics.Process.Start () [0x00032] in <f508ff7dc2d3475abfc25b6b60600edf>:0 
  at (wrapper remoting-invoke-with-check) System.Diagnostics.Process.Start()
  at System.Diagnostics.Process.Start (System.Diagnostics.ProcessStartInfo startInfo) [0x0001b] in <f508ff7dc2d3475abfc25b6b60600edf>:0 
  at System.Diagnostics.Process.Start (System.String fileName) [0x00006] in <f508ff7dc2d3475abfc25b6b60600edf>:0 
  at VRage.Platform.Windows.Forms.MyMessageBoxCrashForm.linklblLog_LinkClicked (System.Object sender, System.Windows.Forms.LinkLabelLinkClickedEventArgs e) [0x00010] in <6669c852ae2c4f45a64d6d2ce7411724>:0 
  at System.Windows.Forms.LinkLabel.OnLinkClicked (System.Windows.Forms.LinkLabelLinkClickedEventArgs e) [0x00020] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.LinkLabel.OnMouseUp (System.Windows.Forms.MouseEventArgs e) [0x000fb] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.Control.WmMouseUp (System.Windows.Forms.Message& m, System.Windows.Forms.MouseButtons button, System.Int32 clicks) [0x001c3] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x005a0] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.Label.WndProc (System.Windows.Forms.Message& m) [0x0005d] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.LinkLabel.WndProc (System.Windows.Forms.Message& msg) [0x0001b] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.Control+ControlNativeWindow.OnMessage (System.Windows.Forms.Message& m) [0x00001] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x000b3] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.NativeWindow.Callback (System.IntPtr hWnd, System.Int32 msg, System.IntPtr wparam, System.IntPtr lparam) [0x00030] in <2880ee803a384afc84fc95657b396772>:0 

\n************** Loaded Assemblies **************\nmscorlib\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/4.5/mscorlib.dll\n----------------------------------------\nSpaceEngineers\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/SpaceEngineers.exe\n----------------------------------------\nSandbox.Game\n    Assembly Version: 0.1.1.0\n    Win32 Version: 0.1.1\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/Sandbox.Game.dll\n----------------------------------------\nnetstandard\n    Assembly Version: 2.0.0.0\n    Win32 Version: 4.6.26011.1\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/netstandard.dll\n----------------------------------------\nVRage.Render\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Render.dll\n----------------------------------------\nVRage.Steam\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Steam.dll\n----------------------------------------\nVRage\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.dll\n----------------------------------------\nSpaceEngineers.Game\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/SpaceEngineers.Game.dll\n----------------------------------------\nSystem\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll\n----------------------------------------\nVRage.Library\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Library.dll\n----------------------------------------\nSystem.Xml\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll\n----------------------------------------\nVRage.Math\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Math.dll\n----------------------------------------\nVRage.Game\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Game.dll\n----------------------------------------\nVRage.NativeWrapper\n    Assembly Version: 0.1.1.0\n    Win32 Version: 0.1.1\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.NativeWrapper.dll\n----------------------------------------\nSandbox.Graphics\n    Assembly Version: 0.1.1.0\n    Win32 Version: 0.1.1\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/Sandbox.Graphics.dll\n----------------------------------------\nSandbox.Common\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/Sandbox.Common.dll\n----------------------------------------\nSystem.Core\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll\n----------------------------------------\nVRage.Platform.Windows\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Platform.Windows.dll\n----------------------------------------\nSystem.Windows.Forms\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System.Windows.Forms/4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll\n----------------------------------------\nSteamworks.NET\n    Assembly Version: 13.0.0.0\n    Win32 Version: 13.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/Steamworks.NET.dll\n----------------------------------------\nSharpDX\n    Assembly Version: 4.2.0.0\n    Win32 Version: 4.2.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/SharpDX.dll\n----------------------------------------\nSharpDX.DXGI\n    Assembly Version: 4.2.0.0\n    Win32 Version: 4.2.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/SharpDX.DXGI.dll\n----------------------------------------\nSystem.Runtime\n    Assembly Version: 4.1.2.0\n    Win32 Version: 4.6.25714.01\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/System.Runtime.dll\n----------------------------------------\nSharpDX.Direct3D11\n    Assembly Version: 4.2.0.0\n    Win32 Version: 4.2.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/SharpDX.Direct3D11.dll\n----------------------------------------\nVRage.Ansel\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Ansel.dll\n----------------------------------------\nProtoBuf.Net\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/ProtoBuf.Net.dll\n----------------------------------------\nProtoBuf.Net.Core\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/ProtoBuf.Net.Core.dll\n----------------------------------------\nSystem.Reflection.Emit.Lightweight\n    Assembly Version: 4.0.1.0\n    Win32 Version: 4.0.0.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/4.5/Facades/System.Reflection.Emit.Lightweight.dll\n----------------------------------------\nSystem.Reflection.Emit.ILGeneration\n    Assembly Version: 4.0.1.0\n    Win32 Version: 4.0.0.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/4.5/Facades/System.Reflection.Emit.ILGeneration.dll\n----------------------------------------\nAnonymously Hosted DynamicMethods Assembly\n    Assembly Version: 0.0.0.0\n    Win32 Version: n/a\n    CodeBase: \n----------------------------------------\nSystem.Drawing\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System.Drawing/4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll\n----------------------------------------\nAccessibility\n    Assembly Version: 4.0.0.0\n    Win32 Version: \n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/Accessibility/4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll\n----------------------------------------\nSystem.Configuration\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll\n----------------------------------------\n\n************** JIT Debugging **************\n

I had to edit my SpaceEngineers.cfg's GDPRConsent field back from True to False to move past this.

Or my memory is failing me. Ignore me, I should go sleep :upside_down_face:

EDIT:
In any case it would be good to track "known issues" somewhere along with "known solutions".

Update for those who can get into the game. install vcrun2003 ontop of your working prefix. This may resolve crashing while you are in the game. The best way to test this is to create a creative version of world Alien planet world, get into the deterrent fighter, and start shooting the nearby smaller ships with missiles. This has seemed to reliably cause crashing on my sisters computer until I installed vcrun2003. Put the game under as much stress as possible and if it does not crash, load into another world and try again. If it still does not crash i think this is the issue.

As for the people who still can not get into a game world due to crashing and freezing. Let us try a blanket install of everything in my winetricks history, that would be on-top of the mono version in the guide.
winetricks --force -q vcrun2003 vcrun2005 vcrun2015 vcrun2017 msxml6 xact d3dcompiler_47 corefonts dxvk winxp

Let me know if anything changes!

@Linux74656
I validated my files again. Then I did:

$ rm -rf /media/egyteras/SteamLibrary/steamapps/compatdata/244850/pfx

$ WINEPREFIX="/media/egyteras/SteamLibrary/steamapps/compatdata/244850/pfx" winetricks --force -q vcrun2003 vcrun2005 vcrun2015 vcrun2017 msxml6 xact d3dcompiler_47 corefonts dxvk winxp

$ WINEPREFIX="/media/egyteras/SteamLibrary/steamapps/compatdata/244850/pfx" msiexec -i "./wine-mono-4.9.3.msi"

$ python3 autopatcher.py
bsdiff is installed!
Cannot locate install directory. Please input the steamapps folder location where Space Engineers is installed.
/media/egyteras/SteamLibrary/steamapps/
BuildID: 4246126
checksum.json Retrieved
Patches Retrieved
Program Complete!

( autopatcher.py version is the one from Linux74656/SpaceEngineersLinuxPatches#5 )

Unfortunately the behaviour after this is still the same as my previous comments: the game crashes left and right and I am unable to get through the loading screen.
Log files show no change as far as I can tell:
SpaceEngineers.log
steam-244850.log

I did a quick test then and my game crashed on loading, I did apply the new patches for v103 but perhaps I will verify again and re-attempt it.

@dsge Thanks for the fix to the autopatcher! Could you tell me your OS version, kernel version.

@Linux74656

steam_systeminfo.txt

Moved my game to the NVMe, redid the patch. Seems to work good second attempt anyway.
I really hope the developer of Space Engineers can make these patches work with windows multiplayer servers, I feel that's pretty important issue to overcome.

@dsge Try running the game with this config file:
Don't change any settings until after you try loading an empty world.

EDIT: Use this one instead, the other one was in french(I don't actually speak french but i was seeing if the game acted differently with other localization... it does not seem like it does).
SpaceEngineers.cfg.zip

Yea I was wondering why the french locale would be better suited to run the game :D

So the custom game called "Empty World" does load up:

(I was not aware that there was literally a custom game by that name, as I said I just bought the game yesterday.)

Other custom games do not seem to work, however I only had 1 crash out of the 8 tries I did on other custom games. The other 7 times I got stuck on the loading screen. By "stuck" I mean that I could see in Gnome System Monitor that the game does not actually reads or writes anything from my drive and uses 50% cpu (aka fully uses 2 of my 4 cores).

System Monitor that the game does not actually reads or writes anything from my drive and uses 50% cpu (aka fully uses 2 of my 4 cores).

Yeah that's typical of what you experience when it decides it isn't going to load. I've had it plenty of times but I can normally get in on the second try. Not sure why its always failing for you. It relies on mono to do the world compile job so perhaps mono is breaking on your system for larger workloads.

You can set different parameters for mono on loadup, atm I use _MONO_GC_PARAMS=nursery-size=32m,minor=simple-par %command%_

OK we are making progress.
I have noticed that my sister's computer has the same loading issue from time to time. But my computer does not. I did not think much of it as it was only a minor inconvenience, but it may be related so I'll see if i can fix it on hers.

I'm having issues loading anything still. Didn't manage to launch a world a single time, regardless of multiple attempts and doing various things.

I was tailing the SE logs as I was trying, and it seems like it's connected to loading definitions most of the time, not particular ones from what I see, just definitions in general - sometimes it loads voxel definitions fine, sometimes it loads nothing, and then it just hangs. I had one run where it actually loaded everything and tried to start a session, but then it crashed.

I'm kinda stumped at the moment, no idea if trying to attach any kind of mono debugger would give us anything useful, since this build doesn't have debugging symbols, but at the moment it seems to be wildly inconsistent, both between loads on a single system and between systems themselves.

While I'm happy this all gave us at least some insight, and I do hope we figure out if Mono is at least a temporary viable solution, I'm half tempted to just try and go back to dotnet and see if following Wine logs can reveal what exactly is tripping the GC up and see if we can fix that in Wine instead...

You can set different parameters for mono on loadup, atm I use _MONO_GC_PARAMS=nursery-size=32m,minor=simple-par %command%_

@jarrard I tried that just now. Unfortunately the only difference I noticed is that now the game is back to 100% crashing after the loading screen (meaning that it does not get stuck there). "Empty World" still loads up just fine, no change there.

OK we are making progress.
I have noticed that my sister's computer has the same loading issue from time to time. But my computer does not. I did not think much of it as it was only a minor inconvenience, but it may be related so I'll see if i can fix it on hers.

@Linux74656 Thank you and everyone who is spending time on this. Quite a few of my friends play this game and I would really like to try it out to see if it's good. At least in single player for now.

@InflexCZE Do you think people could try installing these patches into their windows versions of the game? That would allow some people to play with windows users, the one that create their own custom games.

EDIT: Also is there some way to temporarily disable garbage collecting while running dotnet? If disabling it removes the stutter then we will know what the issue is.

@dsge Verify your game files. Do not apply the patch and instead create a new prefix to run the game with the following command:
winetricks --force -q vcrun2015 xact dotnet472

If you can launch the game into a world with this then your problem is most likely related to wine-mono and the patches.

@Linux74656 You can try, but I doubt that the changes you've made would cause such a huge difference to the MP table as I've seen in the logs. There is ton of plugins and community projects for SE that perform thousands of small patches or straight up replace entire methods and systems and it works fine with vanilla clients.

Imho this is another issue coming from differences in Mono BCL. Unfortunately fixing this one, as opposed the the script compiler, would be much more tricky, mainly because of serialization.

Regarding the GC, it's very essential system that tracks and reclaims memory that is no longer used by the game so it can be recycled and used again (Yes, very green-thinking system, mother nature is proud :stuck_out_tongue: ) I'm sure there is a way to instruct .NET FW GC to allocate new memory from OS instead of trying to identify and reclaim bits that are no longer used (aka instead of doing the all performance intensive stuff) but be advised, you're looking at RAM consumption somewhere in a neighborhood of +500GB just to get into empty scene. So unless you have a really future proof PC or Linux knows some pretty damn good magic regarding swapping, I don't think it's a good idea to go this way. In any case, trying to manually configure it with proper parameters, same as we did with Mono GC before might fix it.

Alternatively you could try .NET Core. Last I've heard it runs very well on Linux and it should be very compatible with .NET FW, even in BCL. Last we've tried it was able to run SE dedicated server _almost_ out of the box so who knows, maybe it might work even better than Mono.

@InflexCZE I'll give dotnetcore a try and see if it cooperates.
I'm looked into the documentation of how the dotnet GC works. The image shown in this section talking about threading: https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals#what-happens-during-a-garbage-collection acts similar to the profiling shots i tried to get. A single core jumps to 100% usage while the rest seem to significantly decrease in usage or stop. Could this be a coincidence?

@InflexCZE I was more thinking of checking the logs to see which calls to native Windows libraries are not completely implemented in Wine and just see if those can be filled in properly and whether that would help. A lot of stuff in Wine's implementation of Windows API is just stubbed and implemented just enough to get things working initially, and is getting slowly filled in with time.

As for .NET Core, we'd still need to run it under Wine (at least VRage parts). I mean, VRage itself relies on WINAPI, right? And I'm also suspicious about ABI being compatible since it's a Windows application after all. Also, we still need to translate those DirectX calls to either OpenGL or, prefferably, Vulkan. That's maybe something that can be done independently of Wine, I didn't read up on it.

Arguably, whatever Wine bugs plague .NET 4.7 would also affect Core, since we'd have to run the Windows version of it anyway. And do note, current use of Mono for SE is not us running native Linux Mono and just feeding the SE executable to it, it's actually a build made specifically for Wine, and is actually a Windows application.

Also, since I do use .NET Core for Linux development (but I don't deal with low level stuff in .NET enough to be knowledgable about that part of it), I can tell you that yes, the code will mostly run fine, but there are many things that don't work cross-platform: there's no Windows Forms of course, some things like System.Drawing now exist as a nuget package but are not 100% compatible... Basically, something like a service you'd run on a server? Should work. Anything graphical? Not really.

I'm sure there is a way to instruct .NET FW GC to allocate new memory from OS instead of trying to identify and reclaim bits that are no longer used (aka instead of doing the all performance intensive stuff) but be advised, you're looking at RAM consumption somewhere in a neighborhood of +500GB just to get into empty scene.

Based on my (admittedly limited) experience I'd actually think that zram might actually be able to handle compressing the empty scene while leaving GC still off. If it's similar data (and I'd assume for an empty scene it would be) then it should be fairly easily compressible. Obviously not a great solution, and may affect pref. But I think it would actually be an interesting thing to try.

Let me clarify. Game does not prealocate that much mem just for case it's needed. It would be that much of random bits of memory used during the loading of empty scene, but not needed any more. GC is able to find these bits and recycle through the lifetime of the process (~every few frames). Without it, they will lay there and eat up space forever.

@Onyx47 You're right, I didn't realize at the moment that Core will actually not shield us from need of Win APIs and running Win build on top of Proton would prolly suffer from the same issues as .NET FW.

@Linux74656 It could mean anything. Could be GC or could be render going full balls while simulation is stuck or something.

I did a quick search online, unfortunately it looks like that .NET FW GC doesn't offer any configuration options (at least not any that would be worth it, fixed heap size, Gen 0 size, thread allocation for collection works, ...) so unless you have some more tricks up your sleeve on how to profile/identify the peaks I guess we're out of luck here :(

@InflexCZE If I set the fixed heap size, and or Gen 0 to something ridiculous like 25gb (one of my systems has 32gb of ram) would that prevent the garbage collector from running for at least a few seconds?
If so how would I set it to do that?

Yes, fixed heaps of some insane size should reduce GC frequency greatly (in exchange for slight increase of collection time _when_ it actually happens and ridiculous memory consumption ofc), but as I've said it doesn't seem that .NET GC supports any kind of such (manual) configuration, unfortunately.

I understand now. Sorry for all of the confusion.

@dsge Verify your game files. Do not apply the patch and instead create a new prefix to run the game with the following command:
winetricks --force -q vcrun2015 xact dotnet472

If you can launch the game into a world with this then your problem is most likely related to wine-mono and the patches.

@Linux74656 I did just that, here are the results.

I am getting this twice before the splash screen and once if I exit the game through the menu (pressing "yes" takes me here - thanks Microsoft I guess):

Other than that, the game starts. I was able to start any Custom Game that I've tried.

The game stutters at very regular intervals (not quite visible on my screenshots because taking a screenshot momentarily messes with the frame timings and the fps reported by dxvk hud) which also causes stutter in any sound that's currently playing. On an empty world it was less frequent (about once per second) and on a more built up world it was at least 2-3 times per second. Other than the stuttering I seem to have 120fps (every graphics option is set to the lowest possible value) without much of a problem on my system (specs).

My overall impression is that technically the game works but that stutter makes it very annoying to play.

@dsge Yeah... the stutter is why we started using wine-mono.
At least we know that the issues with launching into the world are related to wine-mono and the patches.

Yepp I know, it's also why garbage collection is being discussed. I just wanted to document that at least with dotnet472 I am getting pretty much the same result as everyone else does. Unlike with wine-mono+patches which for whatever reason seem to work much better for you than it does for me.

There's a lot going on in this thread, what's the right way to run this at the moment? I installed xact dotnet472 to get it running but it stutters pretty hard on my rig, I see mentions of a patch?

The current process is mentioned here (not super clean rn though, I'll work on the readme in a bit if Linux doesn't). Basically install vcrun2005, xact, wine-mono, and either use the patch tool to apply Linux's patches or do it manually with bspatch. Currently cannot do Linux-windows multiplayer but linux-linux seems to work.

@InflexCZE What does <gcServer enabled="true"> do exactly? Would it break the game in anyway that I might not understand? I added it to some files and it seems to have solved the dotnet stutter issue. It can't be this easy... nonetheless since this has something to do with garbage collection, as long as what I changed did not break other cpu intensive parts of the game, I assume the stutter in dotnet has been GC related all along. Unless there is something else I am missing(considering how late it is this is very possible :smile:),

where is the _gcServer enabled="true"_ setting? that in a config somewhere?

Did you test it against windows mp servers to see if you can join them (best test on server with no mods to start with).

MS is pretty vague about what the server GC preset actually does, but from what I can tell it tries to leverage more cores (that are usually present on server machines) and allocates bigger memory segments which would result in less frequent triggers of GC traded for increased overall mem consumption of the process.
https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals#workstation-and-server-garbage-collection

Feel free to experiment with it, it's high improbable that you would break anything in game with GC settings, at worst it could start crashing.

This is actually an interesting find. Reading a bit myself (pasted from the docs):

For single-processor computers, the default workstation garbage collection
should be the fastest option. Either workstation or server can be used for
two-processor computers. Server garbage collection should be the fastest
option for more than two processors.

This makes me think that, while GC might be impacted running under Wine, is it possible that the part of the problem is also related to the scheduler? IIRC, many people have reported that the game only uses 50% of the CPU even though it's struggling (and I think that also happened to me), while I'm sure I saw it hit at least 80% on Windows on my rig. Maybe it's just the problem of GC running on the same core as the rest of the game while it doesn't happen natively because Windows scheduler handles stuff differently and/or Linux scheduler doesn't know it's thread safe (possibly because multiple things that are separate on a real Windows system all might be running under wineserver process on Linux) so it refuses to move it to a different core?

I'll test this tonight on my end and report the results. If it works that would be great news! Especially since I don't see a reason for this not to be turned on in the game itself, given its requirements I think we can pretty much count on everyone playing having a multicore system, or at the very least a hyperthreaded one which should still improve performance. Yes, I know the docs mention multiple processors, but with modern CPUs that line is blurry anyway, is it not?

Hello I have:
<Runtime> <gcServer enabled = "true" /> </Runtime>

inserted at the end of my SpaceEngineers.exe.config and the game is now running with .net already 4 hours without stuttering.
Also in multiplayer on a windows server.

Can someone else try that?

@Onyx47 SE is able to effectively leverage only ~2.5 up to 4 threads, depending on scene complexity. It's well known issue coming from old architecture of used engine. If you don't see it scaling well with number of provided codes, it doesn't _necessarily_ mean it's fault of anything in your Linux setup. More likely our technical debt.

My guess from the beginning is that the sefl-tuning mechanism of the GC is failing because of some incorrect data feeded to it from Proton side and it is very possible that this issue doesn't manifest in server mode. Whatever the actual culprit actually is doesn't really matter tho, as long as it runs well :smile:

I'm very glad that even crossplay with Windows works fine. Scripts and mods work too, right?

I have just tested scripts.
works in multiplayer and singleplayer.
Even with mods no problems

my gpu load is a bit higher than in windows

I see a spike every 10-20 seconds in my dxvk hud, even a slight fps drop, 5-10 fps but the average is between 50-60 with vsync and high settings (GPU RX580 8GB)

Then you just installed dotnet472, xact and make the change in the config ?
That's all ? You can use the last proton version ?

installed packages: protontricks 244850 -q --force vcrun2005 vcrun2015 dotnet472 xact
steam launch settings: DXVK_HUD=full PROTON_NO_ESYNC=1 %COMMAND% -skipintro

Proton: 4.11-6
Kernel: 5.0.0-30-generic Ubuntu 19.04

Update: sry i forgot dotnet472

ok, on my side apparently I can't install vcrun2015, I've got this error :
Note: command /home/sich/.steam/steam/steamapps/common/Proton 4.11/dist/bin/wine vc_redist.x86.exe /q returned status 102. Aborting.

but, I have installed dotnet472 and added the <gcServer enabled = "true" /> inside the Runtime and now it's work very well :)

I tested 2/3 mods and apparently it's ok for that.

But adding this at the end of the .config file doesn't work. :

<Runtime>
  <gcServer enabled = "true" />
</Runtime>

I have change the config file like this at the end :

    </assemblyBinding>
  <gcServer enabled = "true" />
  </runtime>

Thx for the tips.
If you know how to increase the memory usage (I have 32gb) just tell me, it will probably help.

the end of my config looks like this:

  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
  </startup>
  <runtime>  
    <gcServer enabled="true"/>
  </runtime>
</configuration>

ok, it's inside the configuration then.
It's probably the same, as long as we stay inside the configuration.

But I wasn't able to do anything without dotnet472.

@diKsens So it appears I do not need to add it to all of the config files (Sandbox.Game.dll.config and VRage.Game.dll.Config). Only SpaceEngineers.exe.config. That is good to know.

I can confirm that scripts do in-fact work, and that connecting to windows servers(keen na) works without issue.

Can I please ask for one SE log from .NET FW? Just regular log after game successfully starts.

@InflexCZE Here you go!
SpaceEngineers.log

I am still convinced something is going on behind the scenes. I used the speed enhancement mod and took the crashes red ship and slammed it into another asteroid at 300m/s and the game had practically no issue with it. I will keep testing.

_Game had no performance issues when I did something it was designed for._
Is that a bad thing or what? 😛

Oh... I thought the game limited ship speed to 100m/s because of performance issues?

It depends. Throw this against a planet and expect impact sometime tomorrow this time. It will tank sim speed really hard even on decent rigs.
https://steamcommunity.com/sharedfiles/filedetails/?id=501767620

I notice one thing here that I also saw under Mono (but thought it might just be a Mono thing):

2019-10-03 09:27:06.247 - Thread:   1 ->  GC Memory: 1,857,883,240 B
2019-10-03 09:27:06.251 - Thread:   1 ->  Process Memory:  B

Maybe worth investigating on the Wine front, GC might be using a similar call into WINAPI and getting no data?

This call queries NtQuerySystemInformation (SystemProcessInformation):
https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntquerysysteminformation

If you know where, can you check if it's correctly implemented or just stubbed?

Well with that little config file fix it works now, pretty damn good in fact. Even joined a MP server, no problems.

vcrun2015 didn't install for me either but perhaps its already installed by steam? either way this is awesome. From trash rating on protondb to gold basically :)

https://source.winehq.org/git/wine.git/blob/a8745d1211033dd38682e2f4e8bc322d47a15e0f:/dlls/ntdll/nt.c#l2373

Seems to be implemented but it does include a fixme as well, don't have enough time to look deeply into what might be wrong with it (if anything is, other than how it gets memory usage in the first place smelling badly) right now.

@InflexCZE For the lolz I did this:

It depends. Throw this against a planet and expect impact sometime tomorrow this time. It will tank sim speed really hard even on decent rigs.

And I see your point :smile:

I am still astonished at how much the game has improved since I last played it properly in windows(roughly a year and a half now.) You and the other space engineers developers have taken this game further than I ever thought possible. Thanks for all the hard work you all put into this game.

There are some new space engineers type games coming out that seem to fix the physic limitation problems that SE has, such as speed limits and collisions causing all hell to break loose. It be nice if something was done for the VRage engine but I suspect its just not possible.

@InflexCZE I was silly and was looking at the wrong part of code, I assume this is the actual relevant part:

https://source.winehq.org/git/wine.git/blob/a8745d1211033dd38682e2f4e8bc322d47a15e0f:/dlls/ntdll/nt.c#l2460

Looking at docs a bit, I'm assuming PrivatePageCount is the relevant property? Which doesn't seem to be set anywhere.

@jarrard Anything is possible given enough time and resources. Unfortunately our team is small so we have to make a choice. Either we deliver new content and gameplay, or we do a deep changes to the engine and implement new state of the art technologies that emerged in last years.

We believe that our players will currently appreciate more if we focus on the first one and once the time comes to significantly improve technology it'll prolly come hand in hand with announcement of new game so we don't have to maintain backwards compatibility for every little thing we change (which usually consumes most of time).

(No, we are not abandoning SE now, we're still working on it 😄 )

@Onyx47 I see. That could explain some things

@InflexCZE : that's a good way to go.

Just if you can think to our little linux community when you work on your new game that can be a very good thing :)
Just that we can play with Proton without too much trouble, like it seem we can probably do with Space Engineers soon :)

Because with Medieval Engineers we can't even start the game...
I hope that this will not be the case with your next game !

Now that Space Engineers is playable on Linux I will be able to completly remove Windows, just before the end of life for Win7, just perfect :D

And BTW, thx to every people working so hard to find solution for Space Engineers !
Thx to you @InflexCZE to join us here and for all the help you have provide !

Since this seems to be a far more stable solution to getting Space Engineers to run I redid the repo and readme all of the mono stuff we worked on is is a sub-directory in this repository, should we ever need to come back to it.

Thanks again to everyone for helping figure this out. It has been an interesting journey :smile:

@LtSich The decision to not pay any special attention to Linux is very simple, money. This applies to all studios universally. Either an engine game uses supports Linux out of the box, in that case the game "supports Linux" or the engine doesn't support it, in that case nobody really cares and focuses only on major platforms. Developers are expensive and <1% market share speaks clearly.

As for the case of VRage, we're now supporting also XBox so we had to restructure engine quite a bit to make it platform agnostic. This means that by implementing limited interface, the game will be able to run on any platform that can run .NET, thus, if you encounter any issues with our future games you can just re-implement this interface with proper Linux calls and have a good time with a new game.

We may be <1% but I think we're pretty loud for being such a small group :P

We may be <1% but I think we're pretty loud for being such a small group :P

And determined!

Yeah, well that won't pay my dinner, is it? 😛

Yeah, well that won't pay my dinner, is it? stuck_out_tongue

I'm ok with a crowfunding to collect money to make some change on the game to run better on Linux... I'm sure a lot of people will be ok to give some money to have the game run smoother on Linux...

And the problem is that you make a game for Windows, and after that you try to make it run on Linux...
To make a game that run multiple plateform you have to think about that from the start.. And don't use Windows only tools.

And don't forget that Google Stadia is soon here, and it's on Linux servers...
Being able to run the game on Proton / Linux give the ability to sell the game on Google Stadia...

And about Windows... Win10 is a plague... A lot of people would like to go on Linux to avoid that...
I work with Linux servers for more that 10 years now, but I only use it on my computer for 1 year now... Because I don't want to use Win10...

But don't worry, I fully understand why KSH don't support Linux.
And I'm very grateful for the help you give :)

Oh and here is a good post from a linux dev, it's interesting to read :)
https://beardedgiant.games/benefits-of-supporting-linux-if-you-are-a-small-indie-developer/

We are more than 1%. Steam survey is borked. I'm completely Windows free for 10 years and I got the survey just once. One more thing - don't count on statistics from Net Marketshare etc. Many Linux users still have to use Windows user agent for various reasons.

Hi folks, while it's nice to see a servicable workaround has been figured out, let's try to keep this compatibility report focused on the game. Feel free to discuss the general state of gaming on linux on the forums.

If you are still open to conversation regarding even potential considerations for Linux support for future Keen releases, would it be possible to have a channel of some sort on the Keen discord (I remember that existing a while back) to handle this type of topic so we do not derail this Proton issues thread too much from the intended purpose, as kisak has said we are? I think there could be interesting discussions to be made in that regard especially since the landscape of graphics programming (vulkan) and dotnet is changing.

After following the instructions the game seems to work for me as expected and the vast majority of the annoying stuttering is gone. There are still some leftover issues with the audio at least, but it's nothing I cannot live with.

Check it out: https://youtu.be/RBqQAkYWBGA?t=60 :tada: :tada: :tada:

Thanks again to everyone who helped find those workarounds!

I confirm success as well! Some graphics crashes currently, but not sure if it's the game or running it in Proton, since those happen sometimes even on Windows, sadly...

Can confirm that the above fix works on my end, adding just the following to my SpaceEngineers.exe.config file resolves the frequent performance drops and the game runs at a solid 120fps for me at high settings on my i7-7700k/GTX 1070. Multiplayer works fine as well.

Also need to install dotnet472 and xact via winetricks or protontricks.

<runtime> <gcServer enabled="true"/> </runtime>

\ already exists for me so I just had to put the \

After switch back to .NET FW with server GC, do you experience any startup issues like on Mono, hangs in loading screen, crashes or anything?

After switch back to .NET FW with server GC, do you experience any startup issues like no Mono, hangs in loading screen or anything?

dotnet472 does not have that issue for me. Everything works as expected so far in that regard. I can reliably start the game and start any Custom Game that I've tried.

Personally, I had a crash when starting a new world once and two crashes that threw out a graphics driver crash dialog (the driver didn't actually crash on the system, might've just been DXVK giving up), but past that it was a pretty smooth experience.

Spent a few hours playing a MP game in a modded world with 5-6 other people about, messed with scripting while there, and this was all hosted on a Windows machine (just a local world on a friend's machine, not DS).

There were spikes here and there that still might be related to GC, but it was running at pretty stable 120 FPS on my 3GB 1060 and Core i5 4460, all while running in a window with compositing turned on in my desktop environment. Went lower later as we started building a lot, not surprising, not sure how much of a performance loss was due to which factor at that point.

Overall, I'd call it completely playable :+1:

Yeah I think this qualifies it for a Gold rating on ProtonDB, which is works pretty well with minor tweaks.

Wow, this has really blown up (my email). Congratulations on finding a fix/work around, I was able to launch and play with dotnet472 and xact, set gc config option, and ended up needing PROTON_NO_ESYNC to prevent crash while loading.
I've submitted a report to ProtonDB with a gold rating. Thanks for your perseverance Linux74656, and for the insight InflexCZE!

So is vcrun unnecessary or do some people still need it?

i didn't install vcrun2015, but steamplay may have installed it already, didn't check.

The game run fine for me.
I can create a game with mods, scripts are ok.

I wasn't able to install vcrun2015, but with dotnet472 and the config change it was fine.

I think vcrun2015 is installed by Steam as a prerequisite when first launching. It probably also tries to install dotnet, but that requires some hackery in 64bit prefixes that's handled by winetricks so that's why we still need to run that separately. As for xact I think that might be preinstalled or comes as a part of DirectX or something on Windows. With time, we might be able to skip that as well, but FAudio doesn't support the file format used by SE yet, so we're stuck with native Windows libraries for now.

FAudio is meant to replace Xact but it seems it doesn't work in this case.

@jarrard from what I read on their features page, it's probably the XWM file format, the regular version that gets installed by Steam doesn't support it.

Interestingly enough, since I happen to know Skyrim uses the same file format, I went looking and found this:

https://github.com/Kron4ek/FAudio-Builds

Seems like someone built it with WMA support and it reportedly works in Skyrim. Might be worth trying that for SE as well, that means we'd get rid of one more native requirement.

worth a try, I'll give it a shot sometime, dunno when, chances are 10 of you guys will beat me to it, if so let us know how it goes. (Faudio with WMA).

As a shortcut I heard proton-GE has faudio with wma already in it, but could be wrong.

@Onyx47 try installing d3dcompiler_47 into your prefix. I had an occasional graphics crash as well, but after installing that it seems to have gone away(of course it was so infrequent to begin with it still could happen).
Also I just created a new prefix using winetricks to install faudio instead of xact, It seems to have solved the popping audio. I'll modify the guide to include both of these if it seems to fix peoples issues.

what is required to allow the movie files to play that the game uses?

It seems that actual playback of .wmv files is not likely for now. you can check the issue #1464 for more information.
I have tried installing media foundation and using/overriding various dll's from a windows 7 laptop. It did not have any impact on the play back.
I don't know what kinds of video formats the game can load, but I have tried converting the intro into a few dozen different types, back when I thought the stutter might be related to the audio and the background videos on the main menu, nothing really came of it. I am sure someone will figure out in time... but for now just disabling the intro video is the best option.

Tried Proton-GE and it just ctd on loading a world so that doesn't seem to work if anyone was wondering. Guess I'll need to compile my own faudio, also its worth noting the game sound itself works fine without faudio wma support, the wma support is what the MUSIC uses.

https://github.com/Kron4ek/FAudio-Builds

I overlooked that there are compiled releases.. oops, yeah compiling it yourself is a headache, gotta set a half dozen dependency paths which I don't fully understand. (I can compile the basic faudio but wma support requires 5 extra path configurations)

@jarrard I installed faudio through winetricks (in a fresh prefix without xact) and it seemed to work fine.

ok maybe winetricks/protontricks uses the wma supporting version which is good since without ffmpeg support it kinda makes faudio very limited.

Confirming that faudio from winetricks works for me as well :+1:

Okay, so faudio clearly works better, but there is one thing left that is really bugging me.
Whenever a ship arrives at your location for example, its engine sounds will persist and loop over and over until you either load another area or quit.
Haven't played survival yet, but this at least occured in the campaign. Precisely, I remember it happening in this exact moment: https://youtu.be/6MihPOJUrQ4?t=2623
Of course, the persistent engine sounds occured whenever there was an engine going off, if I remember correctly, but this scene should make it possible to replicate the issue.

I've had issues with "stuck" sounds on Windows, though not as often as you make it sound. Which means, two things:

1. Before beginning to troubleshoot it as a Proton issue, we need to establish a scenario that reliably produces a stuck sound in Proton but not Windows
2. It may ultimately not be strictly a shortcoming in Proton, but slight differences in timing causing a race condition to be hit more often. If so, it will be pretty much impossible to troubleshoot and will disappear overnight if Keen manages to fix the original bug.

Whenever a ship arrives at your location for example, its engine sounds will persist and loop over and over until you either load another area or quit.

Perhaps redo your prefix with XACT and test that scenario again a few times and see if it occurs there. If it only happens with faudio then it could be a bug report needed in that section for it?

I've had similar issues with sound blocks, sound not ending but rather just echoing the start of the sample. For example, a sound that should play for 2 seconds would play for 1.5 seconds, and then the first 0.5 seconds would play again, instead of the final 0.5 seconds (numbers for illustrative purposes only of couse, didn't time it). And this was with xact, didn't get to test it with faudio yet. Can anyone confirm?

If this happens with xact as well, might just be a Wine bug, or possibly PulseAudio bug. If anyone still runs pure ALSA on a system, could they try to repro this?

I get this error message when I attempt to launch the game or when I run the WINEPREFIX command.
Is it possibly cause I have --force run the command several times in the same prefix with both xact and FAudio.
I recently switched to Linux and I am not familiar with Wine or any related programs like Proton or Winetricks. I've got a Linux buddy ( who got me to switch finally) who has helped me out so far.

Edit: I got the game to work (for a second time, first time I had it working too but with very obvious and obnoxious sound bugs. The audio would be delayed, as if the sound file had to fully finish playing before playing the next one in a queue style. So when you built a lot fast it would queue the sounds and play them one at a time meaning that when you stopped placing/welding, the sounds of construction would continue until all sounds had played). I don't know what I did to get the game to work this time in particular but the game runs relatively smoothly with one problem. The audio is clearly bugged still but not quite in the same way as before. The sound is muffled at some parts and sound file is cut off at beginning/end sometimes and some sounds wont play at all at random.
I still get the error message when I launch the game.

When I add "PROTON_NO_ESYNC %command%" to the launch parameters it does not launch at all. Just says "Running" then "Syncing" and back to nothing.

I tried to install xact and dotnet472 using winetricks or protontricks. dotNET install is corrupted and game needs dx11. (ArchLinux fella)

probably outdated winetricks

@CrafterSvK You can try to create a prefix using dotnet48 (This will require the latest winetricks version, winetricks --self-update) I have used it instead of dotnet472 and it seems to work the same. Although I still do get the rundll32 popups on start, just hit no when ever it pops up and the game should start fine.

can you tell wine to disable rundll32?

I tried disabling it and it seemed to work. The error no longer appears, and the game seems to run alright with limited testing.

yeah I think I got that error a few times also, not sure why it happens.

I tried winetricks --self-update nothing changed and installed dotnet48, os version is now windows xp which is weird primusrun %command% instantly crashes, ENABLE_PRIMUS_LAYER=1 optirun %command% seems to generate window for 1 second and intel graphics does nothing. :/ (I have 64-bit prefix, is it an issue?) This seems to be issue that I can't really get to work Vulkan on my Laptop. I have managed to run it on integrated graphics but only menu. After I load game, it crashes.

Finally back on PC. @thorsten-passfeld when you reproduce the infinitely looping sounds again, can you please check this screen (Ctrl+F11) to see if you find the sound that's bugging you there. The game logs here all sounds the are currently playing, at least from its PoV.

If the sound is there, it means bug in the game. If not, most likely it's somewhere in XAudio re-implementation and we should track it there.

Ofc the simpler the scene, the better for debugging.

@CrafterSvK Can you please zip up and upload the logs for the crash, both SpaceEngineers.log and VRageRender-DirectX11.log.? They should be located at "INSERT/DIRECTORY/TO/SPACEENGINEERS/pfx/" + "/drive_c/users/steamuser/Application Data/SpaceEngineers/"

Also if you could post your system specs from steam "Help>System Information", into a txt file and upload it , that may be helpful.

info.zip
Here you go. Thank you very much. (I am currently doing stuff to school but later today I am going to try nvidia-xrun opposed to bumblebeed with primus_vk)

Looks like issue with video player. Try deleting (or renaming) all videos in "SE_INSTALL_PATH/Content/Videos/*" and see if gets you any further.

@CrafterSvK Which nvidia graphics card does your laptop use? And do you have the proprietary Nvidia drivers installed?
Neither of these are listed in the steam info.
Also the game runs 64bit so a 64 bit prefix is required so it is fine that your prefix is 64bit. It also seems that most users have more stability when the prefix windows version is set to winxp, so this is normal as well.

Well, steam shouldn't run on nvidia graphics when bumblebee is used. I installed nvidia-xrun everything works fine and stable. 70 fps at lowest settings with 950M

@CrafterSvK Good to hear! Glad it works well!

Everything runs nice and smooth, visually, however there is a very perceptible audio crackle, and it's quite distracting - both the music and the ingame sfx have the problem..

The audio problems have been discussed extensively in this discussion and there are solutions to reduce the problem. Just need to read above your post! for the most part using faudio for many works, sometimes you need to fiddle with pulse audio sync timings also.

@Linux74656 Prolly should be added to the guide too

Got it! The issues section of the guide has been updated!

Update: The PULSE MSEC thing didn't work for me. It looks like I have an older sound card that doesn't properly support the glitchless pulse playback (TIL!). I found alternative instructions here: https://www.reddit.com/r/wine_gaming/comments/83j0mh/wine_and_pulse_audio_latency/dvk60mp/

Basically, change the pulseaudio config to load with tsched=0 and smaller (apparent) fragments makes the audio sound perfect. This now gets a gold rating on proton. Brilliant stuffs. 6 months ago I tried and it couldn't even start. :+1:

There are issues with keyboard focus when in fullscreen (even in "windowed fullscreen"). If I try to switch to another window/app, the game immediately reclaims keyboard focus. This is a bit of an issue when copy/pasting ingame scripts from an outside editor. The workaround I found is to temporarily switch to a window when I need to get out of the game.

However, the clipboard DOES work, and it does look like ingame scripts are 100%.

As requested earlier, we now have special channel dedicated to SE on Linux on our official KSH Discord. Feel free to join us there:
https://discord.gg/keenswh

Just for information, I have far better result with xact against faudio.
On the last test I have installed xact and xact_64.
And I have made the change mentionned here : https://www.reddit.com/r/wine_gaming/comments/83j0mh/wine_and_pulse_audio_latency/dvk60mp/

And honestly the game run very very well.
Few audio bug when I start the game, and after few minutes all is running fine.

With faudio I have some strang audio lag, it's very annoying.
And it seem to impact performance.

Maybe this depend on the hardware or the system, I don't know...
But people who have trouble with faudio should try with xact.

There are issues with keyboard focus when in fullscreen (even in "windowed fullscreen"). If I try to switch to another window/app, the game immediately reclaims keyboard focus. This is a bit of an issue when copy/pasting ingame scripts from an outside editor. The workaround I found is to temporarily switch to a window when I need to get out of the game.

However, the clipboard DOES work, and it does look like ingame scripts are 100%.

That's actually a problem on Windows too, so nothing Wine/Proton/Linux specific.
There's a few bug reports floating around somewhere on that problem.
It's very nice when I switch to notepad or discord to type something, and the game starts triggering a bunch of actions too. /s

We've found the issue on Windows and it'll ship with next patch of the game.
Hopefully it'll fix the issue on Linux as well.

I modified the guide and wrote a new(heavily modified the old one) autopatcher to fulfill a different purpose, it will now patch the config file for you, then (try to) create the prefix. It should be at least mostly functional. Hopefully this will help reduce confusion on prefix creation for some of the newer or inexperienced users.

After using the autopatcher i'm able to launch and play - however it hitches every 2 seconds or so. Using the full DXVK hud it shows a red line in the graph every time it hitches. Other than that, I get around 70-90 fps on Earth.

i7 6700k, 1080ti, 32gb DDR4 3200mhz

Did it look like This?

Did it look like This?

Yea it does, where do you set that?

its mentioned how, just read down a few posts. you use the steam launch command thing.

its mentioned how, just read down a few posts. you use the steam launch command thing.

Yea sorry, it was hidden (https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-536643269)

Set my launch options to: MONO_GC_PARAMS=nursery-size=32m,minor=simple-par DXVK_HUD=full PULSE_LATENCY_MSEC=60 %command%

Still getting it, here is what the graph looks like:

I think this is only usefull with mono : MONO_GC_PARAMS=nursery-size=32m,minor=simple-par
Did you try to build your prefix with xact instead of faudio ?
I have far better performance with xact... Faudio I have the exact same issue that you...

Yes, it's only for mono.

@matty-r please check if autopatcher executed steps 3&4 correctly (e.g. the GC server is present in your config) https://github.com/Linux74656/SpaceEngineersLinuxPatches/blob/master/README.md#step-3

Yes, it's only for mono.

@matty-r please check if autopatcher executed steps 3&4 correctly (e.g. the GC server is present in your config) https://github.com/Linux74656/SpaceEngineersLinuxPatches/blob/master/README.md#step-3

That's what did it. Just needed to add gcServer enabled="true" to the .config file. Works perfectly now. Amazing.

Thanks.

@matty-r If autopatcher failed for some reason it would be good to know why so it can be fixed for others. Any error messages when you applied it? Also, can you tell us full path to the config file on your system? Apparently the path differs on some systems.

@matty-r If autopatcher failed for some reason it would be good to know why so it can be fixed for others. Any error messages when you applied it? Also, can you tell us full path to the config file on your system? Apparently the path differs on some systems.

I tried re-running it, but it looks like it applies the gcServer setting now - bit odd. It did however stop working completely after I re-ran it and would just show the crash report dialog after the splash screen. I had to manually re-add gcServer, and deleted KSH.wmv .

So not really sure why it broke the first time around - the path matches the concatenated string in the Python script file.

I just successfully got Space Engineers working pretty easily on Linux, using a little bash script based on @Linux74656's Python script.

I'm running Fedora 30 on a system with an AMD RX 580 GPU.

Of note is that I actually couldn't get it to work unless I _didn't_ install vcrun2015.

Here's what you do:

1. In your Steam library, right click Space Engineers -> properties -> check "Force the use of a specific Steam Play compatibility tool" and choose "Proton 4.11-7", then click close.
2. Install SE.
3. Start SE, wait for the error about an outdated library, click OK. SE should create a wine prefix when it does this.
4. Go to a Bash shell, and run the command below.
5. If everything in step 3 succeeds, start SE. It should work now.

Bash command for step 3:

export WINEPREFIX=~/.steam/steam/steamapps/compatdata/244850/pfx && winetricks --force -q d3dcompiler_47 && winetricks --force -q faudio && winetricks --force -q dotnet48 && winetricks --force -q winxp && sed -i 's/<runtime>\r\?$/<runtime> <gcServer enabled = "true"\/>/' ~/.local/share/Steam/steamapps/common/SpaceEngineers/Bin64/SpaceEngineers.exe.config && mv ~/.local/share/Steam/steamapps/common/SpaceEngineers/Content/Videos/KSH.wmv{,.bak}

That seems overkill. All I really had to do is launch game and let it error (to generate the initial prefix), protontricks 244850 -q dotnet472 xact, manually edit SpaceEngineers.exe.config, and it Just Works(TM).

Of note this didn't seem to work with Proton 4.2, but I wanted to use 4.11 by default anyway.

Hold on, you're specifically trying to use FAudio, aren't you? I missed that. d3dcompiler_47 or winxp shouldn't be necessary, though. (I'm surprised winxp doesn't break the game, to be honest.)

Windows XP is required to get the game to run. I've been unable to get it to work on Windows 7 or above.

Hello @duckinator, I'm glad that the game runs well for you.

Currently we have another user over on our Discord that's having problems with winetricks on Fedora (Line 443):
https://pastebin.com/5Y1s7xjG

Can you share with us what version of winetricks you use?

@roothorick based on your comment, I deleted the wine prefix so I could try again.

Turns out, this is enough to make it work for me:

WINEPREFIX=~/.steam/steam/steamapps/compatdata/244850/pfx winetricks -q dotnet48 xact && sed -i 's/<runtime>\r\?$/<runtime> <gcServer enabled = "true"\/>/' ~/.local/share/Steam/steamapps/common/SpaceEngineers/Bin64/SpaceEngineers.exe.config

Adding the -skipintro launch option to Space Engineers isn't required, but makes it so it skips the startup video which doesn't play. If you don't set that option, it plops you at a black screen and you need to click or press a key to continue.

@InflexCZE here's wine + winetricks version info:

~$ wine --version
wine-4.17 (Staging)
~$ winetricks --version
20190912 - sha256sum: 31d37bf18f1503ec46cedf8889e447901e746454e9c3de465f9cc57193e0c90b
~$

My simplified one above may work better, just due to doing fewer things. Also, they'll probably want to run rm -rf ~/.steam/steam/steamapps/compatdata/244850/ and then re-run the game once (to get it to regenerate the wine prefix) before trying again.

~Using your workarounds, the game will only work for about one second after loading a world, where it would then freeze but the audio keeps on playing.~

EDIT: it works fine after re-launching.

Here's some info about my system in case it's relevant:

• Ryzen 7 2700
• AMD Radeon RX 580
• 16GB RAM
• Running Fedora 30
• Steam is installed from the RPM Fusion repos

Someone I know with similar hardware (Ryzen 7 1700, Radeon RX 580) successfully got it working on ArchLinux using my last comment but I'm not sure if they needed to do anything extra beyond that.

@duckinator Your one liner above totally worked for me on F30. Game runs nearly flawlessly. I'm on a 2700X with an RTX 2070

Having issues with copying GPS coords to clipboard. I can do it once, but any time after that when I click the copy to clipboard button it locks up for a couple seconds and does not copy the coords to the clipboard.

Is this on Wayland Matty?

Is this on Wayland Matty?

Nah, x11.

I've been getting two other issues:

1. After exiting the game from the main menu, it hangs in the background and doesn't actually close. Steam continues to report Space Engineers is running.

2. After about 30 mins of play, any mouse movement becomes jittery. I can move the character around fine with using the keys and experience no problems, but as soon as I look around with the mouse it's jittery again. Exiting the game and relaunching fixes the issue temporarily.

Hello @matty-r, the second part reads like #3316, see https://github.com/ValveSoftware/Proton/issues/3316#issuecomment-565734041 for a workaround.

Hello @matty-r, the second part reads like #3316, see #3316 (comment) for a workaround.

Thanks mate, I'll give that a crack tomorrow and see how it goes.

Hello @matty-r, the second part reads like #3316, see #3316 (comment) for a workaround.

G'day @kisak-valve , that appears to have resolved both the hanging on exit and mouse movement issues on one machine (Yet to try the other, but i'm confident it will work there also), thank you for that.

The only issue I have seen now is https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-565758685 - Unable to copy gps co-ords to clipboard after the first attempt.

After exiting Space Engineers, a process remains open in the background and steam reports that the game is still running.
Proton 4.11-11

After exiting Space Engineers, a process remains open in the background and steam reports that the game is still running.
Proton 4.11-11

Same here, the game run fine, but I need to manually kill a lot of process after playing (wine, spaceengineers, ..).

Same here, and killing the processes is not enough to make steam say that I'm not playing it anymore, have to kill steam as well. So weird.

For everyone with still playing problem - find and kill the SteamChildMonit process, that doesn't close properly either and that will make Steam stop showing you're playing the game.

Killing the processes is not the problem.
but it came with the 4.11-10 update and is still there.

Killing a process will solve the problem. Something, whether it be SE
itself or one of the various dummy processes, is hanging.

Mind you, that doesn't solve the root cause but it works

On Thu, Jan 2, 2020, 10:32 AM diKsens notifications@github.com wrote:

Killing the processes is not the problem.
but it came with the 4.11-10 update and is still there.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1792?email_source=notifications&email_token=AB5DMRGXZSSVUSETAH4RG6LQ3YCHTA5CNFSM4F6IMNRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH6TJ6A#issuecomment-570242296,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5DMRAEVHS5P3XPDP2QZN3Q3YCHTANCNFSM4F6IMNRA
.

I could not start the game initially, to get it working with Proton version 4.11-11 I had to install latest version of winetricks with the command wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks && chmod +x winetricks && sudo mv -v winetricks /usr/local/bin then execute the script wget https://raw.githubusercontent.com/Linux74656/SpaceEngineersLinuxPatches/master/autoprefix-patcher.py && python3 autoprefix-patcher.py

System:    Host: asimov-MacBookPro Kernel: 5.4.6-050406-generic x86_64 bits: 64 compiler: gcc 
           v: 9.2.1 Desktop: Cinnamon 4.4.6 wm: muffin dm: LightDM Distro: Linux Mint 19.3 Tricia 
           base: Ubuntu 18.04 bionic 
Machine:   Type: Laptop System: Apple product: MacBookPro13,3 v: 1.0 serial: <filter> Chassis: 
           type: 9 v: Mac-A5C67F76ED83108C serial: <filter> 
           Mobo: Apple model: Mac-A5C67F76ED83108C v: MacBookPro13,3 serial: <filter> UEFI: Apple 
           v: 263.0.0.0.0 date: 10/30/2019 
Battery:   ID-1: BAT0 charge: 52.4 Wh condition: 53.3/76.7 Wh (70%) volts: 12.7/11.5 
           model: SMP bq20z451 serial: N/A status: Full 
           Device-1: hidpp_battery_0 model: Logitech Wireless Keyboard serial: <filter> 
           charge: 55% status: Discharging 
CPU:       Topology: Quad Core model: Intel Core i7-6920HQ bits: 64 type: MT MCP arch: Skylake-S 
           rev: 3 L2 cache: 8192 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 46398 
           Speed: 3363 MHz min/max: 800/3800 MHz Core speeds (MHz): 1: 900 2: 900 3: 900 4: 900 
           5: 900 6: 900 7: 900 8: 900 
Graphics:  Device-1: AMD Baffin [Radeon RX 460/560D / Pro 450/455/460/555/560] vendor: Apple 
           driver: amdgpu v: kernel bus ID: 01:00.0 chip ID: 1002:67ef 
           Display: x11 server: X.Org 1.20.4 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa 
           resolution: 1920x1080~60Hz, 1920x1080~60Hz 
           OpenGL: 
           renderer: AMD Radeon RX Graphics (POLARIS11 DRM 3.35.0 5.4.6-050406-generic LLVM 7.1.0) 
           v: 4.5 Mesa 18.3.0-rc4 direct render: Yes 
Audio:     Device-1: Intel 100 Series/C230 Series Family HD Audio driver: snd_hda_intel v: kernel 
           bus ID: 00:1f.3 chip ID: 8086:a170 
           Device-2: AMD driver: snd_hda_intel v: kernel bus ID: 01:00.1 chip ID: 1002:aae0 
           Sound Server: ALSA v: k5.4.6-050406-generic 
Network:   Device-1: Broadcom and subsidiaries BCM43602 802.11ac Wireless LAN SoC vendor: Apple 
           driver: brcmfmac v: kernel port: 3000 bus ID: 03:00.0 chip ID: 14e4:43ba 
           IF: wlp3s0 state: up mac: <filter> 
           IF-ID-1: docker0 state: down mac: <filter> 
Drives:    Local Storage: total: 465.92 GiB used: 104.53 GiB (22.4%) 
           ID-1: /dev/nvme0n1 vendor: Apple model: SSD SM0512L size: 465.92 GiB speed: 31.6 Gb/s 
           lanes: 4 serial: <filter> 
Partition: ID-1: / size: 455.46 GiB used: 52.10 GiB (11.4%) fs: ext4 dev: /dev/dm-1 
           ID-2: /boot size: 704.5 MiB used: 319.2 MiB (45.3%) fs: ext4 dev: /dev/nvme0n1p2 
           ID-3: swap-1 size: 979.5 MiB used: 25.0 MiB (2.6%) fs: swap dev: /dev/dm-3 
Sensors:   System Temperatures: cpu: 76.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/additional-repositories.list 
           1: deb [arch=amd64] https: //download.docker.com/linux/ubuntu bionic stable
           Active apt repos in: /etc/apt/sources.list.d/amdgpu-pro-local.list 
           1: deb [ trusted=yes ] file: /var/opt/amdgpu-pro-local/ ./
           Active apt repos in: /etc/apt/sources.list.d/graphics-drivers-ppa-bionic.list 
           1: deb http: //ppa.launchpad.net/graphics-drivers/ppa/ubuntu bionic main
           Active apt repos in: /etc/apt/sources.list.d/kubernetes.list 
           1: deb https: //apt.kubernetes.io/ kubernetes-xenial main
           Active apt repos in: /etc/apt/sources.list.d/lutris-team-lutris-bionic.list 
           1: deb http: //ppa.launchpad.net/lutris-team/lutris/ubuntu bionic main
           Active apt repos in: /etc/apt/sources.list.d/nodesource.list 
           1: deb https: //deb.nodesource.com/node_10.x bionic main
           2: deb-src https: //deb.nodesource.com/node_10.x bionic main
           Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
           1: deb http: //ftp.acc.umu.se/mirror/linuxmint.com/packages tricia main upstream import backport
           2: deb http: //archive.ubuntu.com/ubuntu bionic main restricted universe multiverse
           3: deb http: //archive.ubuntu.com/ubuntu bionic-updates main restricted universe multiverse
           4: deb http: //archive.ubuntu.com/ubuntu bionic-backports main restricted universe multiverse
           5: deb http: //security.ubuntu.com/ubuntu/ bionic-security main restricted universe multiverse
           6: deb http: //archive.canonical.com/ubuntu/ bionic partner
           Active apt repos in: /etc/apt/sources.list.d/skype-stable.list 
           1: deb [arch=amd64] https: //repo.skype.com/deb stable main
Info:      Processes: 307 Uptime: 2h 31m Memory: 15.54 GiB used: 2.85 GiB (18.4%) Init: systemd 
           v: 237 runlevel: 5 Compilers: gcc: 7.4.0 alt: 7 Client: Unknown python3.6 client 
           inxi: 3.0.32 

Game won't start with NVIDIA GPU using proprietary drivers (tested on 435 and 440), but it does using integrated AMD GPU (poorly).
I keep getting the "Update windows or your gpu drivers" dialog.

• wine version 5.0-rc3 (tried with 4.0.3 as well)
• winetricks version 20191224-next
• proton version 4.11.11

Logs:
SpaceEngineers.log
VRageRender-DirectX11.log
steam-244850.log

Try a proton-tkg release and see what happens. I think NVIDIA cards are typically spoofed as AMD cards but maybe that is no longer happening, you can manually spoof your GPU to AMD.

I'm not sure if this method still works for proton but these are for AMD (just search the values).

dxvk.conf in game directory:
dxgi.customDeviceId = E366
dxgi.customVendorId = 1002

I just tried using proton_tkg_5.0rc5.r0, but it doesn't work even with the dxvk.conf file.

I'll give it a test drive soon on tkg.

Using Proton GloriousEggrolls 4.15-ge-1, seems to make the game recognize my actual GPU, but VRageRender keeps failing:
VRageRender-DirectX11.log
SpaceEngineers.log

UPDATE: My problem was fixed thanks to @Linux74656 :

• Wineprefix contains faudio vcrun2015 dotnet48 and d3dcompiler_47.
• Proton 4.11.12
• Steam game parameters: DXVK_FILTER_DEVICE_NAME="GeForce"

I can't seem to start it with all the patches and recommendations, and I can't tell why even with the log information:
steam-244850.log

Can anyone help me out?
System Information

Hello @MajorLunaC, err:module:fixup_imports_ilonly mscoree.dll not found, IL-only binary L"SpaceEngineers.exe" cannot be loaded looks like the line of interest from your log. It looks like .NET support broke somewhere in your tinkering.

System:
AMD 2700X watercooled
32GB DDR4 3200MHz CL18 RAM
RX VEGA64 watercooled
Game on SSD

OS Manjaro kernel 5.5 Mesa 20 git (with RADV_PERTEST=aco in game launch), Wine 5 RC4
compared to Win10 1909

Games is running, but randomly crashes, proton log generates 50-150+MB each run, game render feels stuttery till its not running at 120 FPS. and on same settings, the game considerably running slower (70+ FPS stabel on Win, 28 on Linux. 4k High settings preset. On same location in the same world save.)(After loading it up again, it gave me in fps counter 60 fps, yet the game felt stuttery, just like before. If like the render would run fine, but the game engine is in a shitty performance state.)
Windows-VRageRender-DirectX11.log
Windows-SpaceEngineers.log
LINUX-VRageRender-DirectX11.log
Linux-SpaceEngineers.log

proton log (50MB)
Google Drive

Yes I remember the stuttery feeling even tho FPS was high. I can't remember for sure if I fixed it or not but you might want to try enabling vsync.

Hi @kisak-valve , I actually haven't tweaked anything beyond SpaceEngineersLinuxPatches. I've tried Steam's default fixes which fail the exact same way, then the commands listed in this issues conversation, as well as SpaceEngineersLinuxPatches. From what I've gathered, it seems likely that .NET is not installing properly - See How to install .NET 4.5 on 64-bit prefixes, and I'm not even clear on when WinXP mode or Win7 mode should be enabled during installation and run (apparently it makes a difference). I think the issue might be from different versions of Winetricks which gets installers from different sources.
I have Winetricks 20191224-next, and I cleared /HOME/.cache/winetricks/ so new versions would download. Supposedly .NET is supposed to provide a new version of mscoree.dll that's over 100 kb if it installed correctly, but it never seems to change. One semi-workaround is that I download the newest version of mscoree.dll (version 10 something) from <Link removed by moderator> and put it directly inside SpaceEngineers/Bin64/ (as well as ucrtbase_clr0400.dll and vcruntime140_clr0400.dll which it asks for after), and the game starts and I can navigate the game menus. It crashes the game sometime while loading a new game with the following in the SpaceEngineer.log :
2020-01-23 15:28:50.210 - Thread: 1 -> ERROR Entity init!: System.IO.IOException: Too many open files.

Can I get someone to tell me their winetricks version that works? Or eventually even their whole pfx directory that works?

While I'm at it, @plasticbomb1986 , for possible performance boosts, you can try tweaking the registry (backup the pfx directory before you do), particularly changing the VideoMemorySize key to your actual one, GLSL key, and DirectDrawRenderer key, also anything in Direct3D and having to do with textures or shaders. Try one at a time, reverting any changes before trying a new one, then you can try combining.

@MajorLunaC, while I'm not going to comment on the workarounds you are trying, it may be worthwhile to double check that ulimit -Hn outputs a high value and not 4096.

Also, one of the links in your comment is legally problematic and has been removed.

@kisak-valve Whoops, sorry about the link, I didn't realize it. I'm too used to trying to figure out what's wrong and required by any means necessary.

The output of ulimit -Hn is 4096. Is there anything I can do about that? Can I safely increase it and to how much?

Proton uses esync (or fsync with capable kernels) by default, so it's likely that's contributed to what you encountered. The first section of https://github.com/zfigura/wine/blob/esync/README.esync should be helpful.

@kisak-valve Wow, it worked, I can play perfectly! Thank you for all your help!
I would still like to figure out how to make sure everything installs properly with the installers provided through winetricks to get some consistency, since the installers don't seem to really check if they did the job right. I think the .NET Framework Repair Tool might run through wine. It's not practical for everyone to copy dlls from a windows version they own or the "legally problematic" way of finding dlls online.

just use protontricks for ease of installing dotnet.

Dotnet can be installed all the way up to 472 I think (or is it 492 now?), but many of its functions may not work correctly. Windows Mono is a alternative but again many functions may not match up well.

Jarrad

Yes I remember the stuttery feeling even tho FPS was high. I can't remember for sure if I fixed it or not but you might want to try enabling vsync.

Check. Its feels a littlebit better, less stuttery, but the fps is still not close where it should be. PLus sometimes its still crashing.

MajorLunaC

While I'm at it, @plasticbomb1986 , for possible performance boosts, you can try tweaking the registry (backup the pfx directory before you do), particularly changing the VideoMemorySize key to your actual one, GLSL key, and DirectDrawRenderer key, also anything in Direct3D and having to do with textures or shaders. Try one at a time, reverting any changes before trying a new one, then you can try combining.

Gonna check it out! Thanks for the tip!

Ohh, and one more thing. Does any of you able to use Alt+F10?

Any one get a file not found Error on startup?

@BeauBouchard Are you using a custom version of proton... I get this message when using the latest version of Glorious Eggrolls custom proton.
If so try it with the latest official proton version. Note: you may have to delete and recreate your prefix, as GE destroyed my Space Engineers prefix, even after switching to 4.11-12.

Today proton got an update on my pc (from proton 5 to 5.0.2?), and since after that the game closing with out of memory error even when its just sitting in the main menu.
SpaceEngineers.log
VRageRender-DirectX11.log
steam-244850.log

Theres a shitton of things goin on, with an avarage 2-3 hour game session the proton log make a 400-500 MB log, easily.

Today proton got an update on my pc (from proton 5 to 5.0.2?), and since after that the game closing with out of memory error even when its just sitting in the main menu.
SpaceEngineers.log
VRageRender-DirectX11.log
steam-244850.log

Theres a shitton of things goin on, with an avarage 2-3 hour game session the proton log make a 400-500 MB log, easily.

After recreating the prefix, its still doin the same.

SpaceEngineers.log
VRageRender-DirectX11.log
steam-244850.log

Forgot system spec: Ryzen 2700X 32GB DDR4 VEGA64 and multiple ssds (swap on nvme ssd).

kernel 5.5 mesa 20git Manjaro Gnome DE

same here.
SpaceEngineers.log

steam-244850.log
Here's my latest log in case it helps, I haven't gone past the splash screen.

Same error but I'm not running Proton ( lutris-5.0 ) and my game crashed today suddenly after playing a month without issue.
I reinstalled the wine prefix/game, disabled steam cloud, no effect.
I booted into windows 10 and I see a notification for the first time : Default Radeon WattMan settings restored due to unexpected system failure.

Can play under windows, but after reboot/cold boot, same error under Linux.

Config: Ryzen 5 2600, AMD RX470, 16Gb RAM, SSD / Lutris-5.0 / ArchLinux

This is really strange error. It's completely outside of SE somewhere deep in .NET library.
From the stack trace it looks like network communication, maybe analytics or something.

Can you try disconnecting your internet for a sec and running SE without any connection so we can rule out possibility of an insane response from remote server.

This is really strange error. It's completely outside of SE somewhere deep in .NET library.
From the stack trace it looks like network communication, maybe analytics or something.

Can you try disconnecting your internet for a sec and running SE without any connection so we can rule out possibility of an insane response from remote server.

Tryin the reinstallin process now. Linux74656 script stall here: 01a0:err:ole:ifproxy_release_public_refs IRemUnknown_RemRelease failed with error 0x800706be

Without an internet connection, SE can be started as before.
As soon as the Internet connection is established and the servers are queried, it crashes immediately.
SpaceEngineers.log

I have it with Proton 5.0-2 and dontnet472 as well as dotnet48.
also tried with Proton 4.11-12 and dotnet472.

@plasticbomb1986 For installation you still need internet connection so that installers can be downloaded.

@plasticbomb1986 For installation you still need internet connection so that installers can be downloaded.

That would have been a facepalm moment, but no, net was on at the time.

I just came home from the cinema, in the last 4 hour it seems like it finished at the end, but i gonna rerun it, just to check it.

I can also confirm disabling the internet connection prevents the error.

I can also confirm disabling the internet connection prevents the error.

Yep, if after Se starts up and pop up the first loading "screen" i turn off the net, its loading up, and running okay, if i do not turn the net off, its loading up, but the audio cracks, and after a few sec its giving the out of memory error.

Guys on Keen SWH Discord (https://discord.gg/keenswh) found solution in a meantime.
Game sends analytics to 81.0.234.196 and 88.146.207.227 (Keen SWH analytics servers) which apparently sends back some garbage that causes the issue (unintentionally).

Solution is to block this service via:
sudo iptables -A INPUT -s 88.146.207.227 -j DROP

All credit goes to Rölli :+1:

Solution is to block this service via:
sudo iptables -A INPUT -s 88.146.207.227 -j DROP

Nice, thx ! This work fine !

Seems there's a few different people getting a few different errors here, and none of them seem to match mine. I also get the splash screen for a short time and then a crash, but my log looks different from the most recent ones uploaded by others. The most interesting line to me is
[000000000000003C:] EXCEPTION handling: System.TypeInitializationException: The type initializer for 'GameAnalyticsSDK.Net.Logging.GALogger' threw an exception.

This is on a clean prefix (removed steamapps/compatdata/244850), tested with and without the file changes from here.

The above iptables command does not help for me.

steam-244850.log

@captaincrutches By chance did you accept the GDPR agreement info dialogue when the game starts up? It may be active and be the source of the issue.
You can check here: .../244850/pfx/drive_c/users/steamuser/Application Data/SpaceEngineers/SpaceEngineers.cfg

and change:

<item>
        <Key>GDPRConsent</Key>
        <Value>
          <Value xsi:type="xsd:string">True</Value>
        </Value>
</item>

TO:

<item>
        <Key>GDPRConsent</Key>
        <Value>
          <Value xsi:type="xsd:string">False</Value>
        </Value>
</item>

@Linux74656 I never got a GDPR dialog, and I don't have that file at all. In fact, I can't find a SpaceEngineers.cfg anywhere on my system.

That folder does contain a SpaceEngineers.log which I'll upload here for completeness - it seems to have a null pointer exception.

SpaceEngineers.log

You're running the game via Mono instead of .NET framework. Probably incorrectly installed prefix.

What distro and winetricks version are you using?

I'm on Gentoo, using the latest winetricks (20191224) and protontricks (1.4.1) in portage.

Delete game prefix and create it again. While doing so, save output log so we can see if there is anything interesting.

Ah, well, guess what? I had been previously trying to do the patching via the command line using protontricks/winetricks... but I just tried with PatcherGUI.jar and lo and behold, the game now starts! Thanks for the nudge~

Not sure if I should be posting in this thread or not, but when I tell Space Engineers to quit, it doesn't actually close the threads properly. Plus hitting "Stop" on STEAM doesn't kill it either. I need to kill the processes manually.

I've been getting the same issue, What's perplexing me is that even if I kill all of the processes related to SE, Wine, or Proton it still refuses to see SE as exited in Steam. I actually have to kill steam in order for me to relaunch SE afterwards. Quite annoying. I've not looked into the issue too much beyond killing all of the SE/Proton related processes in Steam but it's something that probably needs to be looked at

I've been getting the same issue, What's perplexing me is that even if I kill _all_ of the processes related to SE, Wine, or Proton it still refuses to see SE as exited in Steam. I actually have to kill steam in order for me to relaunch SE afterwards. Quite annoying. I've not looked into the issue too much beyond killing all of the SE/Proton related processes in Steam but it's something that probably needs to be looked at

I have a tip for you. I'm on Ubuntu, so this may or may not translate to your situation.

After I exist Space Engineers I bring up "System Monitor". While in the "Processes" tab, I click on the stacked burger (three horizontal lines) menu to then enable 'Show Dependencies". This then turns the "Processes" section into trees.

I then go and look for the areas with "Steam" running, and look specifically for "SteamChildMonit" and the tree from that. If there are multiples (there probably is only one) look for the one with the child "SpaceZEngineers." and a bunch of wine stuff.

I then first click on "SteamChildMonit" to highlight it, hold shift and click on the last child in that tree (often "winedevice.exe"). Then right click on the selection, go kill, and it kills all of them.

This enables me to relaunch the game (or I can launch other games) without having to kill all of STEAM.

I have actually found that if I exit SE "normally" I do need to manually kill a bunch of processes as described above... but if I kill -9 $(pgrep SpaceEngineers) from the terminal instead of exiting the game normally, all relevant processes die as desired.

The zombie process issue is not a Wine / Proton issue, it also occurs on Windows for me.

See this: https://github.com/Linux74656/SpaceEngineersLinuxPatches#issue-8

For the first time since owning the game I can actually get it to go past the splash screen with Proton 5.0-8rc, haven't a clue what I'm doing in the game but at least I can finally play it. :)

I'm facing a crash after long enough sessions. The steam-244850.log has 900 MB, but the game log is smaller. I will have to wait for a while before the upload finishes.

The game log:
SpaceEngineers_20200626_220158938.log

Steam log (compressed): https://mega.nz/file/gxxAnKzS#gunhdGQRfYJLIbnEGadOWQ6PNC2j4eMYgssjh-IJHPg

System specifications: https://gist.github.com/FurretUber/e105309ff4c58e197c3b2f65318cd8e1

Yeah Space Engineers crashes for me after a random period of time, and watching the logs I don't see anything crop up, so not sure what to do about it :( It happens quite frequently.

Can we get a fix for proton for Space Engineers not actually quitting when exiting the game please?

"Game is not started in Proton sandbox and can see normal Linux directory structure" -summary by one of many actually programming-literate people who have helped me today. From my perspective, I see a splash screen for a second or two, then all returns to a state as if I had never clicked play. Log is attached.
SpaceEngineers_20200708_180142615.log

System Information

• GPU: X.Org Radeon RX 570 Series (POLARIS10, DRM 3.33.0, 5.3.0-62-generic, LLVM 9.0.0)
• Driver/LLVM version: 4.5 (Compatibility Profile) Mesa 19.2.8
• Kernel version: 5.3.0-62-generic
• Link to full system information report: https://gist.github.com/HalberdGuard/c623a4f14676e77e6f401b3c62a2e9b7
• Proton version: 5.0-9

Did you try the setup jar file? I've found that to be rather reliable, but yeah, that stuff should be baked into proton for sure.

This was actually the result of having used both the automated version, and later the manual version, with the assistance of aforementioned friendly and knowledgeable (and patient!) people... Suppose I should have mentioned that. : p
Due to other, likely unrelated circumstances, I will likely have to re-install Steam from scratch soon, maybe it'll no longer be weird? We'll see!