SRL Archive - SRL Archives

SRL should be made debug-able by using compiler directives.

(compiler directives are those that are like {$DEFINE DebugThisMethod}, {$IFDEF DebugThisMethod}, {$ENDIF}, etc)

when a new SRL method is made, all the coder will have to do is (instead of commenting out the debug, as is so often done), add the compiler directives around the debug code (and as a standard, for debugging an entire method a directive name should be "Debug" followed directly by the full name of the method, I.E. "DebugFindSymbol"); I.E.:

procedure ThisIsATestProcedure(var X, Y: Integer);
begin
  {$IFDEF DebugThisIsATestProcedure}
    Writeln('X is ' + IntToStr(X) + ', and Y is ' + IntToStr(Y));
  {$ENDIF}
end;

If the coder would like to have multiple sections that are debug-able, you can do something like:

procedure ThisIsATestProcedure(var X, Y: Integer);
begin
  {$IFDEF DebugThisIsATestProcedure}
    {$DEFINE DebugThisIsATestProcedurePart1}
    {$DEFINE DebugThisIsATestProcedurePart2}
  {$ENDIF}
  {$IFDEF DebugThisIsATestProcedurePart1}
    Writeln('X is ' + IntToStr(X));
  {$ENDIF}
  {$IFDEF DebugThisIsATestProcedurePart2}
    Writeln('Y is ' + IntToStr(Y));
  {$ENDIF}
end;

Now, if the user only wants to debug half the procedure, all they have to do is call {$DEFINE DebugThisIsATestProcedurePart1}, and you don't get the debug from the other half

Now, for use in SRL, you would have to make an area for setting up the directives, this doesn't need to be done inside a procedure:

{$IFDEF DebugSRL}
  {$DEFINE DebugRadialWalk}
  {$DEFINE DebugRadialWalkEx}
  {$DEFINE DebugWhateverOtherProcedure}
  //etc...
{$ENDIF}

and the user must define the CD on their own:

program CDTest;

{$DEFINE DebugSRL}

{.include SRL\SRL.scar}

begin
  SetupSRL;
end.

Now, ofcource, you probably don't want to debug ALL of SRL, so why not just debug that you think is broken? (I.E. when RS updates and you can't figure out why the mouse if hovering over the "Log in" button…

program CDTest;

{$DEFINE DebugLoginPlayer}

{.include SRL\SRL.scar}

begin
  SetupSRL;
  DeclarePlayers;
  LoginPlayer;
end.

These things would mostly be used for the advanced users to see what goes on with when they call a procedure (without trying to decypher the coding style of other scripters), and the devs that want to see why some procedures aren't working properly.
The major benifeit of having this is that when using compiler directives, you don't have to have them defined beforehand, like booleans


Well, rate/hate plox :)

I still dont understand what {$Define } does.

pretty, useful, but in my opinion not useful enought.

when rs updates we usually detect the changes if they are big. if they are small we just notice something is broken. when we know that just something is broken we don't know what it is and so go debugging what we think it might be by ourselves.

writting "writeln('error no here - GameTab')" in the gametab function, would probably take us only a few seconds more than finding the right debug with

  { $Define SRLCoreFunctionsGameTab }

so the real use in that would be debugging the whole of srl. and for that there is a much easier way

const DebugSRL = True;

procedure SRLDebug(s: string);
begin
  if not DebugSRL then exit
  else writeln(s);
end;

and then just call SRLDebug

~RM

I had the idea of procedural pointers…

Something like:

var
  SRL_Debug(S1, S2 : string) : procedure;

Then, you can do things like

  SRL_Debug := Debug(S1, S2);

I think… I may be wrong in this being possible, but yeah! A procedural pointer might be better than all those defs which would hog up SRL's lines.

Seems like it would be just as hard to do the defines as to comment out parts of procedures.

Maybe a srl_Proc for debugging? Although, that's pretty much what Nava said.

Defines would be better than procedure's IMO. Although I'm not sure what to debug about functions like MMouse..

From: mastaraymond
Defines would be better than procedure's IMO. Although I'm not sure what to debug about functions like MMouse..

For MMouse it'd be like 'Moving to Coords [x, y]'. TPAs would be more like it. Things like FindObj and FindObjTPA. I think those are the big ones..

Has the potential to be very helpful, especially seeing as how SCAR doesn't have a runtime debugger beyond variable watches.

Definitely use defines, a procedure would slow things down. Also, defines could be stripped from the files with relative ease if one so desired.

Anyone mind explaining why defines are better?

If the debug wasn't turned on, the code inside the defines wouldn't be compiled.

From: Smartzkid
If the debug wasn't turned on, the code inside the defines wouldn't be compiled.

Not so sure about how those defines get handled in scar… They might get interpreted every time, no?