Posted December 14, 2019
high rated
I got the game for free as Wintersale Give Away. Thank you GOG!
So this is in now way a complaint!
The first problem I ran into was already mentioned earlier hier in the forums.
The game doesn't work well with my dual-monitor setup, at least in fullscreen mode.
- I disabled a monitor,
- configured the game to not run in fullscreen,
- gave it a reasonable resolution (my monitor's native),
- and re-enabled the sceond monitor.
Problem 1 solved.
Intro works, menu works, creating a squad works, ...
But when the loading progress bar is at about 80% the game either crashes or hangs.
(Seems to depend on settings, but I'm not sure about it. Lately it always hangs for me.)
After some looking and testing I learned, that the game opens more files than linux (shell) usually allows.
My workaround (command-line): Before starting the game (`start.sh`) I raise the resource limits for that shell by `ulimit -n 4096`. (In the first gameplay minutes I observed around 2000 open file handles, I just guess 4096 should be enough for later gameplay.)
Problem 2 solved. So to say.
The second problem was a little tricky, so I hope the workaround might help someone.
Similar symptoms were already mentioned occasionally since 2016 in game comments. I'm curious if it is still the same cause.
More technical stuff (maybe someone know to read them better):
- Most open file handles are for just 1-2 asset files (i.e. `sharedassets5.resource`)
- Intro uses about a dozen file handles (f.j.1-2 a.f.)
- Main menu uses about 200 file handles (f.j.1-2 a.f.)
- Early gameplay it is about 1900 handles (f.j.1-2 a.f.)
- When the game hangs, `~/.config/unity3d/.../Player.log` continuously grows by errors about file `unity default resources` not being able to be opened (for reading)
- When the game hangs, its process constantly checks if that file exists (`stat` and `access` syscalls)
- When the game hangs, I do not observe any `open` syscalls from the process
So this is in now way a complaint!
The first problem I ran into was already mentioned earlier hier in the forums.
The game doesn't work well with my dual-monitor setup, at least in fullscreen mode.
- I disabled a monitor,
- configured the game to not run in fullscreen,
- gave it a reasonable resolution (my monitor's native),
- and re-enabled the sceond monitor.
Problem 1 solved.
Intro works, menu works, creating a squad works, ...
But when the loading progress bar is at about 80% the game either crashes or hangs.
(Seems to depend on settings, but I'm not sure about it. Lately it always hangs for me.)
After some looking and testing I learned, that the game opens more files than linux (shell) usually allows.
My workaround (command-line): Before starting the game (`start.sh`) I raise the resource limits for that shell by `ulimit -n 4096`. (In the first gameplay minutes I observed around 2000 open file handles, I just guess 4096 should be enough for later gameplay.)
Problem 2 solved. So to say.
The second problem was a little tricky, so I hope the workaround might help someone.
Similar symptoms were already mentioned occasionally since 2016 in game comments. I'm curious if it is still the same cause.
More technical stuff (maybe someone know to read them better):
- Most open file handles are for just 1-2 asset files (i.e. `sharedassets5.resource`)
- Intro uses about a dozen file handles (f.j.1-2 a.f.)
- Main menu uses about 200 file handles (f.j.1-2 a.f.)
- Early gameplay it is about 1900 handles (f.j.1-2 a.f.)
- When the game hangs, `~/.config/unity3d/.../Player.log` continuously grows by errors about file `unity default resources` not being able to be opened (for reading)
- When the game hangs, its process constantly checks if that file exists (`stat` and `access` syscalls)
- When the game hangs, I do not observe any `open` syscalls from the process