Open v322v322 opened 8 years ago
Interesting, could you provide an example of a use case for this?
I was trying to use the Ultamate Doom Visor mod, and the game would not appear to launch when I hit the "Play Doom" button (it appeared that nothing at all was happening). I had to copy the command line generated by RocketLauncher and try it manually from a terminal to see the error messages from Zandronum. With this change, I can just start RocketLauncher from a terminal, and see the error messages from the Doom engine. An alternative would be to have a window pop up with the output from the Doom engine subprocess piped to it, similar to what Doomseeker does with the output from a Doom server process, but the traditional thing to do with subprocesses is to connect their standard error and output to the parent process's standard output and error streams.
I recommend merging this.
Both of the attached screenshots show the state of a terminal after I've started RocketLauncher, started DOOM from RocketLauncher, closed DOOM and closed RocketLauncher.
With RocketLauncher2 built from the current master branch, this is what I see:
And if I merge this pull request, rebuild RocketLauncher2 and repeat the process, I see this:
I'm just a bit concerned about how this might affect behaviour on windows, some of the source ports, such as ZDoom & Zandronum, create their own small console window when launching in windows, I just need to make sure things like this don't break for any source port on windows.
Made the Doom subprocess forward its standard output and standard error to the parent rocketlauncher2 process so that error messages from the Doom process will not be lost. This is especially helpful when dealing with potentially buggy mods.