GUI editor doesn't shut down Doom 3 when it is closed

Monty · **Posted:** Mon May 07, 2012 10:38 pm

Hello,

I've recently started working with id Tech 4 for Windows, and right now I'm getting used to the Quake IV GUI Editor. It's an excellent tool, but I have a small problem with it.

It seems that Doom3.exe still runs after I've closed the editor's window; this forces me to manually shut down Doom 3 with the Task Manager every time I want to reopen the editor or the main game, because it can't run in more than one window.

A few notes:

I have the Steam version of Doom 3.
Once the editor is closed, there is no visible game window.
The issue arises whether I access the editor through a desktop shortcut or the in-game console.

Is there a way to make Doom3.exe shut down when the GUI editor is closed?

Thank you. This engine seems to have a lot of potential, and I'm anxious to see what it can do.

jmarshall23 · **Joined:** Tue Dec 06, 2011 8:05 pm **Posts:** 418

That is a bug with the gui editor(relating to freeing already freed memory or it trying to use something that was already freed I can't remember exactly), it wasn't that hard to fix if your willing to recompile the code.

Monty · **Posted:** Wed May 09, 2012 12:05 am

Thanks for the reply.

I can recompile it, do you know where the error can be found?

Perhaps somewhere in the <neo/tools/guied> folder? I'm not sure where to look, there are a ton of files.

jmarshall23 · **Joined:** Tue Dec 06, 2011 8:05 pm **Posts:** 418

Its been awhile since I fixed that, just run doom 3 open the gui editor and close it..it will break at the right place.

Monty · **Posted:** Thu May 10, 2012 8:56 pm

I've compiled everything and added all the assets from the base folder, but I can't seem to use the dev tools.

I can play the regular game without any problems, but when I type "editguis" into the console, it doesn't recognize the command; the same is true when I try "editor", "editdecls", "editlights", etc.

Do they need to be compiled separately?

jmarshall23 · **Joined:** Tue Dec 06, 2011 8:05 pm **Posts:** 418

No ensure your project config is set to debug with inlines.

Monty · **Posted:** Fri May 11, 2012 2:59 am

Hmm... I'm still getting the same results with that configuration.

I also tried Dedicated Debug with inlines but got some errors that I think are related to MFC, which I'm not using because I have VC++ Express.

I don't know what MFC was used for in the game, could that be the problem?

jmarshall23 · **Joined:** Tue Dec 06, 2011 8:05 pm **Posts:** 418

That was the next thing I was going to ask if you were using express, express versions of visual studio dont include MFC so that would be why you dont have the tools in your compiled build. Download the trial version of visual studio 2010 and you'll be fine as its a quick one time fix.

Monty · **Posted:** Sat May 12, 2012 4:43 am

Ah, you were right, it was because I was missing MFC. I'm sorry; if I had known, I would have mentioned earlier that I was using VS Express.

I did get an exception when I closed the GUI editor, but it didn't lead back to the code.

Here are the messages that were logged right after the error. Most are in French though, so here's a summary: I got 16 messages about 'Thread Win32' stopping with the code 0, an access violation, and another two exceptions that were returned by the engine.

Code:

Le thread 'Thread Win32' (0x1038) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0xca8) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x838) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x19c4) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x4a8) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x1014) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0xfb0) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x116c) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x108) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x1134) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0xa38) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x11d0) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x18b0) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x1750) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x428) s'est arrêté avec le code 0 (0x0).
Le thread 'Thread Win32' (0x16f8) s'est arrêté avec le code 0 (0x0).

Exception de première chance à 0x55b893c0 (gamex86.dll) dans DOOM3.exe : 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0x1d32d7f0.

Net_GetUDPPacket: WSANOTINITIALISED
Net_GetUDPPacket: WSANOTINITIALISED

From what I've read, the "Thread Win32" messages are normal.

The exception that comes after appears to involve my newly compiled gamex86.dll; as you said, it seems likely that the access violation was caused by improper freeing of memory.

I can't make heads or tails of the last two lines; all I could find out was that they probably came from a function called NET_ErrorString() in <sys/win32/win_net.cpp>.

I hate to post logs and ask others to tell me what they mean, but there's very little information online about these exceptions. Do you recognise any of these messages?

(Also, I should say, there's no rush. I greatly appreciate the help you've offered me so far, so if you have any ideas, you can post them at any time.)

jmarshall23 · **Joined:** Tue Dec 06, 2011 8:05 pm **Posts:** 418

Quote:

did get an exception when I closed the GUI editor

Are you building it with a debug configuration? If it didn't break than more than likely the debugging symbols aren't getting created.

Monty · **Posted:** Sat May 12, 2012 2:52 pm

Debug with inlines, as before.

The program does break when the window is closed (I have to manually stop the debugging process afterwards) but there doesn't seem to be any indication of where the error comes from.

Visual Studio doesn't open the problematic cpp file; the only clues I get that something's wrong are the logged output and Doom3.exe still showing up in the task manager (until I close the debugger).

Is VS not showing the origin of the error because the problem was found in gamex86.dll rather than Doom3.exe?

jmarshall23 · **Joined:** Tue Dec 06, 2011 8:05 pm **Posts:** 418

Copy and paste the call stack here.

Monty · **Posted:** Sat May 12, 2012 11:42 pm

Actually, the call stack window appears to be completely empty during the entire debug session.

On a side note, I should perhaps mention that when the GUI editor is opened, the music from the main menu keeps playing. Once I close it, the music stops.

I'm not sure what it means, but I'm wondering if it might be relevant.

jmarshall23 · **Joined:** Tue Dec 06, 2011 8:05 pm **Posts:** 418

I don't know what to tell you its just not loading the debug info, I haven't changed the UI Tools that much in idTech 4 CDK you can try pulling the ui code from there(as I fixed this paticular issue)

blackenmace.com <-- the svn link is in the forums.

Monty · **Posted:** Sun May 13, 2012 9:36 pm

I found this SVN address.

But what exactly should I copy? The code in the UI folder appears to reference quite a few files from various other parts of the engine, parts that aren't in the original Doom 3 source.

Doom3world

GUI editor doesn't shut down Doom 3 when it is closed

Who is online