I'd hope you read the whole thing below, but here's the gist of it all:

• Grab the correct UnrealScript source and set it up in your game directory
• Make sure you have the correct version of WOTgreal (2.906 developer or higher)
• Move WOTgreal's dinterface.dll into the System directory
• Make sure your stuff is compiled with -debug
• Launch the Debugger from WOTgreal (UT 2003->Run Debugger)

The UDebugger is a line debugger for Unreal Script, however it has been notoriously difficult if not darn near impossible to get running properly. Also, as far as I know, it only has shipped with UT2003, although the other engines could have shipped it as well, I just don't know. This set of instructions is how to get the UDebugger for UT2003 working from within the context of WOTgreal, and to make WOTgreal the controlling IDE instead of passing control off to the UDebugger visual interface. The principles should be able to be extrapolated to other IDE's as well (if another stable IDE eventually exists).

The UDebugger works with UT2003 build 2136, 2166, and 2225. Build 2166 didn't have a UDebugger.exe included with it, but the one from 2136 works. So to make everything simple, I've bundled the source, the debug .u files, and the correct UDebugger.exe file up in a handy dandy zip file to ease the downloading nightmare I had trying to find all the stuff. After you have made sure that all old Epic (make sure not to delete your own) class files have been deleted from your system and that WOTgreal is shut down, simply extract the zip file into your games base directory (like C:\UT2003). Start up WOTgreal and re-build your trees. (Select a tree and hit F5 is probably the easiest way to do this.)

The debug .u files will need to be in your System directory (*please* make sure to back up your original files first). They are located in "System\2225 Debug U packages" if you got them from the afore mentioned zip file. When you compile your source code, you will need to compile with the -debug switch on the command line. WOTgreal won't be able to be used as the actual debugger, nor will it compile with the -debug switch, unless you are a trial version or have registered. Last, but not least, you need to replace the dinterface.dll that ships with UT2003 for one that can comunicate with WOTgreal. This file is available starting with the development build of 2.906 on 11/14/2003 07:59 AM. Make sure to back up the original dinterface.dll in the System directory and the place WOTgreal's version there (the WOTgreal version is located in the WOTgreal install directory, right next to WOTgreal.exe). The new dinterface.dll file should be ~90K in size.

To get this whole thing working within WOTgreal you first and foremost must have the class and package tree from within WOTgreal set-up properly. The core of everything within WOTgreal resides around these two trees (code and parameter completion, making sub classes, knowing how all the classes relate together, etc. Everything). You can *edit* code without this (and just that, nothing else will really work terribly well), but the debugger will not run without it. If you don't currently have this up and running properly, look in the Getting Started section of the WOTgreal help file.

Now once you have compiled your files with the -debug command, have the debug.u's in the right place, have the proper UDebugger.exe, and the WOTgreal version of dinterface.dll, you are ready to rock and roll.

To use the debugger from within WOTgreal you can do it in one of two ways. No matter what, WOTgreal has to be running first. Then you can either launch UDebugger.exe normally (double click on it in windows explorer for example), or click on the Run Debugger button/menu option from within WOTgreal. I recommend doing it from within WOTgreal so that your current breakpoints will get passed to the debugger properly. Otherwise they will probably be out of synch. When the debugger starts up it starts talking to WOTgreal and you should be good to go. You will notice a new menu appear for debugging, and a new toolbar appear on the top that has a play, pause, and some stepping options.

Breakpoints can either be set before the debugger starts, when it is paused (because a breakpoint has been hit or something), or while the game is running. Setting a breakpoint while the game is running is kind of tricky, but can be done. Once the game is paused because it hit a breakpoint, control is passed to WOTgreal where you can decide what to do. You can check the values of local and global variables, step into, over and out of the current procedure, set more breakpoints, etc. Watches, at least in the traditional IDE sense of a watch, do not work. Hopefully this can be fixed for UT2004, but since the game isn't even released yet who knows.

Now window focus sometimes becomes an issue. Since debugging was kind of retrofitted into the engine, and there isn't really a good way to communicate back and forth, window focus sometimes goes a little wonky. If you hit a breakpoint and WOTgreal doesn't get complete focus, use windows to Alt+Tab to it (although this part should always work). Or vice versa, if you click on continue and the game doesn't get focus, Alt+Tab back to the game.

The Unreal Script Debugger is still in it's infancy, but give it time and it will improve. Hopefully now it can at least be used more easily from within WOTgreal and we can help Epic flush the rest of the bugs out of it.

Also of note is how the engine is actually working. When the game is running (ie not in a paused state) it can, though it might not, take up near 100% of your CPU's power. If this occurs pretty much nothing else will respond because it can't get any CPU time until the game is paused somehow (minimize the window, pause the game, hit a breakpoint, etc.)