0004173: Add failure check for when the test-release file is not found and show a popup

Notes
(0024058) Zalewa (developer) 2024-10-09 20:04	Perhaps checking for error code 9009 and displaying a popup box should be enough. I will check it out.'https://stackoverflow.com/a/23095106/1089357 [^]' IIRC the original idea for even having the bat files in the first place was that Doomseeker creates such a bat file (or sh file on Linux) for the user, and then the user has a convenient way of launching the testing build without Doomseeker.

(0024070) Zalewa (developer) 2024-10-19 14:11 edited on: 2024-10-19 14:13	A quick and non-invasive solution I wanted to implement here was to start the game and monitor its process for a short while after the start. If the process would finish with an error code, we could pop-up an error message at the least. This still has some caveats, and doesn't offer a fix, but is at least somewhat better than just failing silently. Now I've looked into this more closely and the matter is not that trivial because Qt gets in the way. We're using QProcess::startDetached() to launch the game, which immediately makes Doomseeker loose the track of the launched process. At first it seems that this method should be enough, because it checks the status code to see if the process started correctly, but since we're going through a .bat file here, which does start correctly and only fails to run its own program, then everything looks fine from the perspective of this check. Starting a process where it can actually be monitored is done via QProcess::start(). This differs under the hood from startDetached(). Here are the relevant implementations in Qt 5.7 for Windows: 1. start():'https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qprocess_win.cpp?h=5.7#n454 [^]' 2. startDetached():'https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qprocess_win.cpp?h=5.7#n862 [^]' Most importantly, if a QProcess is not detached, it brutally kills the started process when it is deleted: 'https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qprocess.cpp?h=5.7#n1254 [^]' Meaning that a properly behaving, unbugged (without mem leaks) Doomseeker would close all the processes it started when it itself is closed. And that's not something we want. Detaching a process after it has started is not directly possible in Qt. Now, it's possible to vandalize the QProcess to not kill its monitored process when it itself is closed, but the differences in how start() and startDetached() behave may come with more consequences that can't be tested on a short notice and could simply break stuff. I would rather not do that for the release of Doomseeker 1.5.0. An altnernative solution would be to drop the .sh/.bat files and run the testing executable directly. The .sh/.bat files are useful, though, for the reason explained in my previous comment 0004173:0024058. So Doomseeker should retain the functionality to generate them (on demand, at the least). I didn't explore the effort needed to do this properly, yet. Keep in mind that Doomseeker doesn't only use the .bat files to launch online clients, but also proposes them in the "Create Game" dialog box.

(0024074) Blzut3 (administrator) 2024-10-20 21:58	I don't immediately see anything in the linked source code regarding creating a job object ('https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects [^]' ) which allows for keeping track of child processes on Windows, so I'm a bit surprised to hear that Qt killing the batch process also kills the game engine? Given game engines use the Windows subsystem they should automatically detach and the batch script exits more or less immediately no? What you wrote sounds right for Linux/macOS, although it might be possible to simulate Windows's detach behavior in the shell script with the disown command or maybe nohup. If it is indeed the case that QProcess kills all child processes then yeah your conclusion sounds right to me.

(0024076) Zalewa (developer) 2024-10-21 15:56	This is correct. The game process detaches from the batch process and Doomseeker doesn't kill it. However, the same launcher code that launches batch scripts also launches normal game executables outside of the testing builds. Run a non-detached, non-testing Zandronum client, which is launched directly through the .exe file, and it will die with Doomseeker. The hacky solution that could work is provided in this SO answer, but, because it's hacky, I didn't want to implement this right before a release: 'https://stackoverflow.com/a/36562936/1089357 [^]' I didn't think of making a special case for the Zandronum plugin only, directly in the plugin, because this would omit Doomseeker's normal launching routines. That's non-elegant and, again, too soon before the release.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2023-12-01 17:57	Necrodoom	New Issue
2024-07-27 15:10	Zalewa	Assigned To	=> Zalewa
2024-07-27 15:10	Zalewa	Status	new => acknowledged
2024-07-27 15:10	Zalewa	Target Version	=> 1.5.0
2024-10-09 20:04	Zalewa	Note Added: 0024058
2024-10-09 20:04	Zalewa	Status	acknowledged => assigned
2024-10-19 14:11	Zalewa	Note Added: 0024070
2024-10-19 14:13	Zalewa	Note Edited: 0024070	View Revisions
2024-10-20 21:02	Zalewa	Assigned To	Zalewa =>
2024-10-20 21:02	Zalewa	Status	assigned => confirmed
2024-10-20 21:58	Blzut3	Note Added: 0024074
2024-10-21 15:56	Zalewa	Note Added: 0024076

Relationships