Add dependencies (Mosty just Yad) for Steam Tinker Launch to functon.

[LostWarriorr]

Currently Steam Tinker Launch does not function unless the host has the following dependencies installed:

However, on Distros that are Debian based Yad is currently unmaintained and to outdated to be used with STL.

To fix this problem I propose that Yad (and the other dependencies if you so wish) should be packaged with the Appimage.

Protonup-Qt will also be unable to install STL as it only sees the dependencies on the host system. If this does function correctly I'm sure a solution can be worked out to bypass the image of said prompt above and install it.

Potential Issues: Protonup-Qt will also be unable to install STL as it only sees the dependencies on the host system. If this does function correctly I'm sure a solution can be worked out to bypass the image of said prompt above and install it.

STL will probably not be able to find the Gamescope or Mangohud bin to use it. This can be fixed manually by the end user but it is worth talking to the folks over at STL if this is able to function.

Further more, from my understanding Appimages mount to a random directory when used therefore the location of the bins would be random each time meaning this won't work smoothly. I'm not sure if these newer Appimages function in the same way or not but I will bring up this issue. The folks over at Prismlauncher had this issue when bundling Java with the Appimage and eventually removed it because it was to troublesome.

[Samueru-sama]

Hi we already include mangohud and gamescope in the appimage, all that's left is adding yad right?

Further more, from my understanding Appimages mount to a random directory when used therefore the location of the bins would be random each time meaning this won't work smoothly. I'm not sure if these newer Appimages function in the same way or not but I will bring up this issue. The folks over at Prismlauncher had this issue when bundling Java with the Appimage and eventually removed it because it was to troublesome.

Ideally the conty appimages should be more like the archimages that Ivan has, where the appimage can interact with with the binaries of the host, that would fix the issue we have of having to bundle everything in the appimage.

I really don't know why you would need to predict the path where an appimage is mounted though, you can't just launch the individual bins inside the mounted appimage because any command would have to go thru the AppRun first where a bunch of env variables are set, otherwise if you try to manually launch the binaries inside they will fail.

[LostWarriorr]

Hi we already include mangohud and gamescope in the appimage, all that's left is adding yad right?

STL doesn't depend on mangohud or gamescope. But it can be used to easily launch both of those without trying to figure out which layout of commands will actually get both to work. It also provides other features that users could need such as its mod manager type features. Yad AFAIK is the only component missing on debian/ubuntu based systems due to it being unmaintained currently

Further more, from my understanding Appimages mount to a random directory when used therefore the location of the bins would be random each time meaning this won't work smoothly. I'm not sure if these newer Appimages function in the same way or not but I will bring up this issue. The folks over at Prismlauncher had this issue when bundling Java with the Appimage and eventually removed it because it was to troublesome.

Ideally the conty appimages should be more like the archimages that Ivan has, where the appimage can interact with with the binaries of the host, that would fix the issue we have of having to bundle everything in the appimage.

I really don't know why you would need to predict the path where an appimage is mounted though, you can't just launch the individual bins inside the mounted appimage because any command would have to go thru the AppRun first where a bunch of env variables are set, otherwise if you try to manually launch the binaries inside they will fail.

I'm not entirely sure on all the procedure of how an Appimage functions.

Here is the pull/merge request from PrismLauncher stating that they don't have a way to automatically detect it due to it being mounted to a random directory: PrismLauncher/#2328

If you know a way to not make this an issue for (potentially) STL finding Gamescope/Mangohud I'm sure it can also be shared to them to help them re-bundle Java into the Appimage for ease of use.

[LostWarriorr]

For Further clarification: STL decides what Mangohud to use based on this line in is config: ## The MangoHud binary used MAHUBIN="/usr/sbin/mangohud"

This config gets auto filled at some point and if the bin is found it gets put there. If it is blank Mangohud will never be activated when using STL.

After going back to look at this I guess I was wrong about Gamescope since only Mangohud appears to ave this as an option in their config.

[Samueru-sama]

I just let the prismlauncher folks know about a way to check for java.

Regarding STL, it is odd that one has to specify the path to the mangohud binary instead of just trying mangohud in PATH.

[LostWarriorr]

Regarding STL, it is odd that one has to specify the path to the mangohud binary instead of just trying mangohud in PATH.

I'm not sure the reasoning behind it either. What I do know is that when I have installed it via flatpak and when using steam through distrobox (currently) it was unable to find it and needed me to manually set it.

[Samueru-sama]

@LostWarriorr https://github.com/Samueru-sama/Steam-appimage/releases/tag/continuous

Test that appimage and let me know if it fixes the issue.

[LostWarriorr]

Steam Tinker Launch appears to not be able to find some of its dependencies needed on the host system:

Thu Aug 29 11:12:26 PM CDT 2024 INFO - main - Checking internal dependencies: Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps - git not found! Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps - xdotool not found! Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps - xwininfo not found! Thu Aug 29 11:12:26 PM CDT 2024 INFO - setAwkBin - Found 'gawk' as an 'awk' variant. It should work without any issues, because 'gawk' was tested completely Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps The dependency check can be disabled by enabling 'SKIPINTDEPCHECK' - exiting now

This results in it being unable to launch. I'm not sure if this is a weird situation like with Mangohud where it chooses a set path for the bin and if different suddenly won't work.

[Samueru-sama]

Steam Tinker Launch appears to not be able to find some of its dependencies needed on the host system:

Thu Aug 29 11:12:26 PM CDT 2024 INFO - main - Checking internal dependencies: Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps - git not found! Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps - xdotool not found! Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps - xwininfo not found! Thu Aug 29 11:12:26 PM CDT 2024 INFO - setAwkBin - Found 'gawk' as an 'awk' variant. It should work without any issues, because 'gawk' was tested completely Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps The dependency check can be disabled by enabling 'SKIPINTDEPCHECK' - exiting now

This results in it being unable to launch. I'm not sure if this is a weird situation like with Mangohud where it chooses a set path for the bin and if different suddenly won't work.

Well looks like I also need to add git, xdotool and xwininfo.

[Samueru-sama]

Steam Tinker Launch appears to not be able to find some of its dependencies needed on the host system:

Thu Aug 29 11:12:26 PM CDT 2024 INFO - main - Checking internal dependencies: Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps - git not found! Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps - xdotool not found! Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps - xwininfo not found! Thu Aug 29 11:12:26 PM CDT 2024 INFO - setAwkBin - Found 'gawk' as an 'awk' variant. It should work without any issues, because 'gawk' was tested completely Thu Aug 29 11:12:26 PM CDT 2024 ERROR - checkIntDeps The dependency check can be disabled by enabling 'SKIPINTDEPCHECK' - exiting now

This results in it being unable to launch. I'm not sure if this is a weird situation like with Mangohud where it chooses a set path for the bin and if different suddenly won't work.

try again on the same link as before.

[LostWarriorr]

Steam Tinker Launch is able to be used. Gamescope and Mangohud were successfully launched through it on a windows game using GE-Proton-9-11. Since it is somewhat independent of steam I will assume everything else will work as normal.

However as I mentioned before I'm pretty certain it checks for the Mangohud binary on either first launch or install. Since I already had it installed I believe it pointed to my Distrobox as posted in my comment above. I do not have it installed on my host system:

`## The MangoHud binary used MAHUBIN="/usr/sbin/mangohud"

Pointing it towards /tmp/conty_$USER_48ea51b_864b991/mnt/bin/ it was also able to launch. However I am not sure if the string of character after my name will ever change or not. If it does the link will be broken and will need to be pointed towards again. Every time I run the Appimage it is the same but I have not tried restarting to see if it does.

In terms of user accessibility Protonup-Qt is unable to install Steam Tinker Launch. This means if one chooses to use the Appimage they will have to install it manually. This issue is not related to that and can be talked through over with them in the future.

Once you answer if the folder path will be changed or not and it gets merged into the main branch I say this Feature Request can be closed.

[Samueru-sama]

That path is likely going to change.

However you might be able to always get it by using something like:

MAHUBIN=/tmp/*conty*/mnt/bin/mangohud

I see STL is just a shell script, so what I posted should should work, or maybe something like MAHUBIN="$(ls /tmp/*conty*/mnt/bin/mangohud | head -1)"

edit: If you want to install the appimage, check this https://github.com/ivan-hc/AM

That will make the appimage show in your list of applications, I don't know if Protonup-Qt needs more than that.

[LostWarriorr]

Neither of those options work. However there is an toggle called "MangoHud Variable" the config describes it as so:

'## Set the MangoHud variable MANGOHUD to 1 and ignore other MangoHud settings MAHUVAR="1"

This works and I can confirm it is using the one from the Appimage as I removed Mangohud from my Distrobox temporarily.

Offtopic: I'm going to assume Appimages have a higher RAM usage than other formats (at least native). This is probably one of the biggest Appimages in size so it issue is more noticeable because of that.

Appimage: ~1.3 GiB not even counting the steam services

Running it in my Distrobox is almost 1 GB less. Not a major issue for me but it is something that could be noticeable for some. But then again, unused RAM is wasted RAM.

[Samueru-sama]

Neither of those options work. However there is an toggle called "MangoHud Variable" the config describes it as so:

'## Set the MangoHud variable MANGOHUD to 1 and ignore other MangoHud settings MAHUVAR="1"

This works and I can confirm it is using the one from the Appimage as I removed Mangohud from my Distrobox temporarily.

Offtopic: I'm going to assume Appimages have a higher RAM usage than other formats (at least native). This is probably one of the biggest Appimages in size so it issue is more noticeable because of that.

Appimage: ~1.3 GiB not even counting the steam services

Running it in my Distrobox is almost 1 GB less. Not a major issue for me but it is something that could be noticeable for some. But then again, unused RAM is wasted RAM.

Yes we are aware that this method uses more RAM.

However if you use zram, then that RAM usage will greatly decreased since you will get a very high compression ratio due to it being a lot of duplicated data.

Ideally the conty appimages should be able to launch host binaries which right now is not possible, it can be done and it is being done in the ArchImages which use Junest for example.

Unfortunately I don't have much time to be able to look and test the differences between conty and junest, but if done that should save us a good 300 MIB from the appimage, which would translate to about 1 GiB less of RAM usage.

However worth mentioning that when I used the Steam flatpak I had weird issues running out of RAM with BeamNG with Proton within 10 seconds of starting a map, I've only had this happen with the appimage once and it was after playing for a while and when the appimage was 800 MiB (that was the original size lol). Never had it anymore since then, in fact I've playing BeamNG testing the changes I just did all this time.

[LostWarriorr]

However if you use zram, then that RAM usage will greatly decreased since you will get a very high compression ratio due to it being a lot of duplicated data.

I do have zram setup and figured that neofetch would figure it out but I guess not. Either way it is useful info for me If I Tell others about it.

Unfortunately I don't have much time to be able to look and test the differences between conty and junest, but if done that should save us a good 300 MIB from the appimage, which would translate to about 1 GiB less of RAM usage.

I figured there was still some more polishing to do. First time I looked at this was back in April and it has come a long way since then. I will continue to use it for now and report back any potential issues I find.

[Samueru-sama]

I do have zram setup and figured that neofetch would figure it out but I guess not. Either way it is useful info for me If I Tell others about it.

Note that zram only compresses when the ram usage gets high, if you have more than 8 GiB launching the appimage alone wont be enough to trigger it unless you start a game as well.

htop has a zram meter that has to be enabled that you can check, and you also get the compression ratio from it.

I figured there was still some more polishing to do. First time I looked at this was back in April and it has come a long way since then. I will continue to use it for now and report back any potential issues I find.

Thanks, by the way what GPU do you have? We seem to be having issues with nvidia users so I'm wondering what you have.

[LostWarriorr]

Thanks, by the way what GPU do you have? We seem to be having issues with nvidia users so I'm wondering what you have.

CPU: 5800x3D GPU: 6800XT Distro: Debian 12 + Backports: (Pipewire, Corectrl, Kernel) DE: XFCE

Hopefully that covers everything that could potentially be an issue for others.

I do have a 750 Ti sitting on a shelf but I have never tried to use Nvidia on Linux and don't think it will be worth to hassle when there are others out there that have much more recent cards to bug test with.

[ivan-hc]

The workflow on github action has failed, I'll re-run it to made the new release available, with new changes by @Samueru-sama