⨯ You can sign up to get a daily email of our articles, see the Mailing List page.
  • Forum
  • Tech Help
  • [SOLVED] Wasteland 2 - crashes when entering Citadel
[SOLVED] Wasteland 2 - crashes when entering Citadel
jrial Dec 16, 2020
After receiving zero help from inXile support, the GamingOnLinux twitter account suggest I post my question here.

I finally got around to playing Wasteland 2 (Director's Cut, played through Steam), and I'm hitting that bug where once you progress a little in the game, you can no longer enter the Citadel without the game hanging or even crashing on the loading screen. Seemed like the issue described here: https://inxile.zendesk.com/hc/en-us/articles/115004658528-File-handles-bug-causing-crashes-Linux- but the proposed fix doesn't reliably resolve the issue.

Relevant info:

  • I have two Linux computers. My main gaming machine, and a laptop that happens to be able to barely run the game. Full specs of both at bottom of this post.

  • The problem first manifested itself on the gaming desktop only, but also appeared on the laptop after upgrading my system packages, which had been neglected for a couple of months, but no more than a year.

  • The problem only manifests itself when attempting to enter the Ranger citadel, and doesn't happen when starting a new game. I suspect it's related to opening up the inner Citadel areas after completing Highpool or Ag Center.

  • A video of the issue has been uploaded to YouTube.

  • When I check the system load when it hangs, I see the WL2 process uses up about 105% CPU, indicating a busy-loop.

  • I've already increased nofile soft and hard to 4096 and 8192 as suggested on the aforementioned issue page. This seems to help somewhat. But it's still not reliable, and I still need to reboot the PC between two visits to the Citadel. I also believe the last time I tried it, I was again locked out of the Citadel entirely. But I haven't been able to verify this due to work commitments.

  • The Steam forums suggest a corrupt disk may cause this as well, but the disk is brand new, I verified local content, and even tried deinstalling/reinstalling. Besides, it happens on 2 machines, one of which only developed the issue after an update.

  • It really hangs, it doesn't just take a very long time. I left it running overnight while I slept, and 6+h later, it was still stuck on the exact same spot.

  • At one point, when the game still worked on the laptop, I saved inside the Citadel to see how the gaming desktop would handle this. At this point, it crashed when loading the "inside the Citadel" savegame, rather than hanging. Probably not terribly important info, but I try to be thorough.


System information main desktop (where the issue has always been present):

  • OS: Linux Mint 20 Ulyana

  • CPU: Intel(R) Core(TM) i5-4690K CPU @ 3.50GHz

  • RAM: 8GB

  • Video card: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)

  • Video driver version: 450


System information secondary laptop (where the issue was absent at first):

  • Thinkpad W520 laptop

  • OS: Debian 11 Bullseye

  • CPU: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz

  • RAM: 32GB

  • Video card: NVIDIA Corporation GF106GLM [Quadro 2000M] (rev ff)

  • Video driver version: Legacy 390


Last edited by jrial on 17 December 2020 at 12:22 am UTC
This topic has an answer marked - jump to answer.
Liam Dawe Dec 16, 2020
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
jrial Dec 16, 2020
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.
whizse Dec 16, 2020
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
whizse Dec 16, 2020
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.
jrial Dec 17, 2020
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
Ehvis Dec 17, 2020
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).
tuubi Dec 17, 2020
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.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.
Register Forgot Login?
★ Support Us
Popular this week
Search or view by category
Contact
Latest Comments
Latest Forum Posts
Misc