What is If Debug?

[Runehack123]

Greetings,

I don't understand at all what

If Debug

means.

I've seen this in scripts, but have no idea how to use it effectively and how to work with it.

None of the TuTs I looked through seemed to mention it, but maybe I missed something.

Any explanation on how to use it would be greatly appreciated.

[YoHoJo]

Umm expansible please?

Normally if you enable debug in a script, it draws on the SMART window or leaves a lot of messages in the debug window of Simba lettings you know what is script is up do/doing/thinking.

It's mostly just for scripters to see what's going on with the script, and kind of fun for regular people to see.

[Runehack123]

Examples where I saw this:
Ashaman's Pinecutter
Cohen's Draynor Willows

I'm sure there's more.

Usually somewhere in the form of:

If Debug...Do

If Debug...Result:=True

But how do I use it and what does If Debug mean? is what I'm trying to ask here.

[P1ng]

You could set a boolean constant at the beginning of your script called "Debug"

like so:

const
  Debug = True;

Then throughout the script like in the instance where you would be doing a WriteLn debug saying that your script has made it to the fishing spots it could look like this:

Walk2FishingSpot;
if Debug then
  WriteLn('Player has reached fishing spots');
LocateFish;

To elaborate - a boolean is a bit of memory that stores either true/false. When stored as a constant it cannot change throughout the script (unlike a variable). Basically this allows your user to decide before running the script if they would like to see all the scripts workings.
In my more recent scripts I have developed a procedure which is this:

procedure PDebug(S: String);
begin
  {$IFDEF DEBUG}
    WriteLn(S);
  {$ENDIF}
end;

What this procedure does is if the user un-comments the

{$DEFINE DEBUG}

at the top of the script, they will be able to see in writing what the script is doing at any particular time because I have lines such as:

if not SPS_WalkPath(myPath) then
      PDebug('Walk2Altar failed');

So there you can see that if the script did not successfully walk to the altar if the user chooses to view the debug the message 'Walk2Altar failed' would appear and they would know why the script failed.

[Runehack123]

You could set a boolean constant at the beginning of your script called "Debug"

like so:

const
  Debug = True;

Then throughout the script like in the instance where you would be doing a WriteLn debug saying that your script has made it to the fishing spots it could look like this:

Walk2FishingSpot;
if Debug then
  WriteLn('Player has reached fishing spots');
LocateFish;

That's how I saw it in the scripts except debug was set to false at the start.
Does that mean your example is the same as...

Walk2FishingSpot;
if True then
  WriteLn('Player has reached fishing spots');
LocateFish;

...without setting the constant at the start. Then why do I have to call True/False something else like Debug? It just doesn't make any sense to me.

[P1ng]

Yes that is correct.
But your script does not know what true is if it has no name...

This is why at the beginning we declare a boolean with a name and from there a particular value can be given to it (true/false).

If you have it your way a user would need to go to every single line that has WriteLn and change them to false, this way they change one true to a false and then the debug is turned off.

[Runehack123]

If you have it your way a user would need to go to every single line that has WriteLn and change them to false, this way they change one true to a false and then the debug is turned off.

So..how does the debug come into all of this? What does it mean? I don't understand at all what you just wrote with the true to a false and changing to false etc...

[P1ng]

Debug is a process that those who write scripts use to remove errors from there scripts.

To do this they use "WriteLn" alot so that they can read in real-time where the script is up to and what it is doing.

People using this script may/may not want to read all of this stuff, they may just want to run it.

Hence, sometimes the writer will add a constant called "Debug" which allows users of this script to have/not have all of this written.

[Runehack123]

Ok thanks rep++

I don't know how to use it, but at least I know what it does.
Sounds like a really confusing process to me.

[Ashaman88]

It's just to let you know where a script is screwing up. In mine for example anytime you do something it prints it. Like if it finds the dtm it will say so, and same if it finds the uptext. So I can run it with debug mode on and see that it's not my dtm that is messed up but rather uptext, so I don't have to waste time trying to figure out what went wrong. I turn off debug mode for users bc there is really no need for them to see it spamming all those debug lines

[Runehack123]

Thanks Ashaman for the reply!
If you could make a guide on it that would be AMAZING!!!

Your arctic pine script (haven't tested it since I don't play) just looks so technical and all that it would be a shame to not have some of your genius explained to newbies like myself!

Just saying haha...

[BraK]

BraK's Explaination

So we have a script we made. let's say something like this:

program WalktoThere;

Begin
  WhereAreWe;
  
  If Location = Destination then
    exit;

  Walk1;

  Walk2;

  Walk3;

  WhereAreWe;

  If Location = Destination then
  begin
    result := true;
    Exit;
  end;
  
  SayWeAreLost;
  TerminateScript;
end.

Now let's say a bunch of users are saying that the script just stop randomly when walking. How would you know where the script got lost? For this we use Debugs. In each step of the script you add a debug saying what it is doing on not doing.

program WalktoThere;

Begin
  WhereAreWe;
  DebugLn('Current Location := ' + Location);
  if Location = Destination then
  begin
    DebugLn('We are at the Destination exiting WalkToThere procedure.');
    result := true;
    exit;
  end;
 
  DebugLn('Doing Walk1 Procedure.');
  Walk1;

  DebugLn('Doing Walk2 Procedure.');
  Walk2;

  DebugLn('Doing Walk3 Procedure.');
  Walk3;

  WhereAreWe;
  DebugLn('Current Location := ' + Location);

  If Location = Destination then
  begin
    DebugLn('We are at the Destination exiting WalkToThere procedure.');
    result := true;
    Exit;
  end;
  
  DebugLn('We Are Lost Terminating Script');  TerminateScript;
end.

As seen above I added in a few Debugs. These debugs will let us know at what point the script stop working and what it was doing. So instead of the scripter having to recreate the error or guess at where the problem is in the script we already have an exact location of the Error. Why is this important? It saves tons of time when fixing broken Scripts. Instead of reworking a whole series of events we can just work on the broken portion of it.

Hopefully you can understand the Examples I gave. None of the Examples are actual working code they are ment to be just that examples.

[Runehack123]

THANKS A TON!!!
Yes, I understand the example. Really nice straight-forward - thanks so much!

[masterBB]

The big pro of using

{$IFDEF DEBUG}
WriteLn(S);
{$ENDIF}

instead of

if Debug then
Writeln(S);

is that the first will be read before the scripts starts. If DEBUG is not defined, it will simply remove that part out of your script. This can come in handy in a lot of situations and you can for example reduce the amount of variables because you won't need that debug bitmap if you are not going to use it. Also the amount of functions will be lower, and the script might be faster.

[Runehack123]

The big pro of using

{$IFDEF DEBUG}
WriteLn(S);
{$ENDIF}

instead of

if Debug then
Writeln(S);

is that the first will be read before the scripts starts. If DEBUG is not defined, it will simply remove that part out of your script. This can come in handy in a lot of situations and you can for example reduce the amount of variables because you won't need that debug bitmap if you are not going to use it. Also the amount of functions will be lower, and the script might be faster.

Thank you! I don't quite understand this at my level and all, but bookmarked this thread so I can get back to it after I looked into it more !