Trying to Use custom command to launch Livespilt with Game using vulkan/DX, Games is Hades

[FluffyThing]

Having issues reading the wiki and watching some videos, and I tried just changing it to the livespilt.exe, but it will never save and revert back to "hades.exe"

I have tick the boxes to allow custom commands.

Really just want to get this working since there is an autospilter made for this game, and overall would greatly benefit linux speedruners.

any help suggestions or if im just doing this wrong would be helpful.

[sonic2kk]

When creating an issue you would've been prompted to follow an issue template. Please don't disregard this, fill out the issue template properly including attaching a log for the game execution (as mentioned in the issue template, this is at /dev/shm/steamtinkerlaunch).

Your issue is currently lacking enough information to try and help you. I just tested and it's working fine for me on v12.12 and latest master. Please update your issue to provide the information originally requested.

As for what you might be doing wrong, I am not sure. Just checking "use custom command" and changing the custom command executable to the desired executable is working fine for me. The option is saving just fine, too. One user on Debian said they had issues with the configuration file saving I think (#745) but that seemed to be not even saving the Proton version, so I don't think that's the issue here.

Without the log file that was requested in the ignored issue template, I can't really give any further advice.

---

I just tested launching a custom program with Hades, and even downloaded this "Livesplit" program and using it with Hades. It just shows this timer (as I have not done any configuration, so I believe this is expected), so I don't think there's a compatibility issue here.

The tool was downloaded from here for transparency: http://livesplit.org/downloads/

Both this program and Hades open for me, so the log is required to see what is up here. Perhaps there is some file path oddity, or a permissions issue.

---

You should check if other configuration options are saving for you, i.e. MangoHUD might be a quick and obvious one to check. I am not sure if you're using Flatpak STL but for now I'll assume not, so you can go to ~/.config/steamtinkerlaunch/gamecfgs/title and see if there is a Hades.conf file.

• If not, then that's the issue. Check the permissions on this folder and ensure they are correct
• If yes, check if the CUSTOMCMD key has the correct path to your Livesplit executable

You should also check the permissions for the drive/folder where Livesplit is saved. If it's downloaded onto another drive for example, check that the permissions (particularly the read and execute permissions) are set up correctly for however you would expect on your system.

If the file path for CUSTOMCMD in the game config is not valid (doesn't exist, or can't be read in which case it effectively doesn't exist to the program trying to read it) then STL will clear the path, and this you would see "Custom command (none)" on the UI. There should not really be a way for this to happen from the UI at least not one I have experienced, but a log would be helpful here, as the log will outline if there is an issue with the path not being found, for example:

Sun  2 Apr 04:29:31 BST 2023 WARN - setFullGameExePath - User enabled Custom Command, but custom command at '/path/for/custom/command' is not a file!

[sonic2kk]

I was able to reproduce a case of the executable not saving, whereby the path to the executable contains quotes, single or double (i.e. /home/username/'LiveSplit_1.8.25'/LiveSplit.exe or /home/username/"LiveSplit_1.8.25"/LiveSplit.exe. Backslashes in foldernames were also problematic.

This caused the executable to not be saved. I am not sure if mountpoints can have labels like this, and it is good practice not to name folders in this way, so I am not sure if this would be the issue.

If the path to your executable is not a standard path i.e. /home/gaben/Downloads/utilities/LiveSplit_1.8.25/LiveSplit.exe, then perhaps this is the issue. If you have a path like /run/media/Games/Gaben's Tools/LiveSplit_1.8.25/LiveSplit.exe, then that would be the issue, which is an interesting one I have not yet come across.

When a path contains these kinds of characters, it is written out to the config file without the characters. For example the path /home/gaben/Gaben's Secrets/Half-Life 3/hl3.exe would be saved as CUSTOMCMD="/home/gaben/Gabens Secrets/Half-Life 3/hl3.exe" - Without the quote. And of course, this path doesn't exist, so when STL feeds that into the Custom command widget on the UI, the path doesn't exist, and so it shows (None).

This stripping of these characters appears to be standard behaviour throughout the Game Menu. It is an edge case but I would be interested in seeing how feasible it is to "fix". Though I will wait to see if that is still the cause of this issue. If not then I may not spend much time on it, but if it is then I may look into seeing if it is fixable. Though generally naming files in this way is just asking for trouble so I have yet to see anyone do this on Linux in the first place 😅

EDIT: Interesting, when the path is entered into the config file manually, and the STL Game Menu is not loaded, then STL actually runs the executable. Somewhere along the way these special characters are being stripped out, and though I'm not sure where I have a suspicion it is intentional (to avoid cases of unescaped/unsafe characters being saved to the config file)

EDIT2: I am able to produce some very strange and random behaviours when trying to hardcode paths in the config file that have these odd characters. Not sure if it's worth trying to fix as it seems to just produce generally strange results with Yad, likely not something 99% of users will run into (no users have reported this issue to my knowledge in the last 1year+ that I've been around here). Still not even sure this is the root cause of the problem, but it could be.

[sonic2kk]

It's been several days with no response and no update to the opening issue to follow the issue template.

An action item from this could be to better allow for paths with special characters but these are edge cases. A user that runs into it could submit a patch and I would happily review, but I don't think it is anything that needs much time as a priority since, if the paths issue is what is causing this problem, it can be worked around by using standard path naming. A note has been added to the Paths wiki page around this, in case users run into issues. Perhaps it could be documented in a better location, but for now I think it's fine 🙂

Aside from the paths with special characters case I have been unable to replicate the issue as described. So I am closing this issue.

Please re-open or open a new issue to follow the issue template and note if the steps above did not work.