Are you able to run it in terminal when it happens, and get us the output? That would be quite helpful, or the player.log file from when it happens. You can usually find it in /.config/unity3d/*game or developer name*/player.log.

The linked video shows nothing other than it loading, and that video didn't give it long to load either.

Last edited by Liam Dawe on 16 December 2020 at 6:32 pm UTC

Hey Liam, thanks for the suggestion. I'm kind of tied up on a tight deadline, but should have time this weekend to do another test. I'll provide the console output and log file contents when I do.

As for the length of the video: I once left it "loading" overnight, and 6+h later it was still stuck on the same spot. It doesn't progress beyond the point shown in the video, so I saw no need to continue filming. Especially since I was the tripod, and doing a poor job too.

You might want to double check that the limits are in fact changed:
ulimit -Hn 
ulimit -Sn
from a terminal.

I have dim memory of having to change those limits somewhere else. But can't really figure out where for the moment. Something in systemd?

You might also want to try and increase those numbers. Other things like Esync in Proton really likes to keep tonnes of files open.

You can check how many files the Wasteland process have open, and compare with the values from ulimit. Something like this should work:

ls /proc/$(pidof Wasteland.bin)/fd/ | wc -l

HTH!

Last edited by whizse on 16 December 2020 at 7:19 pm UTC

It was a systemd setting I changed:

In /etc/systemd/system.conf and /etc/systemd/user.conf change DefaultLimitNOFILE to something sensible. I seem to use 1048576.

systemctl daemon-reexec might do the trick to reload the settings, not sure if logging out/in is required afterwards.

Quoting: whizseIt was a systemd setting I changed:

In /etc/systemd/system.conf and /etc/systemd/user.conf change DefaultLimitNOFILE to something sensible. I seem to use 1048576.

systemctl daemon-reexec might do the trick to reload the settings, not sure if logging out/in is required afterwards.

This seems to have solved the issue. I checked remotely by SSHing into the box, and saw my limits from /etc/limits being applied. But when checking in a terminal, I saw a lower value for the softlimit: 1024.

Did a bit of digging, and stumbled over this, that might explain it. The tl;dr: the contents of /etc/security/limits.conf is not applied to the graphical login.

Applied your huge limits, rebooted. Now when I log in over SSH, I see the limits from /etc/security/limits.conf are being applied. On the graphical shell, it's the hard limit from /etc/security/limits.conf for some reason, but at 16384 that's plenty for me.

Tried entering the Citadel 3 times in the same game session, and it went without a hitch. During my third Citadel entry, I checked the number of files in use by the WL2 executable, and it sat at 2406, which might explain why it got stuck loading with a softlimit of 1024.

Anyway, thanks a lot for the help. It's a big relief to know I can spend my upcoming 2 weeks of vacation playing the game rather than fighting it, like my previous vacation.

Last edited by jrial on 25 December 2020 at 9:29 pm UTC

Since this is a new topic about W2DC issues. Anything that can be done about the horrible tearing in this game?

As I understand, the only fullscreen that this game supports is a buggy Unity5 version of borderless which will not properly vsync (or gsync).

Quoting: EhvisSince this is a new topic about W2DC issues. Anything that can be done about the horrible tearing in this game?

As I understand, the only fullscreen that this game supports is a buggy Unity5 version of borderless which will not properly vsync (or gsync).

Since you're on Nvidia, wouldn't ForceCompositionPipeline work? I don't remember having tearing in the game, and I had an Nvidia GPU at the time.