Problem description: Hey I was wondering if there was any better advice on how to test for bugs. When there is an error, in compiler or ingame, I look over the code and if I can't find anything I either gray out some code to find the problem that is causing the error or put a world << "test 1" somewhere and in another code world << "test 2" etc... to see if the error happens before or after the test codes come up. What else would be a better idea to debug? Also I need to test out some gaming techniques and if characters in the game are doing what I programmed them to do so I think I will now create a special room for testing the character's moves. What else can I do?
| |
I didn't haha, my university teaches it as a fundamental language in the first year so i responded in a way how i would to someone that needs help on java. But on the main topic, debugging is done by outputs i'm afraid the rest is basically down to you :)
| |
How to run the debugger to go line by line?
| |
that's down to your own knowledge, meaning where you think the problem lies. If some code isn't running, for example you have increased stats but the aura icon doesn't appear then you would put the output near the icon summoning code and keep tinkering until you find the correct place. In the end of the day, debugging is down to how well you know the concept of programming.
| |
So byond does not have a debugger like Visual studio were you can step through each line?
| |
Unfortunately, no. The only thing we really have for debugging are the profiler and informative runtime errors.
| |
Sometimes that step debugger would be very helpful as I just spent 30 minutes looking in the wrong place for a runtime error that was actually somewhere else.
| |
It outputs proc name where the error has happened. Unless you have hundreds of lines of code in single procedures run-time error reports are good enough.
| |
If you enable debug mode in Build Preferences, the runtime error will include the name of the code file and the line number of the error.
| |
But the that is not always where the actual error originated at. Meaning I if the 2nd level proc has the error, but it does not trigger until you are 10 procs in, you have to hunt through 8 levels of procs to find it.
| |
Right, but the error itself should narrow down the search a lot. I've never seen a runtime error that I couldn't easily solve. Run-time errors are the best errors.
| |
Hey, can someone tell me exactly what DEBUG mode does in Dream Maker? I still don't get it.
| |
http://www.byond.com/docs/ref/info.html#/DM/preprocessor/ define/DEBUG
If a runtime error occurs, having DEBUG defined makes sure the DMB has enough information to also include the line number and file where the error occurred. For example, an error without DEBUG defined: runtime error: Cannot modify null.name. proc name: TriggerError (/mob/verb/TriggerError) usr: Guest-2394530474 (/mob) src: Guest-2394530474 (/mob) call stack: Guest-2394530474 (/mob): TriggerError() An error with DEBUG defined: runtime error: Cannot modify null.name. proc name: TriggerError (/mob/verb/TriggerError) source file: Error.dm,3 usr: Guest-2394530474 (/mob) src: Guest-2394530474 (/mob) call stack: Guest-2394530474 (/mob): TriggerError() It also enables use of the profiler. | |
Yeah I just tried using the DEBUG feature. It showed me the source of the error exactly! Very good.
| |
Basically the only way to debug is use the languages output function. The rest is up to you to figure it out. As you get better at programming, debugging becomes slightly easier.