Linux - Gamepads (and launch script)

[Squiddy]

I did post this in the replies to a recent update but I guess you missed it:

Okay, so we're getting there.

It now launches on Manjaro Linux from Steam.

Gamepads, surprisingly, also work. Which Game Maker usually has terrible trouble with. However, it doesn't support hotplugging on Linux? If a controller is disconnected, it fails to register it again when reconnected. Could you look into that?

[Squarebit]

I did miss it, thanks!

Looks like it doesn't work on Windows either - you'd have to quit to menu and re-assign controllers right now. An oversight on my end.. will fix it.

Thanks!

[Squiddy]

Ah, good to know!

Looking forward to the update with that in :D

[Squarebit]

Today's update fixes a lot of controller issues, but Linux is a bit more messy with gamepads so let me know if it didn't work for you :)

[Squiddy]

Okay, first thing, you need to not hard-code paths in the run script. You're assuming users have it installed in one directory *woops*.

Change the top of your run.sh for Linux to this:

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"

# Move to the game directory
LIB_CURL="$DIR/usr/lib/libcurl.so.4"
LIB_SSH="$DIR/usr/lib/libssh2.so.1"

First line simply gets where run.sh is, a very handy one liner to get the exact directory of it. The other two lines are the only other bits changed in it, to replace the hard-coded path with $DIR for the location.

Leave the rest as normal.

This makes it boot perfectly on Manjaro Linux, and it won't matter where users install the game.

Onto gamepads...it works! Way way better than before, even my Logitech F310 is now picked up properly when it wasn't at all last time :D

However, the Back button still doesn't get detected on either the F310 or the Steam Controller. That's the last issue to solve.

[Squarebit]

Thank you, I will give that a go!
Do I keep the export line or remove that too?

I will take a look at the back buttons not working - not sure why it won't pick those up.

[Squiddy]

Those are the only bits in the file I edited to make it work, so full example (this is messy, needs to be done better as it's copying around files):

#!/bin/bash

export LC_ALL=C

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"

# Move to the game directory
LIB_CURL="$DIR/usr/lib/libcurl.so.4"
LIB_SSH="$DIR/usr/lib/libssh2.so.1"
STEAM_LIB="$HOME/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64/libcurl.so.4"
STEAM_LIB_1="$HOME/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu/libcurl.so.4"

cd "$(dirname "$(realpath "$0")")"

# Run the game
cp -a $STEAM_LIB $STEAM_LIB.back
cp -a $STEAM_LIB_1 $STEAM_LIB_1.back
cp -a $LIB_CURL $STEAM_LIB
cp -a $LIB_CURL $STEAM_LIB_1
cp -a $LIB_SSH $STEAM_LIB
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:./usr/lib" ./Chronicon ${@}
cp -a $STEAM_LIB.back $STEAM_LIB
cp -a $STEAM_LIB_1.back $STEAM_LIB_1
exit 0

Thanks for the support and looking into it, once the back button on gamepads work it's pretty much flawless and will be on almost any distribution with the script fix above.

[Squarebit]

Thank you, I have now included the updated scripts with today's update (coming in a bit!).
I had a look at gamepads and could confirm that the back button doesn't work on Linux specifically.. works fine on Windows. So it'll need some more digging to figure out, aiming to have it fixed ASAP after today's.

Thanks again :)

[Squiddy]

引用自 Squarebit：

Thank you, I have now included the updated scripts with today's update (coming in a bit!).
I had a look at gamepads and could confirm that the back button doesn't work on Linux specifically.. works fine on Windows. So it'll need some more digging to figure out, aiming to have it fixed ASAP after today's.

Thanks again :)

That's awesome, really happy to see such awesome support. Thanks a lot.

[Squarebit]

Update: the gamepad issue seems to be on an engine-level, so I will be sending a report to the engine devs and see what they say - might take a while to get a fix for this sadly

[Squiddy]

引用自 Squarebit：

Update: the gamepad issue seems to be on an engine-level, so I will be sending a report to the engine devs and see what they say - might take a while to get a fix for this sadly

No worries, it's one single button so it's not a massive issue but it would be good if YoYo could look into it and fix it. I really don't get why they don't just use SDL which has excellent gamepad compatibility.

[Squarebit]

They are, I think, but it was added like way later than the other gamepad stuff so I'm not really sure how it works. Regardless, I have reported the issue to them and provided an easy to use sample so hopefully it should be an easy fix for them!

[Squiddy]

引用自 Squarebit：

They are, I think, but it was added like way later than the other gamepad stuff so I'm not really sure how it works. Regardless, I have reported the issue to them and provided an easy to use sample so hopefully it should be an easy fix for them!

Ah great, thanks for giving them a sample too! Hopefully they can get this sorted for everyone then :D

[Squiddy]

Hi, you seem to have broken it on Linux again, the launch script appears to have again been changed.

You're now doing things like this (again...):

LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:../../../ubuntu12_32/steam-runtime/pinned_libs_64/"
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:../../../ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu/"

You shouldn't do that, that's assuming people have the game on Steam installed in specific directories. You know what "../../" does right? That's going backwards in the directory path. This is why the script I supplied a few posts above was made the way it was, as it uses the proper $HOME variable to get the correct path for where you're trying to get the included Steam libs.

Even correcting that to have the launcher as this:

#!/bin/bash
export LC_ALL=C

cd "$(dirname "$(realpath "$0")")"

# Run the game
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:./usr/lib/"
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:$HOME/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64/"
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:$HOME/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu/"
./Chronicon ${@}

Doesn't work, as it seems the dependencies changed?

./Chronicon: /home/liam/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by ./Chronicon)

You also now have the steam api file both in the main folder, and in the /usr/lib/ folder.

I changed it to this to force it to use the libs you actually supply with the game:

#!/bin/bash
export LC_ALL=C

cd "$(dirname "$(realpath "$0")")"

# Run the game
LD_LIBRARY_PATH="./usr/lib/"
./Chronicon ${@}

But now this error:

./Chronicon: ./usr/lib/libcurl.so.4: no version information available (required by ./Chronicon)
./Chronicon: symbol lookup error: ./usr/lib/libcurl.so.4: undefined symbol: libssh2_scp_recv2

So looks like the game dependencies changed from the libs you supply.

At this point, I'm just confused.

The script I put in this comment still works https://steamcommunity.com/app/375480/discussions/0/1638675549024198060/?tscn=1576593800#c1736635023060845650 (but that's not good, as it messes with copying files!)

[Squiddy]

Okay, we got there in the end. A working one:

#!/bin/bash
export LC_ALL=C

cd "$(dirname "$(realpath "$0")")"

export LD_PRELOAD="./usr/lib/libcurl.so.4"
./Chronicon ${@}