[617290] Remnant: From the Ashes #2994
Comments
flibitijibibo
added
Game compatibility - Unofficial
|
Tried another run with a native d3dcompiler_47/43 per @kisak-valve's advice. Same result, without the HLSL compiler errors. |
|
It should be noted this happens on both wined3d and dxvk, I experienced the same issue. Once you go into game then back out into the character select it renders fine. |
|
Do you see any intro sequences when starting the game before reaching the menu? For some strange reason, the game decides to paint a completely black full-screen quad over the menu background, which doesn't happen on Windows. The background itself is 3D graphics rather than a video. |
|
All I saw was a blank screen, some legal text at the bottom, followed by the aforementioned menus, all blank screens. I suppose I'm looking at the black quad; why that's showing up i have no idea :/ |
|
after installing Media Foundation ( |
|
Yes, the game is working fine: |
|
Hello @paxamit, the link you posted is legally problematic and has been removed. |
|
After yesterday update the game crashes immediately after start: UPD: The game is working with GloriousEggroll 5.6 GE2 Proton build |
|
this game also has performance issue with proton. The game suddenly slows down to unplayable when changing settings or exit to main menu. Need to completely restart the game to restore performance. |
|
I picked up this game for my partner and I to play together and my machine (current Arch) connects to multiplayer fine, but hers (Debian) hangs on connecting to matches. Has anyone else encountered this? |
|
@grahampfau Looks like is a distribution problem. Debian seemed to have problem with games. Debian update is slower than other distributions. Debian is aimed to be stable and so not updated as often. Probably don't recommend Debian for games. |
|
@grahampfau Did you ever find a solution? I'm currently experiencing the exact same issue but on Arch. The game plays perfectly offline but it hangs infinitely on "Connecting" when I try to join any games or when someone tries to join mine. I've tried various versions of Proton (including GE), different kernels, and connecting through a VPN. Edit: From a Manjaro Live ISO with my Steam library and Proton mounted, I was able to connect online. So it might just be my particular installation. Edit 2: Reinstalling Arch solved the problem. Still interested in what the actual problem was as people on Windows have reported solving it the same way.... Edit 3: The issue was having Docker running. It happened to me again and the only change I made to my system was configuring enabling Docker. |
|
It won't launch on Proton 6.3 due to "DX11 feature level 10.0 is required to run the engine", but will run on experimental.
Proton 6.3-4 logfile: https://gist.github.com/Raklodder/b098254c55427f0da937b131ed01ff69
|
|
Hello @Raklodder, it may be interesting to test if the game behaves better with Proton 6.3-5 RC (instructions at #4906). |
|
@kisak-valve yes, thank you! Remnant: From the Ashes will run out of the box on proton-6.3-5-rc1. |
|
It appears that having virtual network adapters set to up breaks multiplayer. That behavior is described in this Reddit post and shown in this YouTube video. The latter also presents the workaround to set all but one network adapter to down. Unfortunately, I can't use this workaround because my setup requires network bridges, so a proper fix (if possible) would be fantastic. Here's a log file from starting the game with Proton 6.3-5, trying to connect to a friend's lobby (using crossplay with Epic, in case that's relevant), sitting in "Connecting..." for around 30 seconds, being brought back to the game's main menu screen without an error message and closing the game: steam-617290.log |
Aha, that explains why having the Docker daemon running breaks multiplayer. I believe a similar issue actually happens on Windows, as I remember someone there was experiencing the same symptoms and reinstalling their OS fixed it. |
Compatibility Report
System Information
I confirm:
ReproductionWithout any parameter just set proton to version 8.0-3 and press play. The game will create a black window, that window will go fullscreen, after about 2-3 seconds it will crash to desktop showing this error report tool for unreal:
P.s. |
|
I have been playing this game from 2020, definitely before proton 6. had no problems running the game. |
|
That's not something that would surprise me, AMD drivers are changing rapidly on Linux since the Steam Deck got released. I guess some older games like this one got left behind from some specific fixes, which is normal but still.. would like them fixed if possible. Planning a full game run in co-op with a friend :) |
|
@Plarpoon Have you tried an earlier version of Proton? I have a 6950XT on Arch with Mesa 23.1.3 and have been playing for a couple of years with various different Proton versions. I'm currently running GE 7-53 but I can test 8.0-3 when I get home later and see if I can replicate what you're seeing. |
|
Thank you for telling me that it worked around that version, I have actually just tried it myself and yes, the game works perfectly well (for the very short test I did) with Proton 6.3-8. I must say I was also using the launch parameter: "-d3d11" Tomorrow with more time I should definitely do more testing, but that also unfortunately confirms that the game is dead with the most recent version of Proton. Undeniably so... at least with my hardware configuration. That's something that should be looked into. |
|
@Plarpoon Glad that you found a configuration that works. I just finished my testing and found everything to be working well on both 8.0-3 and GE 8-9, so it does look like something more specific to your configuration. Unfortunately I don't have a current gen card to test more with. |
|
If I can help you with any test you might want to do, providing logs or even screen sharing and spending some hours one day in fixing something let me know. I am up for everything, would be glad to give something back to the community! |
|
Just to be clear, I'm not a wine/proton developer, I just really like this game and tinkering;) If you want to spend the time debugging, see if you can find the latest Proton release that works. From there, it should be easier to nail down what might have changed. |
|
I know you are not, but I like to believe that despite being less impactful since we are not actively contributing to the code we are still helping out by writing reports and issues here. I will definitely do some more tests as soon as I am back home, if you want to do some more specific testing I am up for it! |
|
@Plarpoon Here are a few things to try to get to the bottom of this. Also - I noticed that both this game and DRG use UE4... it would be interesting if you happen to know if you have any UE4 games that do work with Proton 8?
|
|
@alasky17 Here is everything as asked, unfortunately I will have to leave in 2 days for a max of 8 days, there is a project I have to conclude in Ireland and my desktop computer will remain in Italy. I can do any other experiment you might need tonight and the whole of tomorrow but then I will have to take a quick pause, hope that is fine! Good news: issue has been identified, it is an error with the audio devices. tl;dr at point number 4.
(I am terribly sorry I couldn't embed the pictures into a spoiler tab, they just break when doing so) I thought about adding some extras that could be useful, this is the result of lshw -C sound (click on this to see it)
|
That's an interesting finding. I have HD60S+ around so I can give it a shot. I'm a bit surprised it's an input device, but that may explain why you hit the issue with Remnant and DRG only, both have built-in voice chat. I wonder if they use the same UE4 plugin.
Sadly the game doesn't progress to the point where audio devices are used. Can you try to repro the issue with only a single output that's not 7.1 and only HD60S+ input being enabled? Otherwise try to find a minimal configuration that causes the issue. If you can, try actually unplugging the irrelevant devices for testing. Once you find a minimal configuration a log with |
|
@ivyl will do the actual test at minimum in two hours, unfortunately until then I have to finish a work thing. But I already know some of your questions. I also believed it was an issue given by the 7.1 at first but that didn't seem to be the case. As far as I noticed I can play well with Proton 8 as long as neither of webcam or capture card are enabled. If any of the two is it dies. If they are both disabled they work also with 7.1. |
|
@ivyl I have done the tests as you asked and found out couple of things: This one here is the most minimal configuration to make the game run fin on Proton 8 with my hardware: Requested log: So, I noticed couple of interesting things.
Here are the logs about that, same exact behavior and procedure as described above! |
|
@Plarpoon this is the same issue with DSOUND.dll segfaulting as I reported against Dying Light 2. (I came here to report the same issue against Remnant: FtA. For me, it is related to my SteelSeries Arctis Pro Wireless and GameDAC. If I unplug the DAC, the game launches and runs fine. A workaround is to replace dsound.dll under Proton 8/Proton Experimental with the one from Proton 7, see #5542 (comment). I wrote a couple of bash scripts to replace/restore dsound.dll, you can just update the source_path and dest_path to point to wherever you steam common is. #!/bin/bash
# Source and destination paths
source_path="<steam_lib>/steamapps/common/Proton 7.0/dist/lib64/wine/x86_64-windows"
dest_path="<steam_lib>/steamapps/common/Proton - Experimental/files/lib64/wine/x86_64-windows"
# Check if the source file exists
if [ -e "$source_path/dsound.dll" ]; then
# Check if the destination file exists
if [ -e "$dest_path/dsound.dll" ]; then
# Create a backup of the existing dsound.dll
mv "$dest_path/dsound.dll" "$dest_path/dsound.dll.bak"
if [ $? -eq 0 ]; then
echo "Existing dsound.dll backed up to dsound.dll.bak."
else
echo "Error: Unable to create a backup of dsound.dll."
exit 1
fi
fi
# Copy dsound.dll from the source to the destination
cp "$source_path/dsound.dll" "$dest_path/dsound.dll"
# Check if the copy was successful
if [ $? -eq 0 ]; then
echo "dsound.dll copied and replaced successfully."
else
echo "Error: Unable to copy dsound.dll."
# If the copy fails, restore the backup
if [ -e "$dest_path/dsound.dll.bak" ]; then
mv "$dest_path/dsound.dll.bak" "$dest_path/dsound.dll"
echo "Backup restored."
fi
fi
else
echo "Error: dsound.dll not found in the source directory."
fi#!/bin/bash
# Destination path
dest_path="<steam_lib>/steamapps/common/Proton - Experimental/files/lib64/wine/x86_64-windows"
# Check if the backup file exists
if [ -e "$dest_path/dsound.dll.bak" ]; then
# Restore the backup to dsound.dll
mv "$dest_path/dsound.dll.bak" "$dest_path/dsound.dll"
# Check if the restore was successful
if [ $? -eq 0 ]; then
echo "Backup of dsound.dll restored successfully."
else
echo "Error: Unable to restore the backup of dsound.dll."
fi
else
echo "Error: Backup of dsound.dll not found."
fi |
|
@rcbevans I think you have perfectly nailed the issue honestly. The proper way to deal with this issue is probably to ship a working version of DSOUND.DLL natively into the future Proton versions so that less technically involved users can benefit from it too. The workaround that you provided for now it's great and I love it, thank you a lot! |
|
It's weird that the old version fixes the issue for you. There do not seem to be any significant code changes between 7.0 and 8.0 that could explain this. @rcbevans Can you try with test-dsound beta branch of experimental (find Proton Experimental in Steam's library -> right click -> properties -> betas)? There's a slight chance that it will fix the issue. If not I'll may ask you later for some extra tests using a build that has much more logging added. |
|
@ivyl I know you did not ask me but I also tested it and it works perfectly well with the DSOUND beta you mentioned! First try smooth run 😄 I also had the same issue anyway. |
|
Is the DSOUND beta going to be merged to Proton before Proton 9? I don't mean to have an definitive answer if not present, even just to understand if it's supposed to be merged in that timeframe in case it actually is merged. |
|
@Plarpoon thanks for checking! I'm upstreaming the changes in question and I'm going to cherry-pick them into experimental once it gets accepted. If everything goes right those will be a part of next experimental release and 8.0-5 (8.0-4 is already in release candidate phase). I'm also waiting for other users to confirm that it's fixed by the change. While the change is correct and removes bits that were crashing I see no way it could have crashed in the first place just from the code or generated assembly... I see I don't think Deep Rock Galactic uses it though and I believe it also had some problems in the past? If you could get a crash log with |
|
@ivyl That sounds like absolutely amazing news, sorry for asking me again but just want to be sure, do you want a crash log of DRG and not Remnant? |
|
Yes. Deep Rock Galactic please :-) |
|
Here is Deep Rock Galactic using regular Proton Experimental This one like expected hard crashed during the initial loading screen. In other words it opens the window of the game but it cannot load into the 3D environment. More of it it's described here in great detail. There is also an analysis of the problem which you are already familiar with that I achieved mostly thanks to @kisak-valve, I invited other users to talk about it in this issue and it seems relevant to the test-dsound beta. This one is a report of DRG with the test-dsound beta enabled. Unlike the standard Proton-Experimental this one did not crash and started playing flawlessly. I had to manually exit to desktop. If I can be of any other use whatsoever just let me know @ivyl, I switched months ago to a full Linux setup so the only way I have to play all of my games is thanks to people like you. If I can do some testing to reciprocate somehow the effort I am more than glad, in that case feel free to ping me or contact me at my email at any moment! (it's in my GitHub bio) p.s. Off-topic but I am never going to thank you all enough for having found a fix in here at that Battle.Net bug that keeps on wanting to update in loop. |
|
Thank you, this was extremely helpful! I think I've found the root-cause. Including all the monitors (virtual input that's basically a mirrored output) you seem to have 11 of capture devices: This exceeds the number of GUIDs that can be stored in The first test branch removes the list (it's unused) which leaves much more space than intended for the GUID array due to how things are aligned and thus mitigates the crash. I've created |
|
Sure, no issues whatsoever, do you have a specific debug string of parameters you want me to use or should I keep on using the previous one @ivyl? |
|
The previous one is perfect. |
|
Oke @ivyl, gimme a few seconds and I will send you everyhing. You said 3 games, which one is the third one? I know DRG and Remnant, is the third one perhaps Titanfall? Because in that case I have only Titanfall 2 installed at the moment and I might need some time to download the first one. |
|
Hopefully things won't crash. Then logs are not necessary :-) Dying Light 2, at least that's a game that @rcbevans was experiencing crashes with. |
|
I unfortunately do not own that game... I am sorry (hopefully one day) |
|
I have fantastic news @ivyl, both games are working perfectly fine and flawlessly. You found the issue! Here is Deep Rock Galactic Here is Remnant from the Ashes |
|
If I can get confirmation that this issue is fixed I will close it even now adding a redirect to one of your last posts @ivyl. As far as I can see the problem is completely resolved, I am now waiting for more feedback 😃 Thank you for everything you did in the meantime and feel free to ping me if you need to test something in the future! 🦖 |
Compatibility Report
System Information
I confirm:
steam-617290.log
Symptoms
The main menu and character creation menus are blank, minus the UI elements. In-game graphics appear to be okay, and performance is good overall. I see a single reference to mfplat.dll but I don't see any references to actual MediaFoundation calls in the log (and presumably the character would still be rendered in the menu, just without a video background, assuming the background is a video prerender).
Reproduction
The text was updated successfully, but these errors were encountered: