Scripting:Debugger

From 4Dimensions
Jump to: navigation, search

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.


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.