Closed sonic2kk closed 10 months ago
Tested with this new option on and x64dbg off, everything works good. When x64dbg is not installed, RUN_X64DBG
is set to 0
, so there are no worries of any problems when x64dbg is not installed.
Langfiles bumped, shellcheck green, this works in testing, so it should be ready to merge!
Addresses part of #947.
Overview
This PR adds an option to checkbox toggle to control a new variable
X64DBG_ATTACHONSTARTUP
. This controls whether the game EXE is attached tox64dbg
on startup, and it is enabled by default.Implementation
Default Attach Behaviour
It's on by default because this should have been the default behaviour, but it was not due to a bug.
winepath -w
was returning a lot of spew before the game path, which meantx64dbg
could not actually read the standalone game path. This has been fixed by gettingtail -n1
of thewinepath -w
output, and nowx64dbg
will start with the game process as it should have (and as it may have done previously).There was another issue with this default process flow, where when x64dbg was closed, the game would start anyway. This has been fixed by doing a check on this new
X64DBG_ATTACHONSTARTUP
control variable before we launch the game inlaunchSteamGame
. IfUSE_X64DBG
andX64DBG_ATTACHONSTARTUP
are both enabled, then we can assume x64dbg will manage the game launch and that we don't need to do it.New No Attach Feature
Finally, a new flow has been introduced based on discussion in #947, which was the main reason for adding this checkbox. In some cases a user may want to disable this, for example if they're having trouble attaching the right process by default, or if they want to only attach to a certain game process. So we allow the user to disable attaching the game process by default, and allow the game to launch normally, and x64dbg to launch independently. We do this by sleeping, then running x64dbg, and continuing on to launch the game process. We need to sleep otherwise x64dbg will open and for some reason prevent the game from opening.
The sleep value is a magic number, hardcoded to
5
for now, because1
didn't work and I didn't encounter a case in testing where any value above5
was required. It worked in all my tests with as low as2
as well, but I decided to go with5
to be as generous as possible without introducing too much of a wait. We could introduce an option to adjust this in future if needed, though.Since on this path the game is launched by STL normally and has to be attached to x64dbg after-the-fact, we don't have to worry about it launching after x64dbg is closed. Likewise, when the game process is attached to x64dbg, closing the program will close the game process. So in every instance, the game processes and x64dbg should now open and close more cleanly.
Future Work
GitHub changed how it renders the releases page a while ago, and this broke MO2 and Vortex. We fixed that (#592), however it seems we missed x64dbg. Since x64dbg doesn't use tags in the same way, we'll need to figure out another way to find and then download the correct release.
This PR was tested by me and also tested by the reporter in #947, so it should be ready to merge after some quick code review and langfile updates. This should work for Steam games and Non-Steam Games. As far as I know, this is not applicable for Native Linux games.