Zugg Software :: View topic

Posted: Sat Nov 10, 2007 1:00 am

I haven't had time to write any documentation for the new Script Debugger, but it should me mostly obvious how it works.

The menu option is in the Window menu. If you have a saved layout for an existing session, the the "Script Debugger Window" option will probably be at the bottom of the Window menu. You can customize your menu toolbar to move it to a better location if you want. In new layouts, it is shown above the list of your session windows in the Window menu.

You can also open the debugger window using the #DEBUG (shortcut #DEB) on the command line without any arguments. If you specify an argument of 0 or 1 for #DEBUG, then it will disable or enable the debugger (same as clicking the Enable button in the debugger toolbar). If you give a string argument, the string will be sent to the debugger window. If you use a string value of just - (a hyphen), then a horizontal rule (HR) will be drawn in the window. The #DEBUG command recognizes both ANSI color and MXP tags.

To control which debugger messages are shown in the window, use the Messages menu in the debugger. There are several message categories shown in that menu and they are mostly self explanatory. The Options menu can be used for stuff like timestamps and wordwrap. You can toggle between delta (relative time) or absolute timestamps, but you cannot change the timestamp format for the debugger window.

In the Edit menu, the Ctrl-C is assigned to the "Copy with time" option that will copy the text along with the timestamps. Saving the debugger window to a file using the File/Save command will also save the timestamp values.

You can open the Class Tree panel using the arrow to the left of the File menu, or via the command in the File menu. This will display all modules/windows and the classes within them. You can control which classes/windows/modules debugging is enabled for. By default, debugging is enabled for everything. This information is saved with your package.

Unlike the Settings Editor, the Class Tree will *not* automatically update itself as classes are added or removed. Clicking on a class that you have removed might crash. If the classes or windows/modules have changed, use the Update button at the bottom of the class tree to reload it.

When posting dumps copied from the debugger window, be sure and copy/paste only what is needed to illustrate your bug or problem. The debugger can produce a *lot* of text and nobody will read your post if you paste hundreds of lines into the forum.

I'm sure there are plenty of problems in the debugger to fix, so please post those into SEPARATE topics for bug reports. I think it turned out pretty good considering I only worked a week on it along with the timestamp stuff. But I'm sure there are some rough edges. At least it should allow people to determine why certain scripts are slow.

Have fun!

Posted: Sat Nov 10, 2007 2:42 am

Btw, when you first open the Script Debugger window, it will probably be hidden behind the main CMUD window. The focus is returned to the MUD command line when you open the debugger, and that can cause the main window to hide the debugger window. But you should notice a task-bar icon for the debugger window, so it's easy to select it and move it where you want it.

Posted: Sat Nov 10, 2007 6:21 am

When you have the Show Window name option enabled, each line will start with:

WindowName |

If the | character is replaced with an = character, that means the line is the result of a #CW, #PCOL, #SUB, or #PSUB command. So you can see the original text received from the MUD, along with each step in any substitution or coloring triggers that you might have.

If the | character is replaced with a > character, that shows the raw text that is actually sent to the MUD. You'll never see this unless you are connected to a server...it really shows the raw data sent to the server.

If the | character is replaced with a * character, that means the raw text received from the MUD that is shown was in a compressed MCCP packet. So this only happens for the "Show raw input" message.

If you turn on the Show ANSI message in addition to the Show Lines from server, then you might actually see each line from the server shown in the debugger window twice...the first line (the Show Lines message) will show the line in the color that was received from the MUD. Then, if the Show ANSI message is on, you'll see the line displayed again with any ANSI color values expanded as control characters. If there are not any ANSI codes in the line, then the ANSI line is not shown.

When a thread is shown in [], the name of the thread given after the [] thread number is the name of the thread as it was first created. CMUD gives a thread a name when it is created that shows the name of the window, followed by the type of setting being executed (like Trigger, Event, etc). If it is the command line thread, then you will see "windowname ComLine" for the thread name.

However, since CMUD will reuse a thread from the thread pool, these threads are not getting renamed when they are reused. So the thread name can be a bit confusing when looking at the debugger output. In the future I'll try to fix this so that the threads have more meaningful names.