The debugger I use is to add echo statements within scripts in a way that doesn't otherwise alter the way the script runs. Something like:
echo -s $asctime($ctime,[HH:nn:ss]) $nopath($script) $scriptline
You can place these in as many places as you wish, helping you determine whether your script branched the expected way on an if() statement, is triggered by an event, etc. You can also include %variables, identifiers like $event or $ctimer to help trace why your script is glitching. If you want to echo a command where the variables and results of $iif() etc are replicated in the display, you sometimes need to add spaces to allow $identifiers and $variables to display their true values even though an if() statement can correctly function without.
If you don't want your debug messages being lost in the status window clutter, you can send the output to a @window instead using aline instead of echo. Check /help for any switches you might find helpful, like 'aline -p @window'.
If you use a consistent format for your debug messages, you can easily identify which message from which script is showing, allowing you to trim them when your glitch is fixed.
In some cases you'll want to have conditional logic to limit debug messages to certain conditions. For example if you have a debug message inside a dialog, showing debug messages for every 'mouse' $devent will flood your debug window.
To add debug messages sometimes requires adding brackets around existing code to make it behave the same way. For example, debugging this:
if (%var123 == 1) goto label
would need to change to something like:
if (%var123 > %var456) { echo -t @debug $nopath($script) $scriptline var123 %var123 var456 %var456 | goto label }
Sometimes the presence of your debug messages can slow down a script enough to prevent a glitch if inserting slow debug messages delay the code enough to prevent a timing-related problem, but that's rare.
