Open mcc85s opened 2 months ago
Hello,
This is GtkRadiant and not NetRadiant. I don't know what NetRadiant does, they could have a completely different implementation of this stuff.
But I can answer for GtkRadiant - the version of q3map2.exe that we use has an option to stream out it's output over a TCP connection back to the editor.
This was useful in contexts where compilations were still being done on a much larger, shared central server, and it also had the advantage of being portable. It also allowed the debug stream to flag bad brushes and highlight them during the BSP phase, that sort of thing.
Iirc for tools that do not support the TCP streaming we just execute a batch file and don't really look at the output, until after completion maybe.
This was all written long before PowerShell existed, so it uses none of that. Capturing stdout/stderr from Win32 console applications is a notorious quagmire.
I think if I had to do this nowadays I'd use python's subprocess module which I'm pretty sure can do it and provide a reasonably sane API. It'll also be portable without over-complicating things which is always a bonus.
Of course this would all just wrap around suitable CreateProcess usage and you could go directly to that and write a Windows only solution (https://learn.microsoft.com/en-us/windows/win32/procthread/creating-a-child-process-with-redirected-input-and-output). That requires a level of proficiency with Win32 APIs that I don't care for though.
Interesting, maybe I can do something with the TCP session to get the result I'm looking for.
Yeah, I used to use GtkRadiant a lot, but for some reason if I run it today, it is extremely slow and unresponsive, and I think it has something to do with the graphics chip I have.
I didnt realize I was submitting this to GtkRadiant, but I would imagine that the approach is virtually identical.
Thanks for your prompt response, I appreciate it!
On Wed, Sep 25, 2024, 8:31 PM TTimo @.***> wrote:
Hello,
This is GtkRadiant and not NetRadiant. I don't know what NetRadiant does, they could have a completely different implementation of this stuff.
But I can answer for GtkRadiant - the version of q3map2.exe that we use has an option to stream out it's output over a TCP connection back to the editor.
This was useful in contexts where compilations were still being done on a much larger, shared central server, and it also had the advantage of being portable. It also allowed the debug stream to flag bad brushes and highlight them during the BSP phase, that sort of thing.
Iirc for tools that do not support the TCP streaming we just execute a batch file and don't really look at the output, until after completion maybe.
This was all written long before PowerShell existed, so it uses none of that. Capturing stdout/stderr from Win32 console applications is a notorious quagmire.
I think if I had to do this nowadays I'd use python's subprocess module which I'm pretty sure can do it and provide a reasonably sane API. It'll also be portable without over-complicating things which is always a bonus.
Of course this would all just wrap around suitable CreateProcess usage and you could go directly to that and write a Windows only solution ( https://learn.microsoft.com/en-us/windows/win32/procthread/creating-a-child-process-with-redirected-input-and-output). That requires a level of proficiency with Win32 APIs that I don't care for though.
— Reply to this email directly, view it on GitHub https://github.com/TTimo/GtkRadiant/issues/702#issuecomment-2375502131, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKWFP24R6OEMMIAFZOO5HWLZYNIU7AVCNFSM6AAAAABO3JWOJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZVGUYDEMJTGE . You are receiving this because you authored the thread.Message ID: @.***>
Greetings,
This is not an issue with Netradiant per se, however I'm curious to know how tools like (mbspc.exe/bspc.exe), qmap2.exe, etc. sends stuff to the console in your application, because I've been attempting to implement that into a WPF application I've been making that uses XAML and PowerShell that helps orchestrate the process of compiling and packaging a map
I'm not trying to build something as complicated as Netradiant, however, I want to use PowerShell to wrap and log all of the things I'm doing to a particular map, or multiple. Being able to redirect the standard output or error output from these tools has crashed with virtually every (attempt/approach) I've made.
I even took some time to try out various other approaches that Microsoft Copilot suggested.
So like, if I run something like this:
...that works, but the process has to complete before I can access or see any of that data.
But as soon as I try an approach like this...
...the process does something, but it locks up my console host and doesn't return anything to the screen, so I have to terminate the console host.
But I can see very clearly if I build the map using Netradiant, it updates the information on the fly.
Perhaps you could offer some insight...?