Hi, after patch 1.3.5 issue still persist. Not fixed :-/
Thank you very much everyone for the workarounds!
Questions:
1; Why recreating the appid file every time? Does it get deleted by Steam? As far as I tested it stays there.
2; Would it do any harm if I just add the LD_LIBRARY_PATH export to my /etc/profile or add it to my Steam launcher’s command? Will it interfere with anything?
3; I wonder why it doesn’t work if I start steam after exporting but then try to start SC with the button.
Sorry, I’m not an expert in Linux… 
OK this is really weird… I have a 64 bit system so THIS is supposed to work for me:
LD_LIBRARY_PATH=~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/
But it doesn’t, while THIS does:
LD_LIBRARY_PATH=~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu ./StarConflict1; Why recreating the appid file every time? Does it get deleted by Steam? As far as I tested it stays there.
You only have to create it one time, after that, the only thing you have to do is run the Library Load command while starting your game.
2; Would it do any harm if I just add the LD_LIBRARY_PATH export to my /etc/profile or add it to my Steam launcher’s command? Will it interfere with anything?
I am not sure what the problem is with the steam application loading at the moment, but steam already knows where to find the library files - something else was broken which is why we are bypassing the Steam loader and running StarConflict from the terminal.
OK this is really weird… I have a 64 bit system so THIS is supposed to work for me:
LD_LIBRARY_PATH=~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/
But it doesn’t, while THIS does:
LD_LIBRARY_PATH=~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu ./StarConflict
My guess would be that at some point, either you or your package manager installed a specific i386 library that was a defined dependency for another program at that time. Though most programs you can install in Ubuntu are MultiArch (meaning they can run on shared libraries for either i386 or amd64), not all programs are like this.
For instance, if you are in a 64-bit OS and you type “sudo apt-get install wine” - wine is a program that has specific i386 dependencies and, even though you are in a 64-bit OS, it will install the :i386 version of its dependencies.
If you go back and run that 64-bit load command and look at whatever library it tells you is missing, and then go into your package manager and look for it, I’d bet you will see only the i386 version installed, and if you install the other version of that library, the other load command would likely work.
That said, I wouldn’t do that if it’s already working for you. No need. “If it ain’t broke, don’t fix it”.
Glad you got it working.
-LIB
OK this is really weird… I have a 64 bit system so THIS is supposed to work for me:
LD_LIBRARY_PATH=~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/
But it doesn’t, while THIS does:
LD_LIBRARY_PATH=~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu ./StarConflict
$ file StarConflict
StarConflict: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=06070f67d5c37cb8859954c3bb1099d2217a7839, stripped
The game is 32 bit so you need the 32 bit libs 
and i put the “echo “212070” > steam_appid.txt” in my script just for comfort so if you have the “steam_appid.txt” you can just remove the line.
#!/bin/bash
export LD_LIBRARY_PATH=~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/:~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/
cd ~/.local/share/Steam/SteamApps/common/star\ conflict/
steam &
sleep 15s
./StarConflictThe game is 32 bit so you need the 32 bit libs
The game is 32 bit, but he “needs” MultiArch libs. I run my game using the Library load command for a 64-bit lib directory because I didn’t want to install the same libraries for 32 as I already had for 64. There’s no need. It runs just fine.
As I said though, “If it ain’t broke, don’t fix it”. Nothing’s wrong with running it from the 32-bit directory if you already had the dependencies qualified by that Arch-type - as the majority of people probably already have. Or even if you don’t, and you’re installing dependencies for this game and haven’t had a bunch of other programs for the same libraries.
But for me, I’ve used my Ubuntu desktop extensively long before installing this game, so I had many MultiArch libraries already installed for a plethora of other games / programs and had no need to install 32s if the 64 works just fine for this game (because they’re MultiArch anyhow). Comes around full circle to - “If it ain’t broke, don’t fix it”.
Also, as I stated above, you do not need to echo the appid.txt every time. The file is not deleted after running.
I use Arch Linux 64bit, not Ubuntu. In Arch 32bit files are packed and installed separately from multilib repo, by default everything is 64bit (on your 64bit install). And the 32bit multilib packages should depend on their respective 64bit versions. I even checked and the files are there.
I hope they fix the game
I want clic play in steam and start playing only without have to use terminal
is there any progress here ? topic started one month ago…
Star Conflict 1.3.6 and newer
Ubuntu 16.04 LTS (64bit)
install of:
steam:i386 via standard Ubuntu repository::
username@host-name:~$ sudo aptitude install steam:i386
The following NEW packages will be installed:
steam:i386
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/874 kB of archives. After unpacking 2.662 kB will be used.
Preconfiguring packages …
Selecting previously unselected package steam:i386.
(Reading database … 267621 files and directories currently installed.)
Preparing to unpack …/steam_1%3a1.0.0.48-1ubuntu3_i386.deb …
Unpacking steam:i386 (1:1.0.0.48-1ubuntu3) …
Processing triggers for man-db (2.7.5-1) …
Processing triggers for hicolor-icon-theme (0.15-0ubuntu1) …
Processing triggers for bamfdaemon (0.5.3~bzr0+16.04.20160415-0ubuntu1) …
Rebuilding /usr/share/applications/bamf-2.index…
Processing triggers for desktop-file-utils (0.22-1ubuntu5) …
Processing triggers for mime-support (3.59ubuntu1) …
Setting up steam:i386 (1:1.0.0.48-1ubuntu3) …
install of :
Star Conflict 1.3.6 via steam client
Hy,
I got an other script working for me:
!/bin/bash
export LD_LIBRARY_PATH=~/.steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/:~/.steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/
cd ~/.steam/steam/steamapps/common/star\ conflict/
echo “212070” > steam_appid.txt
#steam &
#sleep 15s
./StarConflict
Have fun!! Hoot Hoot! :00555:\
P.S.: See also ::
____________________
New version 1.3.6 does not update via SteamOS on Linux (Ubuntu 16.04 LTS)
So, is there any news about this “bug”? Yes, the workaround works, but you would think that given over a month to “fix” this…It would be fixed already.
It looks like with the last steam update it is working again
yep it is currently launching as it should on mine with a Linux Mint operating system
So, is there any news about this “bug”? Yes, the workaround works, but you would think that given over a month to “fix” this…It would be fixed already.
Thanx to Skula (or another brave SC developer) the SC-Linux :alien3: alien bug is killed !!!
Star Conflict 1.3.6.86265 is fully functioning o.k. now with Linux (Ubuntu 16.04 LTS and Steam install from main Canonical repository)!!
Thank you, Skula - thank you developer team!!