Gw Temp


Tutorial - 'Debugging Tips' by The Blob From Hell

An item about General posted on


The Blob From Hell gives some quick pointers on debugging your events in RM2K/2K3.


Tips on debugging.

I'm here to teach you about some very useful debugging tips that will probably save you from baldness. This is probably your first step toward not ever asking for help.
First I’d like to say that even if this tutorial was written for RM2k(3) it can still be applied in most parts to any other maker or programming language that you might be using. You just need to use your brain a little to adapt them.

First you need to know about the special keys that RM2k(3) uses in test mode.
F4- toggles between full screen and window mode
F5- toggles between big window and small window (must be in window mode)
F9- Switch/Variable menu (only available in test play)
F12- Returns to titles screen (only available in test play)
Ctrl- Walk through everything and ignores on hero touch events (also avoids the default random encounter system)
Shift- Instant text (only available in test play)

This is normally the most direct ways to your problem. For example if you’re wondering why your event isn’t doing anything. Press F9 when it should and you’ll probably realize that the switch isn’t ON. Quick trip to the event that was supposed to triggering it and you’re done!

Hopefully that will be the worst of it. But as we all no, it won’t always be limited to that. Your brain is quite smart when it comes to screwing up your code. So here are some techniques that will help you localize the error:

1. Make sure that you’re using your commands correctly. This can be fixed with a quick tour to the help file.

2. Another way of knowing if your event is starting and is not totally being overlooked, you can stuff a simple show message at the very beginning of the event. If the message pops up then the event is being triggered correctly, if not then I suggest checking your starting condition among other thing. This trick can also be used after forks or things like that to verify if portions of the code are being read correctly.
For other makers, simply writing a message or drawing a special something on screen can act as an indication.

3. F9 can be quite useful to see what happens to your variable and switches. You can easily check if they were properly set or what weirdness happened to them. It will help you understand some problems when doing big custom stuff like a CBS.
Another way to check multiple variables at any given time is to simply put an empty message which will act like a breakpoint in your code. When the message pops up, simply press F9 and check the status of all your variables.
If you’re using other makers you can use the same trick by simply outputting your variables on the screen or using some wait command to act as your break point.

5. Deleting portions of coding can be useful sometime to help you localize the problem. If you’re too scared of deleting a piece of code then you can use message box to separate portions of code. To use the message effectively you put one at the beginning of the coding you want to check and one at the end. This can help you pinpoint the area where some error message might come up or other bad things

4. If absolutely nothing is working and you've checked every single parcel of coding about a billion time, then the answer resides in the most stupid and little thing. It might sound a bit too simple, but I've got enough experience to say it's true and will be true on whatever platform you decide to use. But the previous tip might help you in locating exactly that little bugger.

Well there we go. Now you should be able to easily find the most common errors that you might get while you’re coding those systems of yours. Good luck and I hope you still have hairs ;)