Scripting:Debugger
The script debugger can be used to figure out what's happening in a trigger. This is easier than putting in echos and having to remove them afterwards.
The main command is dbg, followed by a number of subcommands. The syntax for each debugging command is given. It uses the | symbol to denote or: you need to choose between what comes before and after. Arguments between [] are optional in some cases. An argument between <> means what's in between should be replaced by something else. All subcommands may be abbreviated down to the first letter.
All debugging messages start with a yellow [DBG]. More than one imm can debug the same trigger, and each imm will see what the other is doing.
It's not possible to directly debug a load trigger since it doesn't exist at first. One way around this is to temporarily change the type of the trigger and debug it.
Debugging a death trigger is special in that when it hits a breakpoint, the mob dies and the trigger is destroyed. This is how it should be, otherwise a wait would postpone a mob's death. In this case you can also change the trigger type to debug it.
Contents
Start Debugging
The syntax is
dbg mob|obj|room [<name>] <trigger vnum>
To start debugging trigger 123 on a cow which is in the room:
dbg mob cow 123
Debugging trigger 234 on the room:
dbg room 234
Debugging trigger 177 on a worn or carried object, or when it's in the room:
dbg obj waybread 177
Display Info
The syntax is
dbg info [<number>] [breakpoints|variables]
To get the debugging list:
dbg info
It shows all triggers being debugged, if they're running, the breakpoints, and local and global variables. If there's more than one trigger you only get the trigger names. In that case doing
dbg info <number>
shows the detailed info for that trigger.
If you're only interested in the breakpoints you can do
dbg info [<number>] breakpoints
and to only see the variables:
dbg info [<number>] variables
Trigger List
The syntax is
dbg list [<number>]
It shows the trigger with line numbers, so you know where to set a breakpoint.
Setting Breakpoints and Variables
The syntax for setting a breakpoint is
dbg set [<number>] breakpoint <line number>
When a trigger reaches a breakpoint it stops running. This is because a breakpoint is a long wait inserted before the line where it needs to break. This gives you time to see the current state and go from there.
dbg set 2 breakpoint 34
sets a breakpoint at line 34 in debugged trigger 2. Giving the same command removes the breakpoint.
The syntax for setting a variable is
dbg set [<number>] variable <args>
It can only change existing variables:
dbg set variable var A new value
sets global or local variable var to A new value.
In this way variables don't have to be changed in the trigger itself when testing.
Printing expressions
The syntax is
dbg print <expression>
This prints the result of any scripting expression between the %% symbols. If you want to know the value of the local variable %x% you can look it up in dbg info, or do
dbg print %x%
It can also be used to see the result of an expression not related to the trigger:
dbg print %now% dbg print %time.moon%
Flow Control
The syntax for continuing a trigger is
dbg continue [<number>]
When a trigger is at a breakpoint, this resumes a trigger. Because a breakpoint is a wait, continue can also be used to skip long waits in the trigger.
The syntax for stepping through a trigger is
dbg next [<number>]
Next executes only the current line and breaks in the next. It's a quick way of going through a trigger line by line without having to set and remove breakpoints.
Stop Debugging
The syntax is
dbg delete [<number>]
The trigger is resumed if it was at a breakpoint and you were the only one debugging the trigger. Delete also happens when you logout.