Linux version fails to launch due to bad check

[OvermindDL1]

I've had a longstanding isssue where Creeper World 3 fails to launch, x86 or x86_64, and I had some time to dig in to it, so dig in to it I did.

First thing I did was hook up strace to see what files it was accessing, immediately I noticed:

Code Select Expand


write(5, "Player is already running\n \n(Fil"..., 52) = 52

File 52 is apparently linked to a unit3d generic log file (not game log file), and indeed that is being printed.

I then proceeded to dig in to what it was accessing and found it was looping over Every-Single-Running-Program-On-The-Computer!  Aside from the security questions about this (why?!?) I noticed that when it iterated over the Gitter.im desktop client is when it then went down another path (can I say that debugging mono native code sucks, but what would you expect from .NET...), which is what ended up at the fail.

So, closing Gitter.im, and the game then starts up fine.  I can then proceed to reload Gitter.im without issue.

Thus bringing me to my question here, why is the game checking for the Gitter.im desktop client or something it is doing then preventing itself from loading?  I'm curious if this might be the explanation of some other random 'Why is it not launching on Linux?' posts that get resolved after a reboot.  Any chance of fixing this because remembering to kill and reopen the Gitter.im desktop client is irritating.  And the question I am most curious about an answer, why is it iterating over every single process on my system without asking and then killing itself when it hits Gitter.im?

[Karsten75]

I suspect your question is best asked on the Unity3D game engine platform, or on an Linux forum specific to your flavor of Linux (which you conveniently forgot to mention - nor did you give specifications of processor or graphics capability).

I can tell you that the games (Particle Fleet or Creeper World) is NOT doing anything of this nature.

Also, I should point out that there are many others successfully running both games on Linux without thee issues, so it may be an environmental issue specific to your configuration.  Unfortunately, that is the nature of the Linux beast - there are so many different environments, so many different configurations, Virgil can't take account of them all. He gets the game to work on a platform that is equivalent to the SteamOs platform and after that, it's up to those rugged individuals hewing their own bespoke OSes from naked silicon to figure out why it's not working on their platforms, or doing bizarre actions on their platforms that it's not doing on other platforms also claiming to be Linux.

[knucracker]

Definitely unity engine relate as K75 mentioned.  It is mostly a black box that I sit on top of.  Now of course it might also be behavior that has changed or been fixed.  CW3 was built with both unity 4 and unity 5.2.  So you could right click the game in the steam client, go to properties, the BETA tab, then select the older version that was built with unity 4.  If that works when glitter is running, then it is something unity introduced in unity 5 (or maybe even 5.2 specifically).

You could also try particle fleet and see if you get the same problem.  It was built with unity 5.3.

Here's a random discussion I found about the same thing:
https://steamcommunity.com/app/234650/discussions/0/558754899774858118/

[OvermindDL1]

Following up here, and yep, found the similar information, it is scanning processes and gets to a Chromium 3D render process (which redirects via command to self/exe, which when it resolves 'locally' instead of globally it finds itself), whether via Chrome, Chromium, or standalone clients like the Gitter.im desktop client, and it thinks its found itself.  So it is entirely a bug in Unity3D.  ^.^

Feel free to give a bug report to them, unsure about Unity 5.3 yet, will try that when I get an opportunity from work and home life when I can and will report back.  :-)