CSBwin/DSA/bug hunting tips

General

The first thing to say is always use the timer trace when something strange happens...you can try to follow the logic of your code, and usually find where the wheels are coming off quickly enough. Open using notepad and always use the 'find' option to zoom in to certain words if you have alot of activity going on - the name of the particular filter, a certain key 'type' value you know should be appearing, etc. Common things you can spot are stack overflows (if a command isn't geting used right, chances are it is leaking values, especially in a recurrisve loop). Get the hang of what the trace is saying, and diagnosing becomes so much simpler.

Also, if you get a DSA error and not sure where to start, be logical - start from the beginning and make sure each step works and move on to the next. Sometimes where the wheels are coming off can be because a bad value was fed much earlier into the array, or a rogue literal from earlier is combining with another error you would otherwise spot (like a stack underflow)

Errors

I already stated a few in a thread to add, but here's some of the many I've managed to generate through stupidity.

Stack underflows

an error message shown when CSB crashes. Caused if there is a variable missing from the stack when you enter a command.

Either you have simply forgot to put in a value (easy to do with long commands like &move) or some other function isn't providing the right information. I personally also get it because I usually increment using a '&1+' which requires one variable, and I always put '&+ instead, which adds two together to increment

Stack overflows

An error message shown before CSB crashes.

You need to be generating a large amount of values to the stack to do this, and usually is the sign of a recursive loop not breaking out of itself, that is hemoraging (however you spell it) values onto the stack each cycle. Or, in other words, usually you have two problems, to stop the loop, and then you will probably want to work out why you are leaving values on the stack instead of them being used up in the first place!

Game freezes

If the game simply freezes in place, this is the sign that a DSA is locked in an infinite loop.

This will be because you have missed out a '?' in a conditional jump so it always jumps, you are not reaching a target value to break out of the loop, or you simple have a jump command pointing to the wrong place.

Something happening all the time

Watch out for those pesky '?' in front of conditional jumps.

Also, watch out for simple literal checks like &< for 'less than'.

Something never happens

Again it could be the above, but also make sure you are actually checking the values or situations you think you are.

The syntax for &Param and any other check like &monster is reversed. Or, in other words you might think you are filling twelve memory arrays starting from 1' with party information, but in reality you are just assigning the first party variable to '12', and thus any checks you are making will be to garbage numbers. It is also hideously easy to forget to do '&@' when checking the value of an array - so you can be comparing a figure to '0' all the time, not comparing a figure to the contents of array '0'

Tips

I personally always like to keep a single line of code in each DSA (usually 0T3) free as a noop.

It makes it quick to know how to break out of the DSA or a gosub loop - just use JT3!

If you are doing complex code, it is a good idea while you are right in it and know exactly where logical breaks are to add the phrase 'L0 ?JT3' to the code. Currently it will do nothing, but it is very quick to then delete the '?' during debugging and create a break, and restore the ? to remove the break again.

You can, in a small way, comment your DSA code. CSBwin's error checking for parameters is quite good, and any parameter called it knows doens't exist will just be ignored and a zero generated instead. So if you insert the line 'lm lu lm lm ly ld le la lt lh' it will be allowed as viable code, and just generates a set of zeroes to the stack if it is actually acted upon. Whereas you can now remember that weird line of code was the one that killed mummies. Personally I use this kind of small comments in certain states (in unusaed lines) or at the end of a DSA function as reminders.

You can also create the DSA code 'offline', using a standard text editor like notepad, and then IMPORT it. This allows you to include as many comments as you like.

Written by Beowuuf