Closed RomeuG closed 10 months ago
sonic2kk
commented
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 :-)
RomeuG
commented
10 months ago sonic2kk
commented
10 months ago 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.
RomeuG
commented
10 months ago 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.
sonic2kk
commented
10 months ago 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 :-)
sonic2kk
commented
10 months ago 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.
RomeuG
commented
10 months ago 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!
sonic2kk
commented
10 months ago 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.
RomeuG
commented
10 months ago 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?
sonic2kk
commented
10 months ago 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:
RomeuG
commented
10 months ago Indeed, I do confirm that using STL as a compatibility tool does fix the second part of the OP issue, fortunately!
sonic2kk
commented
10 months ago 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.
RomeuG
commented
10 months ago 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
sonic2kk
commented
10 months ago 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.
RomeuG
commented
10 months ago 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?
sonic2kk
commented
10 months ago 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 :-)
RomeuG
commented
10 months ago 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.
sonic2kk
commented
10 months ago 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!
RomeuG
commented
10 months ago 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?
sonic2kk
commented
10 months ago 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?
RomeuG
commented
10 months ago 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.
sonic2kk
commented
10 months ago 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:
RomeuG
commented
10 months ago 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.
sonic2kk
commented
10 months ago 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 :-)
RomeuG
commented
10 months ago 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!
sonic2kk
commented
10 months ago 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.
RomeuG
commented
10 months ago 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.
sonic2kk
commented
10 months ago 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.
RomeuG
commented
10 months ago So, I tested the branch and it's working as expected, both paths!
sonic2kk
commented
10 months ago 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!
RomeuG
commented
10 months ago @sonic2kk
Hey, thank you for actually taking the time to solve it. Very much appreciated, really!
sonic2kk
commented
10 months ago 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 :-)
sonic2kk
commented
10 months ago 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 :-)
RomeuG
commented
10 months ago Ok great! I guess that problem wasn't that important because I didn't have any issue. Thank you so much!
sonic2kk
commented
10 months ago No problem! Please let me know if you have any furrther problems and I'll try investigate asap :smile:
sonic2kk
commented
10 months ago Got a fix up for downloading x64dbg, at #952. Feel free to test if you have some time :-)
RomeuG
commented
10 months ago Great job. Just tested the branch x64dbg-dl-fix and it works perfectly, seamlessly.
sonic2kk
commented
10 months ago 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!
RomeuG
commented
10 months ago Ok, sure! You may close this issue whenever you feel like it. Thank you, once again!
sonic2kk
commented
10 months ago 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 x64dbgand put the game in a steam collection calledx64debugbut the game always starts without x64dbg.From the logs, that you can find below, it seems
steamtinkerlaunchtries 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, andx32dbgexecutable file is inside the expected directoryLogs