SRL Archive - MSI Suggestions

I'm tired, so this will be a quick post.

MSI has several levels of debugging, due to the debug consts.

The reason for this was to people not to have to read through millions of text, just to find out when their player went to false or something like that.

But for anyone developing the script, it is much better if the user has everything debugged, so it can easily be narrowed down.

Well, two ideas:

• Structure the debug
Meaning something like this: [php] - RMagician logged in - - Script: VEM - - Setting up Player - - - - Detecting location - - - - - - In ConfirmLoc - - - - - - Found Symbol: bank - - - - - - Result: true - - - - - - Out ConfirmLoc //… - - Mining //… - RMagician Logged Out [/php] Makes is much easier to read.
• Also, we can just debug some things, but save the whole log (not sure if we do this already?)

~RM

Yeah, I like the idea. Would definitely make it more readable, and it debugs more. Right now I think our debugging is really crowded and hard to read. I wouldn't mind a complete rewrite of the debugging to be honest. Just to make it more clear and understandable. I like your "nesting" type deal because it doesn't repeat the players name on every line. I don't know if you can change the debug colours/font styles in Simba, but it'd be neat to have different styles to make certain parts stand out.

I still think we should have the procedure name and time in there somehow though, but that would probably mess up the aligning (the procedure name part of it anyway).

E: Oh, and I think the object finding debugging needs to be a little better. Everytime I've done any debugging 99.9% is from object finding. It just seems to spam the debug box. =\

I really like that first idea actually.

I'm definitely in support of that. I may actually do it to my own scripts now :spongebob:

[php]
(xx:yy) - RMagician logged in
(xx:yy) - - Script: VEM
(xx:yy) - - Setting up Player
(xx:yy) - - - - Detecting location
(xx:yy) - - - - - - In ConfirmLoc
(xx:yy) - - - - - - Found Symbol: bank
(xx:yy) - - - - - - Result: true
(xx:yy) - - - - - - Out ConfirmLoc
//…
(xx:yy) - - Mining
//…
(xx:yy) - RMagician Logged Out
[/php]

Should we bother with seconds? Only for speed purposes, imo, and I still don't find it that necessary..

~RM

From: Rasta Magician
[php]
(xx:yy) - RMagician logged in
(xx:yy) - - Script: VEM
(xx:yy) - - Setting up Player
(xx:yy) - - - - Detecting location
(xx:yy) - - - - - - In ConfirmLoc
(xx:yy) - - - - - - Found Symbol: bank
(xx:yy) - - - - - - Result: true
(xx:yy) - - - - - - Out ConfirmLoc
//…
(xx:yy) - - Mining
//…
(xx:yy) - RMagician Logged Out
[/php]

Should we bother with seconds? Only for speed purposes, imo, and I still don't find it that necessary..

~RM

I see no real reason for it. That looks good right there.

From: Rasta Magician
Should we bother with seconds? Only for speed purposes, imo, and I still don't find it that necessary..

May not even need time at all, unless for some reason we want to look at the speeds of all the functions, and I'm more worried about them working than speed. Unless it take 5 min to bank, then we'd have a problem.

To keep the proper alignment, we could include the procedure name at the end of the line in brackets or something?

Well, with time in there you see if some procedure takes too long to complete, like the banking as you said, if that for some reason takes the 5-10 minutes, you see from the logs, to ease the notification of those, you could make a difference to the last log mark?

I think we should keep the time stamps. Just how RM posted above would work just fine and looks nice.

From: Coh3n

To keep the proper alignment, we could include the procedure name at the end of the line in brackets or something?

I don't think we need the procedure name, (not anymore :p)

[php]
(xx:yy) - RMagician logged in
(xx:yy) - - Script: VEM
(xx:yy) - - Setting up Player
(xx:yy) - - - - Detecting location
(xx:yy) - - - - - - In ConfirmLoc //this shows you where a proc starts
(xx:yy) - - - - - - - - Found Symbol: bank
(xx:yy) - - - - - - - - Result: true
(xx:yy) - - - - - - Out ConfirmLoc //and where it stops
//…
(xx:yy) - - Mining
//…
(xx:yy) - RMagician Logged Out
[/php]

~RM

As long as it is clear where the error occurred, I'm fine with whatever. :)

From: Coh3n
As long as it is clear where the error occurred, I'm fine with whatever. :)

I started wipping it up, will post later.

~RM

I've been mulling this in my mind.

Here is what I came to
[php]
- - Player Status
- - - - Player Action
- - - - - - Script Status
- - - - - - - - Script Action
- - - - - - - - - - Function Status
- - - - - - - - - - - - Function Action
- - - - - - - - - - Function Status
- - - - - - - - - - - - Function Action
- - - - - - - - - - Function Status
- - - - - - Script Status
- - Player Status
[/php]

[php]
DEBUG_PLAYER_STATUS = 1;
DEBUG_PLAYER_ACTION = 2;
DEBUG_SCRIPT_STATUS = 3;
DEBUG_SCRIPT_ACTION = 4;
DEBUG_FUNC_STATUS = 5;
DEBUG_FUNC_ACTION = 6;
[/php]

For the amount of - it's just const*2

What does everyone think? :)

~RM

I love it. So much more organized. :)

Wrote a tiny bit of code. Result looks good imo.

Compiled succesfully in 1770 ms.
(xx:yy) : [ RM ] —— MSI_Setup: Loading Objects
(xx:yy) : [ RM ] ——– MSI_Setup: impossible to load Object 5
Successfully executed.

{.include SRL/SRL/MSI/Setup.scar}

const
  DEBUG_PLAYER_ACTION = 1;
  DEBUG_PLAYER_STATUS = 2;
  DEBUG_SCRIPT_ACTION = 3;
  DEBUG_SCRIPT_STATUS = 4;
  DEBUG_FUNC_ACTION   = 5;
  DEBUG_FUNC_STATUS   = 6;

{******************************************************************************}
{ procedure MSI_Debug(ProcName, TheMessage: string; DebugLevel:integer);       }
{ By: Rasta Magician                                                           }
{ Date: 10 June 2010                                                           }
{ Description: Used for Debugging. Will debug to DebugBox if                   }
{              DebugLevel >= Debug_LevelToDebug                                }
{******************************************************************************}
procedure MSI_Debug2(ProcName, TheMessage: string; DebugLevel: integer);
var
  DebugMSG, path, str: string;
  theFile: Integer;
begin
  DebugMSG := '('+'xx:yy'+') : ';

  try
    DebugMSG := DebugMSG + '[ ' + Capitalize(Players[CurrentPlayer].Nick)+' ] ';
  except end;

  DebugMSG := DebugMSG + Replicate('-', DebugLevel * 2) + ' ';

  DebugMSG := DebugMSG + ProcName + ': ';
  DebugMSG := DebugMSG + TheMessage;
  writeln(DebugMSG);
{
  //Save the message to a file
  if (saveDebug) then
    try
      path := AppPath + 'Includes\SRL\SRL\msi\MSI Logs\';
      if FileExists(path + scriptStart + '.txt') then
      begin
        theFile := OpenFile(path + scriptStart + '.txt', False);
        ReadFileString(theFile, str, FileSize(theFile));
        CloseFile(theFile);
      end;

      theFile := RewriteFile(path + scriptStart + '.txt', False);

      WriteFileString(theFile, str + #10 + DebugMSG);
      CloseFile(theFile);
    except
      Writeln('Debug saving - error occurred');
    end;
}
end;

begin
  SetLength(Players, 1);
  Players[CurrentPlayer].Nick := 'RM';
  MSI_DEBUG2('MSI_Setup', 'Loading Objects', DEBUG_SCRIPT_ACTION);
  MSI_Debug2('MSI_Setup', 'impossible to load Object 5', DEBUG_SCRIPT_STATUS);
end.

I'll be applying it around the include.

E: Just to let you know that I'm debug Crazy. I usually don't even have to watch my script, I just read the debug box, so.. there'll be an awful lot of debug.

One small problem: the only way I can see such an organized debug is by having A LOT being debugged. But I guess I can do that, and since we have a LevelToDebug const we can just set it to higher, so not everyone is flooded by debug.

~RM

Ehh, I may have removed LevelToDebug because we weren't using it. :o

From: Coh3n
Ehh, I may have removed LevelToDebug because we weren't using it. :o

I can just add it again ;)

~RM

From: Rasta Magician
I can just add it again ;)

~RM

Yeah. I was just letting you know in case for some odd reason you went crazy trying to find it. Lol :p

What if certain levels of debug were colored? such as, forced debugs could be red text(just an example). It might be a bit complicated, but it cant be that bad. Dunno if it would be useful/necessary, but idk… just my two cents.

I dont see how showing everything that happens is helpful. Then you're left with all this extra unneeded data that just shows where things went right. When as long as something isn't going wrong, then it's obviously going right. So to me, it would make more sense to just output as much info as possible such as mayhaps dumping all the variable values or something and where the error happens. Then you should get a lot of potentially useful information and very little of the useless sort.

From: Dan Cardin
I dont see how showing everything that happens is helpful. Then you're left with all this extra unneeded data that just shows where things went right. When as long as something isn't going wrong, then it's obviously going right. So to me, it would make more sense to just output as much info as possible such as mayhaps dumping all the variable values or something and where the error happens. Then you should get a lot of potentially useful information and very little of the useless sort.

That's not a bad idea, but personally, I like to know what my scripts are doing at all times so I can make sure everything is in order.

Dan, couldn't that be up to the scripter by the different levels? DEBUG_LEVEL_BUGS, DEBUG_LEVEL_ALL, etc.?

By the way, I wrote something like this already, check around in the SRL5 section.

Didn't realise this thread was here.

From: Nava2
By the way, I wrote something like this already, check around in the SRL5 section.

Didn't realise this thread was here.

Mind posting some of that for us to look at? :redface:

From: Nava2
Okay, I've made a project.

:)

program New;

const
  srl_dbg_DefaultInterval = 100;
  srl_dbg_SkDefaultInterval = 1000;
  srl_dbg_SkSprtr = '^';

type
  TSkeleRecord = record
    startTime, endTime: Integer;
    name, misc: String;
  end;

var
  dbg_Level: Integer;
  dbg_ProcList: TStringArray;
  dbg_c, dbg_Length: Integer;
  
  dbg_Skele: Boolean;
  dbg_SkI: array of TSkeleRecord;
  dbg_SkPC: TIntegerArray;
  dbg_SkC, dbg_SkCurrProc, dbg_SkL: Integer;

procedure dbg_SetRecords(l: Integer);
begin
  SetLength(dbg_ProcList, l);
  dbg_Length := l;
end;

procedure dbg_Setup;
begin
  dbg_SetRecords(srl_dbg_DefaultInterval);
end;

procedure dbg_SkSetLengths(l: Integer);
begin
  SetLength(dbg_SkI, l);
  SetLength(dbg_SkPC, l);
  dbg_SkL := l;
end;
  
procedure dbg_SetP(n: String);
begin
  if (dbg_c = dbg_Length) then
    dbg_SetRecords(dbg_Length + srl_dbg_DefaultInterval);

  dbg_ProcList[dbg_c] := n;
  Inc(dbg_c);
  
  // Record the information for Skeleton Debugging
  if dbg_Skele then
  begin
    if dbg_SkC = dbg_SkL then
      dbg_SkSetLengths(dbg_SkL + srl_dbg_SkDefaultInterval);
    dbg_SkI[dbg_SkC].name := n;
    dbg_SkI[dbg_SkC].startTime := GetTimeRunning;
    dbg_SkPC[dbg_SkCurrProc] := dbg_SkC;
    Inc(dbg_SkC);
    Inc(dbg_SkCurrProc);
  end;
  
  // Start Procedure Debug Info
  {case dbg_Level of
    //Insert Constants here!
  end; }
end;

procedure dbg_KillP;
begin
  dbg_ProcList[dbg_c] := '';
  Dec(dbg_c);
  
  if dbg_Skele then
  begin
    dbg_SkI[dbg_SkPC[dbg_SkCurrProc]].endTime := GetTimeRunning;
    Dec(dbg_SkCurrProc);
  end;
  
  // End Procedure Debug Info
  {case dbg_Level of
    //Insert Constants here!
  end; }
end;

procedure dbg_Out(s: String);
begin
  // Output s based on a format by the Level
 {case dbg_Level of
    //Insert Constants here!
  end;}

  if dbg_Skele then
    with dbg_SkI[dbg_SkPC[dbg_SkCurrProc]] do
      misc := misc + srl_dbg_SkSprtr + s;
end;

const
  srl_dbg_Sk_GapChar   = ' ';
  srl_dbg_Sk_StartChar = '>>';
  srl_dbg_Sk_EndChar   = '<<';
  srl_dbg_Sk_MiscChar  = '==';
  srl_dbg_Sk_MiscSprtr = ';';

  srl_dbg_Sk_OutType_Full = 0;

var
  srl_dbg_Sk_OutType: Integer;

procedure dbg_Sk_SetResult(SetFrom: String; var setTo: TStringArray; var c: Integer; IndCount: Integer);
begin
  setTo[c] := Replicate(srl_dbg_Sk_GapChar, IndCount * 2) + SetFrom;
  Inc(c);
end;

function dbg_Sk_Output: TStringArray;
var
  i, mark, APc, rCount, curInd: Integer;
  ActiveProcs: TIntegerArray;
  tTSA: TStringArray;
  AllDone: Boolean;
begin
  SetLength(Result, dbg_SkC * 3);
  SetLength(ActiveProcs, dbg_SkC);
  AllDone := False;
  APc := 0;
  rCount := 0;
  curInd := 0;
  
  case srl_dbg_Sk_OutType of
    srl_dbg_Sk_OutType_Full: dbg_Sk_SetResult(dbg_SkI[0].name + ' Called at: ' + IntToStr(dbg_SkI[0].startTime) + ' ms.', Result, rCount, 0);
  end;
  
  if dbg_SkI[0].misc <> '' then
  begin
    dbg_SkI[0].misc := Replace(dbg_SkI[0].misc, srl_dbg_SkSprtr, ' ' + srl_dbg_Sk_MiscSprtr);
    dbg_Sk_SetResult('==' + dbg_SkI[0].misc, Result, rCount, 1);
  end;
  
  Inc(i);
  while (APc > -1) do
  begin
    case srl_dbg_Sk_OutType of
      srl_dbg_Sk_OutType_Full:
        dbg_Sk_SetResult(srl_dbg_Sk_StartChar + dbg_SkI[i].name + ' Called at: ' + IntToStr(dbg_SkI[i].startTime) + ' ms.', Result, rCount, curInd);
    end;
    if dbg_SkI[i].misc <> '' then
    begin
      dbg_SkI[i].misc := Replace(dbg_SkI[i].misc, srl_dbg_SkSprtr, ' ' + srl_dbg_Sk_MiscChar);
      dbg_Sk_SetResult('==' + dbg_SkI[i].misc, Result, rCount, curInd + 1);
    end;

    if (dbg_SkI[i].endTime > dbg_SkI[i + 1].startTime) then
    begin
      Inc(APc);
      ActiveProcs[APc] := i;
      Inc(curInd);
      Inc(i);
    end else
    begin
      i := ActiveProcs[APc];
      Dec(APc);
      Dec(curInd);

      // Set the "End"
      case srl_dbg_Sk_OutType of
        srl_dbg_Sk_OutType_Full:
          dbg_Sk_SetResult(srl_dbg_Sk_EndChar + 'END (' + IntToStr(dbg_SkI[i].endTime - dbg_SkI[i].startTime) + ' ms)', Result, rCount, curInd);
      end;
    end;
    
  end;
end;


begin
  Writeln('hoi');
end.

So, the point of this system is to give the regular debugging, but also allows for a very useful way of viewing your scripts running in something I like to call a "Skeleton".

The last function (unfinished) will output the information gathered like:

>>FirstFunction Called at 0 ms.
  >>SecondFunction Called at 300 ms.
    >>ThirdFunction Called at 4983 ms.
    <<END (400 ms)
    >>FourthFunction Called at 5708 ms.
      == This happened.; Then this; and This also was recorded.;
    <<END (100 ms)
  <<END (900 ms)
<<END (9000 ms)

I know those values in the example aren't correct, just bear with me. I think a system like this would have MANY uses for scripters. Not to mention, it lets people see what is happening when etc.

What do you think? This is hurting my brain, so until I get a go for it I am halting the production. :)

Edit: Just so you know, if you read the code, it can be confusing, I will add more comments later etc.

Its basically a call stack.

(Sorry, NCDS. I forgot you all can't view those forums)

From: nickrules
What if certain levels of debug were colored? such as, forced debugs could be red text(just an example). It might be a bit complicated, but it cant be that bad. Dunno if it would be useful/necessary, but idk… just my two cents.

Not a bad idea, although I have no idea if Simba supports this.

From: Dan Cardin
I dont see how showing everything that happens is helpful. Then you're left with all this extra unneeded data that just shows where things went right. When as long as something isn't going wrong, then it's obviously going right. So to me, it would make more sense to just output as much info as possible such as mayhaps dumping all the variable values or something and where the error happens. Then you should get a lot of potentially useful information and very little of the useless sort.

What i luffs yeww said. The user will be able to decide how much information is debugged using the level system.

How about debugging everything to a logfile, with prefixes for detail levels on each line?

From: Boreas
How about debugging everything to a logfile, with prefixes for detail levels on each line?

We already have the option for the user to save the log. But it does need to be a lot more organized (which I'm assuming is the point of this thread), because right now it's just a mess. I think the '-' indicates the debug levels, but prefixes would work too (that's actually what I used in my draynor script).

From: Coh3n
We already have the option for the user to save the log. But it does need to be a lot more organized (which I'm assuming is the point of this thread), because right now it's just a mess. I think the '-' indicates the debug levels, but prefixes would work too (that's actually what I used in my draynor script).

Ah cool. I was thinking prefixes because it would be easy to make a script that reads the logfile and then displays only X (or everything except Y) leaving the very detailed logfile intact.

From: Boreas
Ah cool. I was thinking prefixes because it would be easy to make a script that reads the logfile and then displays only X (or everything except Y) leaving the very detailed logfile intact.

Yeah. It may be faster to save everything to the log file, then only writeln the the ones depending on the DebugLevel, that way you aren't writing then reading from a file. You're writing everything to the file, but only certain things to the debug.

Imo, this is a great idea, but sometimes i just wish msi wasn't clearing the debug all the time (because, in its current state, it does it alot), and, then i have to look through a log, and not everything is in there.

From: nickrules
Imo, this is a great idea, but sometimes i just wish msi wasn't clearing the debug all the time (because, in its current state, it does it alot), and, then i have to look through a log, and not everything is in there.

I also think we should have an option to not have the Proggie in the debug box. Personally I'd just have it on the file.

~RM

From: Rasta Magician
I also think we should have an option to not have the Proggie in the debug box. Personally I'd just have it on the file.

~RM

I like this idea.

Also for one of the levels, I believe it was mentioned a little while ago, that we have an option to only debug what is wrong with it, the purpose of debugging isn't to know what is right. In all of the scripts that I make there is usually only extensive debugging to say when something goes wrong. The other debugs are like "Finished Walking" so I can look through the script and know exactly where it was when it was doing whatever messed up, just in case another debug didn't catch it for any reason (ie script thought it was right but it clicked the wrong spot).

From: 3Garrett3
I like this idea.

Also for one of the levels, I believe it was mentioned a little while ago, that we have an option to only debug what is wrong with it, the purpose of debugging isn't to know what is right. In all of the scripts that I make there is usually only extensive debugging to say when something goes wrong. The other debugs are like "Finished Walking" so I can look through the script and know exactly where it was when it was doing whatever messed up, just in case another debug didn't catch it for any reason (ie script thought it was right but it clicked the wrong spot).

Personally I use Status and Disguise to keep the user updated on whats going on, then debug box for errors etc. I do think it's important though for the user to easily be able to understand what the script is exactly doing, whether it be right or wrong.

From: NCDS
Personally I use Status and Disguise to keep the user updated on whats going on, then debug box for errors etc. I do think it's important though for the user to easily be able to understand what the script is exactly doing, whether it be right or wrong.

Yeah, my main point got messed up in the post I think.

What I meant was that the helpful tool for actually debugging a script (finding and eliminating bugs) is to only say what is wrong, and I find it helpful if I know which major procedures are happening, so I know the area to look.

From: Rasta Magician
I also think we should have an option to not have the Proggie in the debug box. Personally I'd just have it on the file.

~RM

I agree.

From: NCDS
Personally I use Status and Disguise to keep the user updated on whats going on, then debug box for errors etc. I do think it's important though for the user to easily be able to understand what the script is exactly doing, whether it be right or wrong.

I like this also. I think we should have the status update regardless, then the debug shows whatever is set from the DebugLevel.

Simple but should be effective. Will post more on this later.

var
  CurrDebugLevel: integer;

procedure MSI_Debug(debug: string);
var
  DebugMSG: sring;
begin
  Status(debug);

  //time
  DebugMSG := '('+TheTime+') : ';

  //player name
  try
    DebugMSG := DebugMSG + '[ ' + Capitalize(Players[CurrentPlayer].Nick)+' ] ';
  except end;

  //structure
  DebugMSG := DebugMSG + Replicate('-', CurrDebugLevel * 2) + ' ';

  //debug message
  DebugMSG := DebugMSG + debug;

  //save to file
  try
    path := AppPath + 'Includes\SRL\SRL\msi\MSI Logs\';
    if FileExists(path + scriptStart + '.txt') then
    begin
      theFile := OpenFile(path + scriptStart + '.txt', False);
      ReadFileString(theFile, str, FileSize(theFile));
      CloseFile(theFile);
    end;

    theFile := RewriteFile(path + scriptStart + '.txt', False);

    WriteFileString(theFile, str + #10 + DebugMSG);
    CloseFile(theFile);
  except
    Writeln('Debug saving - error occurred');
  end;

  if CurrDebugLevel <= LEVEL_TO_DEBUG then
    writeln(DebugMSG)
  else
    Debugln(DebugMSG);

end;

//creates a new header, meaning all following debugs will go a level below this one
procedure MSI_DebugHeader(header: string);
begin
  MSI_Debug(header);
  inc(CurrDebugLevel);
end;

//Closes header, debugs result
procedure MSI_CloseHeader(result: string);
begin
  MSI_Debug(result);
  Dec(CurrDebugLevel);
end;

//allows for a one-time-only sub-debug
procedure MSI_SubDebug(debug: string);
begin
  Inc(CurrDebugLevel);
  MSI_Debug(debug);
  Dec(CurrDebugLevel);
end;

I realized later that it comes close to Nava's system, while being an awful lot simpler…


edit: in use:

function MSI_FindTool(): boolean;
//..
begin
  try MSI_DebugHeader('MSI_FindTool');

    MSI_Debug('Figuring out best tool');
    BestTool := GetBestTool(MyLevel);
    MSI_SubDebug(Objects[BestTool].Name);

    MSI_Debug('Looking for tool on player');
    FoundTab := FindToolOnTabs;
    MSI_SubDebug('Found in tab: ' + TabNames[FoundTab]);

    Result := FoundTab > 0;

  finally MSI_CloseHeader('MSI_FindTool: '+ BoolToStr(Result));
end;

expected result:

 - - MSI_FindTool
 - - - - Figuring out best tool
 - - - - - - Rune Axe
 - - - - Looking for tool
 - - - - - - Found in equip tab
 - - MSI_FindTool: true 

The beauty of this is that the levels will always come with the right structure, as with this system they will follow the script flow.
~RM

I love it. :) It will take a while to apply this method throughout the include, but it looks like it will be well worth it.

From: Coh3n
I love it. :) It will take a while to apply this method throughout the include, but it looks like it will be well worth it.

Done debug & banking.simba. Will keep on doing. This also gives me the chance to add debugs where one might have been missing :)

eg: it debug for true, but not for false.

~RM

From: Rasta Magician
Done debug & banking.simba. Will keep on doing. This also gives me the chance to add debugs where one might have been missing :)

eg: it debug for true, but not for false.

~RM

Shouldn't it do

-- MSI_FindTool: false

for false?

From: Coh3n
Shouldn't it do

-- MSI_FindTool: false

for false?

It does.. however for some functions, when it missed something, it wouldn't debug it.

~RM

From: Rasta Magician
It does.. however for some functions, when it missed something, it wouldn't debug it.

~RM

Oh cause it would exit. Maybe we add a debug where it would exit? Not sure if that's really needed or not, but it could be one of the debug levels.

From: Coh3n
Oh cause it would exit. Maybe we add a debug where it would exit? Not sure if that's really needed or not, but it could be one of the debug levels.

I've added try..finally, so it'll always debug ;)

~RM

From: Rasta Magician
I've added try..finally, so it'll always debug ;)

~RM

To every function? Wouldn't that slow everything down a lot?

From: Coh3n
To every function? Wouldn't that slow everything down a lot?

Committed. It wasn't added to every function, no :) It shouldn't affect speed in any noticeable way.

~RM

May I suggest something here?

We could print a coloured (?), (!) or (i) icon to indicate if it's something critical, a warning or just some debug info. That would help spotting the error somewhat. The icon could be drawn into a special MSI font, just to have those special icons. The rest of the text could ofcourse be in the normal font.

Something like this;

Thoughts?

From: CX gamer
May I suggest something here?

We could print a coloured (?), (!) or (i) icon to indicate if it's something critical, a warning or just some debug info. That would help spotting the error somewhat. The icon could be drawn into a special MSI font, just to have those special icons. The rest of the text could ofcourse be in the normal font.

Something like this;

Thoughts?

I love it. However, I don't know how customizable the debug box is in Simba.

@RM: Do a test run of one load or something, you'll find that it's not exactly what was intended. Also, for the time, why not use Simba's built in timestamp? Takes one line to add and it ensures that every line has the time on it. Also I'm pretty sure it's the script runtime (not sure if that's what ours is or not).

Shit, I should have checked that.

[Error] (4:33): Unknown type 'TDebugParams' at line 3

From: CX gamer
Shit, I should have checked that.

[Error] (4:33): Unknown type 'TDebugParams' at line 3

Uhm, what? That's not from MSI is it? Or are you experimenting when debug customization? If the latter, I'd suggest posting in the Simba forums and see if there's even such a feature.

No you were right, it does not recognise the variable used to customizing. Maybe in the future. ^_^

@Coh3n: I'm in china ATM, and can't really have a test run. Could you perhpas post an example of what it is debugging?

Also, having just re-read one of garrett's post about usefulness of debug..

we can easily change the character that it uses to show what it means. Or add a character as gamer suggested. (Just not colored)

(v) - ok
(e) - error (user)
(s) - script error
(f) - script fail

~RM

Yes, I think that would help debugging a bit. Shouldn't be very hard to implement. :P

From: Rasta Magician
@Coh3n: I'm in china ATM, and can't really have a test run. Could you perhpas post an example of what it is debugging?

Also, having just re-read one of garrett's post about usefulness of debug..

we can easily change the character that it uses to show what it means. Or add a character as gamer suggested. (Just not colored)

(v) - ok
(e) - error (user)
(s) - script error
(f) - script fail

~RM

China!? Jesus, where haven't you been? It's like every other week you're in a different country. I'm a little jealous. :rolleyes: When do you plan on coming to Canada? :D And yeah, I'll post what it does… probably would have been easier for me to do that in the first place….

E: Here's a small bit:
[PHP]
SRL Compiled in 15 msec
SMART Initialized.
Loaded: Server 152, Members: False, Signed: True, Super Detail: False.
Setting up MSI took 109 ms.
MSI_SetupPlayer
(10:05:41 AM) : [ ] MSI_SetupPlayer
MSI_BestTool
(10:05:45 AM) : [ ] – MSI_BestTool
CurrentSkill level: 88
(10:05:46 AM) : [ ] —- CurrentSkill level: 88
MSI_BestTool: 25
(10:05:46 AM) : [ ] —- MSI_BestTool: 25
MSI_FindTool
(10:05:46 AM) : [ ] – MSI_FindTool
Found DTM: Rune Hatchet.
(10:05:47 AM) : [ ] —- Found DTM: Rune Hatchet.
MSI_FindTool: Successfully Found Tool - Rune Hatchet
(10:05:47 AM) : [ ] —- MSI_FindTool: Successfully Found Tool - Rune Hatchet
MSI_FindObjectsIn
(10:05:48 AM) : [ ] – MSI_FindObjectsIn
MSI_FindObjectsTPA
(10:05:48 AM) : [ ] —- MSI_FindObjectsTPA
Not enough points!
(10:05:48 AM) : [ ] —— Not enough points!
Not enough points!
(10:05:48 AM) : [ ] —— Not enough points!
Not enough points!
(10:05:48 AM) : [ ] —— Not enough points!
Not enough points!
(10:05:48 AM) : [ ] —— Not enough points!
Not enough points!
(10:05:48 AM) : [ ] —— Not enough points!
MSI_FindObjectsTPA: True
(10:05:48 AM) : [ ] —— MSI_FindObjectsTPA: True
11 objects found!
(10:05:48 AM) : [ ] —- 11 objects found!
MSI_FindObjectsIn
(10:05:51 AM) : [ ] —- MSI_FindObjectsIn
MSI_FindObjectsTPA
(10:05:51 AM) : [ ] —— MSI_FindObjectsTPA
MSI_FindObjectsTPA: True
(10:05:51 AM) : [ ] ——– MSI_FindObjectsTPA: True
2 objects found!
(10:05:51 AM) : [ ] —— 2 objects found!
MSI_FindObjectsIn
(10:05:53 AM) : [ ] —— MSI_FindObjectsIn
MSI_FindObjectsTPA
(10:05:53 AM) : [ ] ——– MSI_FindObjectsTPA
Not enough points!
(10:05:53 AM) : [ ] ———- Not enough points!
Not enough points!
(10:05:53 AM) : [ ] ———- Not enough points!
Not enough points!
(10:05:53 AM) : [ ] ———- Not enough points!
Not enough points!
(10:05:53 AM) : [ ] ———- Not enough points!
Not enough points!
(10:05:53 AM) : [ ] ———- Not enough points!
MSI_FindObjectsTPA: True
(10:05:53 AM) : [ ] ———- MSI_FindObjectsTPA: True
13 objects found!
(10:05:53 AM) : [ ] ——– 13 objects found!
MSI_FindObjectsIn
(10:05:57 AM) : [ ] ——– MSI_FindObjectsIn
MSI_FindObjectsTPA
(10:05:57 AM) : [ ] ———- MSI_FindObjectsTPA
Not enough points!
(10:05:57 AM) : [ ] ———— Not enough points!
Not enough points!
(10:05:57 AM) : [ ] ———— Not enough points!
MSI_FindObjectsTPA: True
(10:05:57 AM) : [ ] ———— MSI_FindObjectsTPA: True
1 objects found!
(10:05:57 AM) : [ ] ———- 1 objects found!
[/PHP]
It just looks like it's duplicating each line with just a normal Writeln. I'll have more time later too look into it, if you haven't. I like this debugging and it'll be quite useful when it's perfect. :D

E2: Oh, this line, we should make it debug the tool name. :)
[PHP]
(10:05:46 AM) : [ ] —- MSI_BestTool: 25
[/PHP]

E3: Okay I found why it was duplicating… it was the status() at the beginning of MSI_Debug. I commented it out for now. Something I just noticed… the '—' gradually gets longer and longer, I'm assuming because the CurDebugLevel doesn't get Dec()'d somewhere.

E4: The decrementing issue it fixed from what I tested. It's an improvement nonetheless. I also went through the files to see if there were any MSI_CloseHeaders missing. There were a few instances in the object functions where it would exit and therefore unable to Dec() CurrDebugLevel. I didn't use try..finally statements there, but you may want to change that.

E5: What do you think about this? This is the Simba time stamp. I just added this line to the mainloop in RunMe.scar and commented out the time in MSI_Debug.

SetScriptProp(SP_WriteTimeStamp, [True]);

[PHP]
[0:00:00]: SRL Compiled in 16 msec
[0:00:00]: SMART Initialized.
Loaded: Server 152, Members: False, Signed: True, Super Detail: False.
[0:00:01]: Setting up MSI took 94 ms.
[0:00:01]: ** REFLECTION HOOKS OUTDATED **
[0:00:01]: [ ] MSI_SetupPlayer
[0:00:05]: [ ] – MSI_BestTool
[0:00:06]: [ ] —- CurrentSkill level: 88
[0:00:06]: [ ] – MSI_BestTool: Rune Hatchet
[0:00:06]: [ ] – MSI_FindTool
[0:00:07]: [ ] —- Found DTM: Rune Hatchet.
[0:00:07]: [ ] – MSI_FindTool: Successfully Found Tool - Rune Hatchet
[0:00:07]: [ ] – MSI_AutoObjects
[0:00:07]: [ ] —- MSI_FindObjectsIn
[0:00:07]: [ ] —— MSI_FindObjectsTPA
[0:00:07]: [ ] ——– Not enough points!
[0:00:07]: [ ] ——– Not enough points!
[0:00:07]: [ ] ——– Not enough points!
[0:00:07]: [ ] ——– Not enough points!
[0:00:07]: [ ] ——– Not enough points!
[0:00:07]: [ ] ——– Not enough points!
[0:00:07]: [ ] —— MSI_FindObjectsTPA: True
[0:00:07]: [ ] —— 14 objects found!
[0:00:08]: [ ] —— MSI_FindObjectsTPA
[0:00:08]: [ ] ——– Not enough points!
[0:00:08]: [ ] —— MSI_FindObjectsTPA: True
[0:00:09]: [ ] —- MSI_FindObjectsIn: True
[0:00:09]: [ ] —- MSI_FindObjectsTPA
[0:00:09]: [ ] —- MSI_FindObjectsTPA: True
[/PHP]
I think it can be set to display the actual time rather than the runtime, but I like the runtime. :)

OMG so sexy! o.O
*Tries to hide erection*

I prefer run(e)time too. Gives more insight into how long it has been running. :P
What's the [ ]?

Simba supports unicode characters, maybe we could find a nice symbol for indication?
http://en.wikipedia.org/wiki/List_of_Unicode_characters

EDIT: Like this �, ✔, ✘, ✪?

@RM (offtopic)

Come to the east coast of Canada rather than central/Coh3n's region. There's only cornfields everywhere around where he lives ;)

From: CX gamer
OMG so sexy! o.O
*Tries to hide erection*

I prefer run(e)time too. Gives more insight into how long it has been running. :P
What's the [ ]?

Simba supports unicode characters, maybe we could find a nice symbol for indication?
http://en.wikipedia.org/wiki/List_of_Unicode_characters

EDIT: Like this �, ✔, ✘, ✪?

The [ ] is where the player's name is suppose to be (I just didn't enter a username for the example). Also, yes I love the character's thing, great idea. :)

From: 3Garrett3
@RM (offtopic)

Come to the east coast of Canada rather than central/Coh3n's region. There's only cornfields everywhere around where he lives ;)

Lmao, true (for the most part), but Nava and I are so much cooler! :D

E: Added the timestamp. It can easily be changed later if needed. CX.. If we want to add a character at the beginning, we may have to add a parameter to the debug functions, which isn't really a big deal I guess, but it would be nice if it could be avoided somehow.

Yea, I don't think it can be avoided, unless you make an AI that detects wether or not a debug is a warning, info or an alert. But if it, then don't implement it. :P
I just threw the idea out there.

From: CX gamer
Yea, I don't think it can be avoided, unless you make an AI that detects wether or not a debug is a warning, info or an alert. But if it, then don't implement it. :P
I just threw the idea out there.

Yeah it's a good idea, and having another parameter isn't bad. Before this system we had 3 params in the MSI_Debug procedure. I think it would be nice to have a clear difference between errors and successes.

Furthermore, there is another thing I'd like to add :p I'd like it to look more like:

[php]
[00.00.01] - - - MSI_FindObjectsTPA
[00.00.10] ~ ~ ~ MSI_FindObjectsTPA: true
[00.00.20] * * * MSI_FindObjectsTPA: false
[/php]

Different…'lining' for different results (on headers).

~RM

That's neat. Though it might get a little complicated to read.

From: CX gamer
That's neat. Though it might get a little complicated to read.

Maybe, maybe not. We'd have to see. I think I like your idea with the symbols better though.