How to identify a bug/bad script when console doesn't print

#1 Are you using an IDE like torsion?... with that, you can get a log fo whats goin on right from teh very begginin of execution of TGB, so that you can track when did the error happened, and so take measures according to what the problem is.

also, doing so, will save you countless hours of debbugin code... but make sure to place debbugin lines (like echoes and warns) into functions, so that you know whats goin on and where.

#2 Everything can be debugged with echo statements! Well, maybe not everything, but certainly a lot of things. But you have to put them in the right spots

A quick way of seeing everything is to use the trace command. At the console or in your code, type trace(true);. It's not all the info you need but it will show you which method your code got to before it crashed. It won't show you where in a method it crashed, but since methods should never be more than a few lines long, that shouldn't be an issue

So that will tell you the last thing that worked before you blew up. What it won't tell you is if your code is blowing up because of some parameter value. But once you find the method that's blowing up, you can add echos to examine the value of every parameter (especially good for seeing if you're going into an if statement; also, in my experience, it helps you catch your own spelling errors)

You can also use debuggers. i believe Torsion has one. CodeWeaver (which i prefer) has one but i don't think it works with TGB 1.5. i've used many, many debuggers in my life and honestly, if you do it right, there's not much better than a simple echo statement. Unless you're writing in C and fighting linker errors and invalid memory exceptions and racing conditions, at which point your best debugging option is a witch doctor and holy water

#3

Quote:if you do it right, there's not much better than a simple echo statement

Totally agree. Echo() and Error() are your best friends.

#4 Baylor,

That reminds me of a signature I saw on a forum. I can't remember it exactly but it was something like, If debugging your application after the fact is twice as difficult as writing it correctly the first time through, assuming you did the best you could to the best of your ability to write it, by definition you aren't capable of debugging it.

Of course the original was better. I'll see if I can drag it up.

----
update
----
Found it.

Quote:Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- ::41554D::

#5 Thanks: echo is my best friend :)

#6 Echo, warn ad error are my best friends... if i know how and when to use them.

#7 Good point. Knowing when to use it is a skill in itself. Like riding a bike - it's not hard once you've done it a couple hundred times but it sure seems tricky the first time you try

echo is used to answer a question, so the important part is to have a good question. For example, suppose your collision method calls a method which calls another which eventually causes an explosion and the explosion isn't working. There are lots of potential reasons. The first question in TGB to ask: is my code broken or is it not being called? To answer that, stick an echo as the first line of the onCollision event:
echo("Player::onCollision");
If you see the line (the method name) in the console, you know your collision code is being called so there must be something wrong with your code so time to look at your code. If it's not there, your collision code isn't working and you should look in the level editor. If it's the code, put echoes at the top of each method and see if your explosion method is being called. If it isn't, you'll see how far you get and know where things are failing

It's also valuable to put echoes in front of IF statements to verify that the value is valid. That's a common way to find that you misspelled a variable name (very common) or are passing in a bad parameter (also common, especially when someone forgets to make %this be the first parameter)

Another thing i do is give most of my classes a toString method that prints the object's name. Sometimes i use a global toString for objects i didn't write a specific method for. An example:

function toString(%object)
{
    echo("id=" @ %object @ " class=[" @ %object.class @ "] name=[" @ %object.getName() @ "]");
}

It makes it easier to write code such as

function SomeObject::takeDamageFrom(%this, %attacker, %attackType, %damageDone)
{
    echo("SomeObject::takeDamageFrom(" @ 
             toString(%this)     @ ", " @ 
             toString(%attacker) @ ", " @ 
             %attackType        @ ", " @ 
             %damageDone
            );
    ...stuff...
}

The above line shows both which method is called and what the parameters are. It helps figure out whether the method is being called and whether the right parameters are being passed

Normally, i don't have the echoes in my code, although on larger projects i might do something like
if $debugging echo("whatever");
If i have a problem, i add simple echoes to see which function is the one with the error. If i see my echoes being called but i can't figure out the error, i add the more detailed echoes that show the parameter values. If i still don't see it, i add echoes after each line echoing the values that the next line will use. It can get pretty detailed:

%potentialTargets = %this.getPotentialTargets();
    echo("isObject(%potentialTargets) = " @ isObject(%potentialTargets));
    echo("%potentialTargets.getCount() = " @ %potentialTargets.getCount());

The key to using echo (warn, error, etc.) is to know what kind of question you're trying to answer and outputting just the information you need to answer that question. My problem with commercial profilers and tracers is that they give you information that is not detailed enough for the areas you care about and too much for the areas you don't. They don't lend themselves well to isolating problems. Which is why, no matter what nifty technologies people come up with, there will always be a place for echoes

#8 Hey, this is kind of related to this topic. when i am using the TGB at my uni, i am able to laod up the error console window, to see any errors going on etc, using a keybind. but at home, i am not able to do this, i am told to press ~ but it does not work. could someone guide me as to why, or how to change this?

#9 Do you have different versions? It was ~ in 1.3 and before but ctrl-~ in 1.5. Maybe you have a newer version than your school?

#10 My uni and myself have both got 1.7.2 now. my laptop does not have just a ~ button, its got the # symbol below it

#11 What type of keyboard are you using? For example, on American keyboards the symbol to the left of the 1 key is ~. On a German keyboard, it is ^. So when you are told to press ctrl ~ to call up the console, it's should be press ctrl plus whatever symbol is to the left of the 1 key.

#12 Next to my one key i have got the button with '

#13 Seems to of cut of my last post. the key i have got is the

#14 Ok thast werid, has done it again! well i have tried all combos i can think of, but none work, i really could do with this working though, any devs here that could help?

#15 I had the same issue and it turned out to be a problem with my keyboard drivers. All I had to do was change them and it worked fine.

#16 Ok cheers mate, i decided to have a look at the .cs files, and changed a keybinding for it, it works now, but still i would like to try and get it working normally.