UDebugger

Here's some general tips as well as step by step how I use the debugger (I don't know if this is how it's intended to be used, but whatever).

Make sure you have the debug packages from Epic.
Make sure you have the latest version of the debugger from http://unreal.epicgames.com. The latest version of uDebugger can be found in the 2136 debug source file available from there. This version of the debugger is not in any of the official patches, and was not included in the 2166 source file release.
Make sure you build your own packages using the -debug option before starting the debugger

To start a normal debugging session

Make sure that StartupFullScreen is set to false in the [WinDrv.WindowsClient] section of the UT2003.ini file.
Start UDebugger.exe
Set breakpoints, watches, etc. you'd like to debug during your session.
If debugging 'Access None' errors, make sure to select "Break On Access None" in the debugger options menu.
To close the debugger, exit the game normally.

To start a UDebugger server session

From the command line, start UDebugger using the following command line: UDebugger MapName?Game=GameType -server
Set breakpoints, watches, etc. you'd like for your mod
Start up a client UT2003 by double clicking the UT2003.exe file, and join your own dedicated server. Depending on where you set your breakpoints, you may need to play the game a little before you hit a breakpoint, but you get the idea.
To close UDebugger.exe and its associated instance of UT2003.exe (the dedicated server that you started), I've found the only reliable way is to issue an admin quit command either from console logged in as admin, or from webadmin. Closing it any other way causes udebugger to hang (i.e. closing udebugger itself, task manager, etc.). However, if you issue an admin quit to the dedicated server, it will close and bring udebugger with it.

Some misc. stuff I've figured out/seems to work/lucky guesses:

UDebugger does not log to the UT2003.log file, but to the UDebugger.log instead. Be aware of this when checking your log after a debugging session.
Haven't been able to get watches to work. Period.
You can manually add breakpoints without having the UDebugger open by editing the UDebugger.ini file, in the [DEBUGGER.BREAKPOINTS] section. The format of this section is as follows:

        Breakpoint0line=50
        Breakpoint0Class=ENGINE.ACTOR
        Breakpoint1line=100
        Breakpoint1Class=ENGINE.GAMEINFO
        etc.

If you are running UDebugger.exe, set breakpoints, work a while, then quit without unsetting those breakpoints, make some changes, then recompile, the next time you start the udebugger, you get all sorts of Access Violation pop-up boxes. Each time you click the OK button on an error pop-up, another one pops up immediately, to the point where you'll have 30 or so pop-up boxes on the screen because the screen won't refresh until it figures out whatever it needs to figure out. Two ways out of this: If you just continue to click the OK buttons on those error popups, eventually it'll make a different sound, and a bigger, but different error message will popup. When that happens, all the little Access Violation popups will go away and everything will seem to be operating normally. Except that setting breakpoints will have no effect. udebugger simply won't break no matter what you do. Second way out of this is to end task in task manager. This ends all popups immediately... but isn't much use since you'll get the exact same errors when you start it up again. May as well continue to click those error boxes...

Moral of the Story: If you have breakpoints set when you close UDebugger, it will save the locations of those breakpoints. However, if you change the source and recompile, then those breakpoints may not be on valid breakpoint lines anymore, but UDebugger doesn't realize this. Unset all breakpoints before closing UDebugger, especially if you're going to be recompiling.
I'm used to setting breakpoints by right-clicking the line I want it set on, and selecting Set BreakPoint. However, this doesn't really work too well in the debugger (usually sets the breakpoint like 100 lines too high or something), so try this instead: To the left of the editor window for the code, there is an empty column where UDebugger will place a red dot for breakpoints. If you click this area on a line without a red dot, it will add one. If you click the area on a line with a red dot, it will remove it.

You can't see the interal values of structs or arrays, so if you use alot of them (like I do) then you should set the member that you're attempting to debug equal to a local variable or something. UDebugger will list the values of local variables, but it cannot display the value of Name[i], for example. Nor is there any way to display the return values of functions. You'll get the hang of what I'm talking about when you work with it a little. I try to compact my data as efficiently as possible, and usually end up with Arrays of structs, which contain arrays themselves ... Unfortunately, this is completely un-debuggable, so get in the habit of seperating your steps more. For example, instead of a normal compact piece of code like this:

struct WeaponItem 
{
    var class<Weapon> WeaponClass;
    var string WeaponName;
    var class<UTWeaponPickup> PickupClass;
    var class<Ammunition> AmmoClass;
    var class<Pickup> AmmoPickupClass;
    var bool bEnabled;
};

var array<WeaponItem> Weapons;

function FillWeapons(array<class<Weapon> > WeaponClass)
{
    local int i, j;

    for (i=0;i<WeaponClass.Length;i++)
    {
        if (WeaponClass[i] == class'BallLauncher')
        {
            CannotBeDisabled[CannotBeDisabled.Length] = WeaponClass[i];
            return;
        }
        for (j=0;j<Weapons.Length;j++)
        {
            if (Weapons[j].WeaponClass == WeaponClass[i])
            return;
        }
        AddWeaponClass(WeaponClass[i]);
    }
    default.Weapons.Length = Weapons.Length;
}

You might need to expand it out a little:

function FillWeapons(array<class<Weapon> > WeaponClass)
{
    local int i, j, WeaponClassArrayLength, WeaponsArrayLength;
    local class<Weapon> WC, TempWC;

    WeaponClassArrayLength = WeaponClass.Length;
    WeaponsArrayLength = Weapons.Length;

    for (i=0;i<WeaponClassArrayLength;i++)
    {
        TempWC = WeaponClass[i];
        if (TempWC == class'BallLauncher')
        {
            CannotBeDisabled[CannotBeDisabled.Length] = TempWC;
            return;
        }
        for (j=0;j<WeaponsArrayLength;j++)
        {
            WC = Weapons[j].WeaponClass;
            if (WC == TempWC)
            return;
        }
        AddWeaponClass(WeaponClass[i]);
    }
    default.Weapons.Length = Weapons.Length;
}

Mychaeel: Is it necessary to run the game on a local dedicated server or is it possible to run botmatches too with the debugger? (Especially launching the server from within UT2003 strikes me as cumbersome.)

Evolution: Not at all. I simply do it this way because of the nature of the mods that I have been debugging. Most of the stuff I'm working with is related to admin / webadmin / advanced admin, and really isn't necessary to have a client instance at all, so a dedicated server is the best way so that I can focus on the debugger's screen.

And btw, the reason that the debugger was crashing upon starting had to do with breakpoints being set prior to starting the debugger, just as I had thought...but there is a much easier way to avoid the error messages. Simply open the udebugger.ini file and delete the breakpoints section before you begin debugging.

Unfortunately, although the debugger is supposed to work as a loader for ut2003.exe, (which would mean you could pass the debugger any parameters you could pass the ut2003.exe) I haven't noticed any command line arguments have any effect.

Evolution: Updated instructions to be a little clearer on this.

renniks: A couple of things I think is important to the novice mod developer is to be sure to set the StartupFullscreen property in the UT2003.ini file to false, and make sure to copy the debug .u files into the system directory. If you don't do that, you won't get very far. Setting the StartupFullscreen property to "false" allows you to easily alt-tab to the UDebugger. Making sure the debug .u's are in the system dir allows you to set breakpoints.

Mysterial: No need to change UT2003.ini, the game will automatically start windowed if another window has the focus when it loads. Alternatively, you can hit Alt-Enter once the game starts fullscreen.

liquiddark: Added a pre-step: you have to build your packages using -debug

Jon K: I've had some problems with udebugger that have limited its usefulness. Actually, they've made it useless. I was wondering if anyone had similar problems and found a way around them.

The first is that with patch 2225, the debugger hangs just as it's trying to launch the UT2003 splash screen video. I've tried it with numerous options from WOTgreal, with no luck.

I had better results with only patches 2136 or 2166 installed. It would run, but usually (though not always) when I would set a breakpoint or try to break into a running game, I would get a GPF with a stack trace that generally ended in a call to "UObject::GetFullName" from "UObject:: ProcessEvent" (for example "General protection fault! History: UObject::GetFullName <- UObject:: ProcessEvent <- (xPlayer DM-Antalus.xPlayer, Function XGame.xPlayer.PlayerTick) <- APlayerController::Tick <- TickAllActors <- ULevel::Tick <- (NetMode=0) <- TickLevel <- UGameEngine::Tick <- UpdateWorld <- MainLoop").

I really like debuggers, and am a bit dismayed at my lack of ability to use this one. I've followed all the instructions mentioned about about upgrading the debugger and putting in source and debug .u files. Any ideas?

Vishvananda: I have the same hanging problem as Jon K with 2225. Has anyone gotten this to work?

Harmeister: I could not get it to work with 2225. I got it to run sucessfully with 2136's UDebugger.exe and 2166's debug .u files. However I finally got WOTgreal up and running to be the controller of the debugger session with a new dinterface.dll. How to get the debugger working with WOTgreal, and the pain I had to go through (beyond the basic stuff described here) just to get the dumb thing up and running is documented at http://www.wotgreal.com . There's a link near the top called "WOTgreal and the UDebugger."

Category Application