Closed RomeuG closed 10 months ago
Interesting! I have never used this option since taking over the project, I'll investigate. Thanks for reporting!
Could you attach the log as a file instead of text please? It makes it easier to search through :-)
One part of your log that stands out to me is:
Sat Oct 21 03:33:06 PM WEST 2023 INFO - setflatpak - started SteamTinkerLaunch from /usr/bin/steamtinkerlaunch
Sat Oct 21 03:33:06 PM WEST 2023 INFO - initAID - Set AID to PLACEHOLDERAID '31337'
Are you definitely launching SteamTinkerLaunch from Steam as a compatibility tool (DLC Quest is a Windows game as far as I can see)? I'm not sure it would make a huge amount of difference but it's just something I noticed.
One part of your log that stands out to me is:
Sat Oct 21 03:33:06 PM WEST 2023 INFO - setflatpak - started SteamTinkerLaunch from /usr/bin/steamtinkerlaunch Sat Oct 21 03:33:06 PM WEST 2023 INFO - initAID - Set AID to PLACEHOLDERAID '31337'
Are you definitely launching SteamTinkerLaunch from Steam as a compatibility tool (DLC Quest is a Windows game as far as I can see)? I'm not sure it would make a huge amount of difference but it's just something I noticed.
Well, good point. I should clarify that: I am using proton as the compatibility tool but I am launching the game as steamtinkerlaunch %command%
in the game steam launch options.
EDIT: Ok, I think I am doing one thing wrong here. Launching as command line options is intended for Native Linux games. I should try using steamtinkerlaunch as a compatibility tool instead.
You need to use SteamTinkerLaunch as a compatibility tool for Proton games, the launch option is only for native Linux games, as noted on the Readme
I don't expect it to resolve much, but it is good practice :-)
Please bear with me as well, I have not used this option before (I took over the project from the original creator who implemented this 2 years ago it looks like) but I'll do my best to investigate.
No worries, and I'm so sorry, I really was doing it the wrong way. I am going to try to use steamtinkerlaunch
as a compatibility tool and I'll report back. Thanks!
I can reproduce the error: checkX64dbgLaunch - Installing failed - can't start '/home/user/.config/steamtinkerlaunch/downloads/x64dbg/release/x64/x64dbg.exe' - skipping
I didn't test any 32bit games, but I imagine the result will be the same, except it'll complain about x32dbg
.
So, using steamtinkerlaunch
as a compatibility tool didn't fix it at all. It still does not download anything. The issue persists.
If I download it manually and put it in the correct path, x64dbg
actually starts! But it will stay up without the game starting. If I close x64dbg
, the game will then start. Shouldn't both programs start at the same time?
So for the initial download failing, it seems like the way STL downloads this from GitHub no longer works. GitHub changed some things a while ago and we fixed it for some tools, but I guess others got forgotten, so I imagine this needs fixed first! :-)
If I download it manually and put it in the correct path, x64dbg actually starts! But it will stay up without the game starting. If I close x64dbg, the game will then start. Shouldn't both programs start at the same time?
I would say they should both start. Does this mean the second part of your OP issue is fixed?
I also tried to install x64dbg in the expected directory. After that, it does recognize that x64dbg exists and tries to run it, giving the following error
If that is fixed that is some good news, otherwise there are 3 things that will need to get sorted here:
Indeed, I do confirm that using STL as a compatibility tool does fix the second part of the OP issue, fortunately!
I think the error in extWine64Run
then is caused by STL not being able to get some variables needed to start a Proton game when used as a launch option. Nice to hear that's one issue down!
I'll first take a look at getting x64dbg to download properly. STL previously used to wget the GitHub releases page and then used grep to get the part of the page with the releases download links. It can still get the page, but that page now dynamically loads releases, so running wget -q https://github.com/x64dbg/x64dbg/releases/tag/snapshot -O test.html
(the commad STL uses to download the page) and opening it in a browser will show the releases page, but with that spinner for the assets section.
The fix for downloading x64dbg should hopefully just be a case of re-using some functions we have to download assets from GitHub.
Ok, great!
So, forgetting the issue about downloading x64dbg
, let's imagine everything goes well and it installs to the expected directory:
debug with x64dbg
, and I also use the x64dbg
steam collection (just to be sure).Here is a STL log for this specific case: steamtinkerlaunch.log
It looks like the game is maybe meant to be started by x64dbg
tool, but I'm not sure yet. The log from that run is helpful, thanks for attaching it.
Ah, good point! I was thinking about both of them starting so I could use x64dbg
to attach to the game. But indeed, I did try to start the game through x64dbg
, and the game did start. So I guess that part really isn't a bug.
EDIT: but in that case, should it start the game after closing x64dbg
, though?
EDIT: but in that case, should it start the game after closing x64dbg, though?
Yes, because once the start command for x64dbg ends, it moves onto the rest of the launch sequence. You can think of it as the Wine run command holds up moving through the rest of the script, preventing it from moving onto the part of launching the game.
If the desired behaviour is for x64dbg and the game to start at the same time, that can probably be achieved, but is this desired behaviour? I'll have to let you tell me, this is my first time using the program.
I should mention that manually extracting x64dbg did also get the program to open for me, so depending on the above, the main issue here is downloading x64dbg :-)
I agree that the main issue is downloading x64dbg
.
About the startup of x64dbg
, there are two ways of using it:
x64dbg
and use it to initialize the intended program/game/whatever.x64dbg
and game at the same time, and attach to the game through x64dbg
(this would be done manually by the user, but the wine prefix would have to be the same, AFAIK).So, it all depends on the user, really. I prefer having both open and attach to the game through x64dbg
. But that's just me, though.
EDIT: And maybe opening both at the same time would be better because of environment variables? I don't really know. Opening the game through x64dbg
might not use the env vars correctly. But I don't really understand that part.
EDIT2: As an extension from the previous edit, if I try to open Yakuza: Like a Dragon
through x64dbg
, I get some game specific error. While opening it normally through Steam just works. This could be an issue with x64dbg
itself, but the thing here is that I chose the .exe
file that maybe runs the game. If the game was already running, I could just attach to it.
Something interesting I noticed in the x64dbg log was this:
Handling command line...
"Z:\home\user\.config\steamtinkerlaunch\downloads\x64dbg\release\x64\x64dbg.exe" "wineserver: using server-side synchronization.
wine: Using setpriority to control niceness in the [-10,10] range
Z:\run\media\user\500GB SSD\Non-Steam Games\Touhou Fumo Racing\TouhouFumoRacing.exe"
File does not exist!
Aside from "File does not exist", the rest of this is the commandline output that STL passes over to x64dbg. It seems that sometime in the last almost 2 years since its implementation, the command that STL passes to x64dbg is wrong.
So STL is meant to give the game to x64dbg and I assume start it that way, but then once x64dbg is closed either game would close or even if it didn't, I think the game would open anyway.
EDIT2: As an extension from the previous edit, if I try to open Yakuza: Like a Dragon through x64dbg, I get some game specific error. While opening it normally through Steam just works. This could be an issue with x64dbg itself, but the thing here is that I chose the .exe file that maybe runs the game. If the game was already running, I could just attach to it.
It sounds like a good solution would be to just run the programs separately and get the user to manually attach the process :-) But I'll investigate and see!
So STL is meant to give the game to x64dbg and I assume start it that way, but then once x64dbg is closed either game would close or even if it didn't, I think the game would open anyway.
Makes sense. If I execute x64dbg
like ./x64dbg.exe random-executable.exe
, x64dbg
will open it, and I can say this because I tested a few seconds ago.
It sounds like a good solution would be to just run the programs separately and get the user to manually attach the process :-) But I'll investigate and see!
I would definitely prefer that way. But I can only speak for myself. Maybe should you offer the user a choice, in this specific case?
I have a work-in-progress fix locally for getting this program and the game to start together, and I can successfully attach the process.
Sorry for my ignorance here, but when I attach the game process to x64dbg
, is it expected that the game will close when x64dbg
closes?
Sorry for my ignorance here, but when I attach the game process to x64dbg, is it expected that the game will close when x64dbg closes?
Yes, if you close x64dbg
while it is attached to the game. If you detach the game from x64dbg
and close x64dbg
, the game should, probably, keep running.
Yes, if you close x64dbg while it is attached to the game. If you detach the game from x64dbg and close x64dbg, the game should, probably, keep running.
Can confirm I'm seeing this behaviour, thanks!
So locally I have two code paths that I can control by a comment. The first, I fixed the EXE path so it automatically getting attached to x64dbg. The game does not start on this path, it only gets attached.
The second path is where x64dbg and the game start together, but the process is not automatically attached. I need to do some code cleanup for this path as it's hooking into parts of the STL script that weren't meant for it, but I should be able to fix this up.
I think then we can add an option to toggle this on the GUI. Do you have any ideas on what would be the best way to do this? Maybe an option like "start x64dbg and game separately", and if so, which option should be the default? I'm asking for feedback because, well, this is a totally new area for me, so I'll trust the better judgement of someone who has used this software before :smile:
Thanks! This feature is great for people like me that do not want to install Windows, but still want to play around with Windows-only games, while checking its behavior in a debugger like x64dbg
.
I do think an option is needed. Sometimes it is very useful to attach before actually running it because it's sometimes useful to understand how the initialization works. Therefore, the default option should be the first path: the game doesn't start but gets attached automatically on x64dbg
. I think it's the more sane option.
I do think an option is needed. Sometimes it is very useful to attach before actually running it because it's sometimes useful to understand how the initialization works
This is a fantastic point, and now that you mention it I wholeheartedly agree. It makes sense to be a safe default.
It is also straightforward then to control whether the game launches when x64dbg is closed, because we can check if we disabled the option to attach the process x64dbg on startup.
Following this issue, the wiki will also be updated with some more information around this behaviour too.
This feature is great for people like me that do not want to install Windows
The less reason to use Windows, the better in my opinion :-)
It is also straightforward then to control whether the game launches when x64dbg is closed, because we can check if we disabled the option to attach the process x64dbg on startup.
Yes! I am also glad it helps you in that case.
The less reason to use Windows, the better in my opinion :-)
Exactly, and you're helping people achieve that!
Doing some tests and finalizing some wording, hoping to get a branch up with the changes to x64dbg execution. There is no fix for downloading x64dbg yet, it seems like that will be a little bit tricker.
Are you comfortable testing branches? If so, you'll be able to test out the new (hopefully working!) fixes for x64dbg's execution and see if it meets your needs. I'll send a reply once the branch is up.
There is no fix for downloading x64dbg yet, it seems like that will be a little bit tricker.
Sure, take your time. There is a workaround and that's fine by me.
Are you comfortable testing branches? If so, you'll be able to test out the new (hopefully working!) fixes for x64dbg's execution and see if it meets your needs. I'll send a reply once the branch is up.
I am, I'll test the branch when it's up.
The branch is up at x64dbg-fix
. The version is bumped, so a nice visual way to see what you're on the right branch right away is that the version should be v14.0.20231022-3 (x64dbg-fix)
.
This branch makes three changes:
x64dbg
-- It was getting confused with other Wine output, so we assume the last line of the winepath
command will be the sanitised game path (which it should be in every valid case). This fixes the default path of having x64dbg launch with the game process attached, so you can view initialisationx64dbg
. Now if you launch it with the game process attached, when you close x64dbg, the game should be marked as closed from Steam, and the game process will not start up again when you close x64dbg.I use the term x64dbg
, but I don't see any reason from the code point of view why this shouldn't work for 32bit programs as well, although I have not explicitly tested this yet.
Sadly, there is no fix yet for downloading x64dbg. I recognise that this is important so I am not brushing it off, however it is a less trivial fix. The way STL downloads programs from GitHub depends on their tags, and x64dbg does not use tags for their releases the same way other projects do. So I will need to investigate how to resolve this and properly download x64dbg. I will make a point of fixing it before closing this issue, so this is just an update to say I know it isn't fixed yet and that I am keeping it in mind.
My "workflow" so-to-speak is normally to get fixes up into a branch and then open a PR and merge. So because of that, if the fixes on the branch are working, I will merge that branch first, and then open a separate PR for the download fix. So these fixes will be merged in before the x64dbg downloading fix, and once they're merged, you should be able to use them in STL-git master without having to wait on me investigating the downloading issue, or stay on the branch for too long. If all goes well, I'm hoping to have the x64dbg-fix
branch merged in before the weekend is out.
So, I tested the branch and it's working as expected, both paths!
Awesome, I'm glad to hear it!
I'll do some cleanup, update the other langfiles, and hopefully get this merged tonight :-)
Thanks for the patience, this part of the code hadn't been touched in a long time and wasn't really a place I had ever spent any time, so even though it sucks you ran into it, now it'll be fixed for other users. Thanks for taking the time to report and test!
@sonic2kk
Hey, thank you for actually taking the time to solve it. Very much appreciated, really!
Sorry, I just realised I made a small mistake with how I was writing out to the config file. It shouldn't break anything but you may see some errors from the commandline along the lines of steamtinkerlaunch: line 6859: export:
$DESC_X64DBG_ATTACHONSTARTUP=': not a valid identifier`.
I found the cause of it and I'll fix it before merging the PR, which is available at #950. Should be merged into master soon, then I'll take a look at how to fix downloading x64dbg :-)
PR was merged into master, any STL version v14.0.20231022-1
or above should have this fix.
Next up is figuring out the downloads issue. Once that's fixed, this issue can be closed :-)
Ok great! I guess that problem wasn't that important because I didn't have any issue. Thank you so much!
No problem! Please let me know if you have any furrther problems and I'll try investigate asap :smile:
Got a fix up for downloading x64dbg, at #952. Feel free to test if you have some time :-)
Great job. Just tested the branch x64dbg-dl-fix and it works perfectly, seamlessly.
Awesome! I'll get it merged. It's not the best fix, but I can revisit it later. The URLs it's using haven't changed since 2015, so it's reasonably safe, but not as robust as the checks we do for MO2/Vortex/HMM. Since the wget for x64dbg is only for that project though I think it's safe :-)
This should be available in master shortly!
Ok, sure! You may close this issue whenever you feel like it. Thank you, once again!
Merged in, this issue was auto-closed by the merge.
Thanks for the report and glad we got this resolved quickly. It's always nice to see some of these lesser-known parts of STL get some fixes :smile:
System Information
Issue Description
I select the option to
Debug with x64dbg
and put the game in a steam collection calledx64debug
but the game always starts without x64dbg.From the logs, that you can find below, it seems
steamtinkerlaunch
tries to download x64dbg without success and because of that, x64dbg archive extraction does not work.I also tried to install x64dbg in the expected directory. After that, it does recognize that x64dbg exists and tries to run it, giving the following error, extracted from other logs:
It says
command not found
, but I don't know which command. Steamtinkerlaunch is inside/usr/bin/steamtinkerlaunch
, andx32dbg
executable file is inside the expected directoryLogs