Legacy:UDebugger

Before you start

1. Make sure you have the debug packages installed (See UnrealScript Source).
2. Make sure you have the latest version of the debugger from Epic. In UT2004 Udebugger comes with the game.
3. Make sure you build your own packages using the -debug option before starting the debugger

To start a normal debugging session

1. Optionally set StartupFullScreen=false in the [WinDrv.WindowsClient] section of the UT2003.ini or UT2004.ini file. (Alternatively you can hit ALT-ENTER to toggle fullscreen anyway).
2. Start UDebugger.exe
3. Set breakpoints, watches, etc. you'd like to debug during your session.
4. If debugging 'Access None' errors, make sure to select "Break On Access None" in the debugger options menu.
5. To close the debugger, exit the game normally.

To start a UDebugger server session

1. From the command line, start UDebugger using the following command line: UDebugger MapName?Game=GameType -server
2. Set breakpoints, watches, etc. you'd like for your mod
3. 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.
4. 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.

Bugs and Quirks

• UDebugger does not log to the main 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 for UT2003.

• 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.

UDebugger does not correctly handle invalid breakpoints. This means if you quit without removing breakpoints then recompile the code where the breakpoints were set, udebugger crashes with many Access Violation errors. On clearing these errors, breakpoints will not work properly in udebugger. To prevent this, remove lines from the [UDEBUGGER.BREAKPOINTS] section of udebugger.ini that pertain to changed code.

• Setting a breakpoint by right-clicking often sets the breakpoint much earlier in the code. More accurate control is possible by setting breakpoints by left-clicking in the empty column where UDebugger places the red dots for breakpoints.

• You can't see the interal values of structs or arrays, so you need to change your code to write the member value to a simple variable.

UDebugger will list the values of simple local variables, but will not display the values of expressions, array members, struct members, nor the return values of functions. When debugging, get in the habit of separating your steps more and using local variables more. For example, instead of a compact piece of code like this:

struct WeaponItem 
{
	var class<Weapon> WeaponClass< SEMI >
	var string WeaponName;
	var class<UTWeaponPickup> PickupClass< SEMI >
	var class<Ammunition> AmmoClass< SEMI >
	var class<Pickup> AmmoPickupClass< SEMI >
	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< SEMI >
			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.

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.

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."