Closed Upbeat Giraffe (stable, linux64) failing to launch from Steam

If I attempt to launch as normal from my steam library, there is very little reaction. If I have my friends list up, it flashes the usual green "In-Game Starbound" under my name for a bit less than a second, then goes back to blue "Online" as if nothing happened...
...but if I hunt down the executable under Starbound/Linux64 and run it directly, the game runs fine. So... I don't know what the steam client is attempting to run, but I'm pretty sure it's not the game's .x64 executable. Maybe it's trying to run the x86-32 version? Or one of the Windows ones? ...I never have gotten steam to successfully launch a game that requires Wine.

Oddly enough, the .log file in that directory is old, and well, it starts with

Code:

Info: Preparing Star::Root...
Info: Loading Star::Configuration from './starbound.config'
Info: Done preparing Star::Root.
Info: Client version 'Beta v. Angry Koala' '628' '428'

despite the executable clearly launching the new version. All 6 of the .log files in the root directory are also from Enraged Koala.

I did manage to hunt down a log file attached to the new version, though. It's in a directory called "giraffe_storage", along with an empty player subdirectory. I assume this is why I see all empties in the character select screen.

http://pastebin.com/dRrPpq2D

...I assume this is from my direct running of the executable and promptly quitting.

Also, if I'm to try deleting starbound.config for this one... which starbound.config would I go with? I've got one in root, one in linux64, and one in giraffe_storage. Tried the one in root, but it hasn't regenerated with subsequent attempts to start.

Just in case, I made a new handy-dandy SysInfo output image:

Of course, that HDD output is completely fabricated. Not entirely sure by what. Long, long ago I had a 1TB drive, a 1.5TB drive and a 500GB drive as auxiliaries to this OS' practically disposable Seagate 80GB system drive, but those are all in my fancy new computer with its UEFI, GRUB-hating Windows 7 only setup. Really, it's this old hardware that moved to a new (cheap) case and power supply. The new Kaveri gets my good old gold-certified PSU and super-airflow case (and it *needs* that airflow, despite lower wattage requirements. Odd, since this old thing is a 125W CPU. One which produces negligible heat).

 

I have the same problem, but dot bashing starbound from /home/iiro/.steam/steam/SteamApps/common/Starbound/linux64/ does launch the game (at least)

 

Someone else's thread took off on this issue: [UNSOLVED] Winter Update Broke GameUnder Linux
...there are a couple of fixes in there, and we've identified the problem. Launch_launcher.sh (which is the shell that the Steam client tries to run when you hit play in their GUI) doesn't work for those without qt5 libraries native to their distro, apparently... every other part of the game works just fine, you can even bash the launcher manually.

 

Been having this one, too, although I can launch the 32-bit launcher, but not the 64-bit one. (I am running a multilib distro, but I don't have Qt5 installed on either 64 bit or 32-bit end. ) Kind of indicates to me that the launcher is trying to use the system Qt files, not its own Qt...

 

Run launch_launcher.sh from a terminal and post the output here.

 

I wasn't able to run from Steam on my ubuntu laptop, but it ran fine from a terminal. Bleh.

 

In that case run Steam from a terminal and attempt to launch Starbound.

 

Nope.

 

Undid the workaround and re-downloaded. Still broken in stable. Updating to nightly to see if it's fixed there, as per the reddit thread (I'm not willing to make an account there for a reply, I'm juggling too many logins and passwords as is).

*edit*
Works fine in the nightly build. Once that's pushed to stable, I'd consider this fixed.

I find this somewhat mystifying. No idea what's involved, code-wise... because the launcher has always worked if you bypass steam. I assumed that meant the qt5 libraries mentioned in the shell script were unnecessary... but apparently not.

Code:

launch_launcher.sh:

#!/bin/sh -e

cd "$(dirname "$0")"

# clobbering the steam LD_LIBRARY_PATH is intentional.  It fixes bug #614 where linux launcher links do not launch properly.
# This does not seem to affect the steam overlay, as it seems that the library path is restored when launching starbound or starbound_server
LD_LIBRARY_PATH=./qt5libs ./launcher