Linux version starting problems

[Night Nord]

Hi, folks. Great game you've made... maybe... because I can't launch it on linux, so I can't check it out.

I'm running a bit of weird system, so game not able to run is not a big surprise. The surprise is that it doesn't say anything bad - no segfaults, no errors in log, etc. Just silently closes like I've asked it to.

My system is:
Gentoo 64-bit, kernel version 3.15.5
Video: [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X]
Video drivers: open source, mesa from recent git (like few days old), llvm from recent git (same). That's probably the problem - I can't use proprietary drivers due to various conflicts and there is no robust support for that chip in open source drivers releases, so I need to use somewhat unstable "live" versions. But it's not an excuse to not saying anything if there is a problem with drivers (and not crashing).
Everything else is probably not so relevant, but just to reassure you that there is no more obvious problems - CPU i7-3770k, 16Gb memory, a lot of free HDD space...

Just as a note - Wastelands 2 (also running on unity3d and AFAIR mono) are doing the same thing if I'm trying to enable shadows. But by default it loads with super-low graphics configuration with shadows disabled and I've managed to up everything but shadows with no problems. Also it's using a standard unity3d configuration file.

VE seems to be trying to run on "Very high" graphics settings and so fails miserably (but again - it should say something about that). I've tried to locate configuration file (using strace) and it seems to using BOTH standard unity3d configuration file location (~/.config/unity3d/AtomicTorch\ Studio\ Pte.\ Ltd./VoidExpanse/prefs) and it's own ~/Documents/AtomicTorchStudio/VoidExpanse/SettingsClient.xml. But it manages to save only it's own file.

I've tried copying prefs file from Wastelands 2 - it worked, not it's in windowed mode, but aside that nothing improved.

I've tried to mess with graphics settings in SettingsClient.xml changing it to

Code Select Expand


    <anti_aliasing>2xMSAA</anti_aliasing>                                         
    <background_effects>Low</background_effects>                                   
    <fps_limit>30 fps</fps_limit>                                                 
    <gamma>0,5</gamma>                                                             
    <post_effects>False</post_effects>                                             
    <quality_setting>Low</quality_setting>                                         
    <screen_resolution>800x600</screen_resolution>                                 
    <sun_effects>False</sun_effects>                                               
    <windowed>Windowed</windowed>             

No luck either. It also says "10.8.14 14:13:00.3134 Set default quality level: Best" in the log. Also tried to set quality_setting to Worst and Performance. Dunno what it should be.

Log file, saved via -logFile with Debug severity: https://www.dropbox.com/s/gfrhkb7frho2265/VE_Linux_log.txt

Please, make it tell what's went wrong, so I can try to work it around or at least file a bug on drivers.

[ai_enabled]

Hello!
>> The surprise is that it doesn't say anything bad - no segfaults, no errors in log, etc. Just silently closes like I've asked it to.
Unfortunately we don't have enough control over the Unity in this part.

>> I've tried to locate configuration file (using strace) and it seems to using BOTH standard unity3d configuration file location () and it's own ~/Documents/AtomicTorchStudio/VoidExpanse/SettingsClient.xml. But it manages to save only it's own file.
All Unity3D applications uses standard Unity3d configuration file upon launch. Then our game read it's own configuration file.

>> Just as a note - Wastelands 2 (also running on unity3d and AFAIR mono) are doing the same thing if I'm trying to enable shadows. But by default it loads with super-low graphics configuration with shadows disabled and I've managed to up everything but shadows with no problems. Also it's using a standard unity3d configuration file.
That explains a lot. If you need to start game, you need to modify both game configuration files (Unity and own specific) to be sure the game launches in a lowest quality mode (which is only one not using shadows, and yes - we can't separately disable shadows, it's also the Unity restriction).
To do so, please modify Unity3D configuration file and "UnityGraphicsQuality" to 0. In SettingsClient.xml you need to change "quality_setting" to "Fastest". It should help you to launch the game, but overall graphics quality will be significantly limited.
Regards!

[Night Nord]

Unfortunately we don't have enough control over the Unity in this part.

Too bad, that's kinda bad to fall out without saying anything. Wastelands 2 also seem to be doing the same. You may file a bug on unity probably.

That explains a lot. If you need to start game, you need to modify both game configuration files (Unity and own specific) to be sure the game launches in a lowest quality mode (which is only one not using shadows, and yes - we can't separately disable shadows, it's also the Unity restriction).
To do so, please modify Unity3D configuration file and "UnityGraphicsQuality" to 0. In SettingsClient.xml you need to change "quality_setting" to "Fastest". It should help you to launch the game, but overall graphics quality will be significantly limited.
Regards!

Well, that did the trick, thanks! Too bad I can't just report a bug on drivers without saying what exactly went bad. But i'll try to debug things on mesa side - at least it will say what errors it does produce.

Thanks for help, and if I may - maybe you should consider auto-dropping video settings to lowest possible if previous attempt to launch failed. That will remove a lot of frustration on bad drivers, especially with your non-standard config placement and format.

[Night Nord]

Well, not it launches, but can't start a single player game. Traditionaly - no errors, no warning, nothing. Except a bunch of exceptions in logs, but it doesn't seem to be dissapointed too much about that. Probably my mono is borked too, not a suprise - that's mono after all

A log with "Important" severity: https://dl.dropboxusercontent.com/u/20857147/VE_Linux_new_game_start_log.txt
It also seems to be blocking any debugging features of mesa [1]. In other words - unity is doing everything to cover it's crime of doing something wrong. And now I'm sure that it's doing something wrong - otherwise why it would go such long way of hiding truth?
I guess I'll just wait for a mesa/llvm release with hopefully more stable support. Or unity3d stop doing that nonsense of blocking any debug. Probably former will be sooner.

[1] http://www.mesa3d.org/envvars.html

[ai_enabled]

Could you test the game in multiplayer? The public server mp.atomictorch.com should work properly. If still not working, then we need to determine what exactly failed... and is not easy without specific debug information about what failed in Unity or driver.

[Night Nord]

Nope. It doesn't work in multiplayer either. I'll try to enforce debugging mode into the mesa code directly. That should at least give us a bunch of GL errors if any. I'll update this post soon enough hopefully

[Night Nord]

Just a heads-up. Still no luck in extracting any debug info out of unity.

But i've catched up an another bug. Unity checks for another instances of the game on start and refuses to start even if there is no "-single-instance" argument passed ("Player already running"). Problem is, that to do that it checks every /proc/<pid>/exe path to match the game binary AND, for some reason, /proc/<pid>/cmdline. Trick is - if you have anything launched as "/proc/self/exe" (chrome launches it's sub-applications like Hangouts such way. You may just run a shell by /proc/self/exe) it will be recorded as such into cmdline. The game will read that and will attempt to check on /proc/self/exe (linking to itself, obviously).

Reproduce:

Code Select Expand


$ cd /path/to/the/game/dir
$ exec /proc/self/exe
$ ./VoidExpense


[Night Nord]

Nope. Still no success. But I'm pretty sure that's the problem on a unity side. I mean - it probably detects something wrong, missing format or something and just silently bails out. No errors from mesa/GL. Everything is fine. Program execution is done almost clearly, that is - it's not a crash.

But what worries me - the program spurs TONS of segfaults and other nasty things but seems to consume that internally without saying a word. That's kinda disturbing and no worries it behaves that way - silently bailing out without saying a word. It's seems to be a standard behaviour in the world of mono or unity or C#, I dunno. Anyway, now I officially hate unity. I knew there was something fishy about it, but I wasn't sure what exactly, so I was just cautious about it. But now I know - it's written for .NET/mono! I hate .NET.

But anyway, on a serious note - it seems to be a lost cause. Let's just note that game doesn't work on a opensource r600 drivers for some unknown reason and let's hope that it will someday when drivers or unity or mono fixes whatever currently failing.

[ai_enabled]

Night Nord, I think Mono/.NET is not the reason of issues. Moreover - Unity is not written on Mono/.NET/CLR/C#, it just using it for scripting. AFAIK, main part of Unity is written on C++.
I will upload the Debug game build for you which is supposed to generate much more debug information. Hope it helps.
Regards!

[ai_enabled]

I created Debug build of the game for Linux, but it doesn't launch for us (on the same machine where release build works without any problem). I sent download link to you in PM if you want to try it.