SRL Archive - MSI Suggestions

Working with Magic.simba, I've realized that our current progress report won't work well for magic. :( I was thinking about adding another pointer in TScript for reports that can be specific to each script. If not that, then a case in MSI_ProgressReport to have reports for different skills.

The whole report wouldn't be changed, just a small part would vary from skill to skill:

{     Script: Varrock East Oaks                                  }
{       Time:  00s                                               }
{       Skill: Woodcutting                                       }
{       Loads: 0                                                 }
{       Exp:   0                                                 }
{       Level: Not yet defined                                   }
{         Item:   Oak logs                                       }
{         Amount: 0                                              }

Where instead of loads and items, it would be like total casts and casts per spell (for magic). For fighting it could be something like Total Kills and specific monster kills.

I'm sure you get the idea.

Thoughts?

Sounds doable and good.

TScript
ReportHeaders: TStringArray;

;)

Although TScript might not be the best place… but I have nothing else to suggest atm :p

~RM

From: Sir R. Magician
Sounds doable and good.

TScript
ReportHeaders: TStringArray;

;)

Although TScript might not be the best place… but I have nothing else to suggest atm :p

~RM

I don't really see any other options unless ReportHeaders was a 2DArray in the same order as the scripts. Hopefully that makes sense.

From: Sir R. Magician
Sounds doable and good.

TScript
ReportHeaders: TStringArray;

;)

Although TScript might not be the best place… but I have nothing else to suggest atm :p

~RM

I was thinking more like:

Report: procedure;

TScript.Report := @MSI_MiningReport();

Another idea: I think we should move the TotalLoads attribute down to be script specific since not all skills have loads (i.e. magic, fighting, etc.). Also, BreakLoads would be changed to BreakTime. The new one would look something like this:

with MSI_Players[1] do
begin
  Name       := '';
  Pass       := '';
  Nick       := '';
  Pin        := '';
  Active     := True;
  Member     := False;
  Location   := LOC_POWER_SKILL;
  BreakTime  := 30; // How long to auto before breaking/switching players (in minutes)
  TotalTime  := 180;

  with Scripts[0] do
  begin
    Name  := SCRIPT_POWER_CHOP;
    Trees := [TREE_WILLOW, TREE_NORMAL];
    Loads := 50; // Total loads to powerchop
  end;
end;

TotalTime could also be changed from minutes to hours, makes more sense.

Thoughts?

TotalTime should stay minutes imo. People can do 60*X where they replace X with hours if they want hours.

We'd need a way to make the script know when to change scripts too. Either level or loads (or even better, the use can chose which of those to use)

From: Zyt3x
We'd need a way to make the script know when to change scripts too. Either level or loads (or even better, the use can chose which of those to use)

Yep, I'd say that would be script-specific also. After magic, my next project is to get multiple scripts working.

From: Coh3n
Another idea: I think we should move the TotalLoads attribute down to be script specific since not all skills have loads (i.e. magic, fighting, etc.). Also, BreakLoads would be changed to BreakTime. The new one would look something like this:

with MSI_Players[1] do
begin
  Name       := '';
  Pass       := '';
  Nick       := '';
  Pin        := '';
  Active     := True;
  Member     := False;
  Location   := LOC_POWER_SKILL;
  BreakTime  := 30; // How long to auto before breaking/switching players (in minutes)
  TotalTime  := 180;

  with Scripts[0] do
  begin
    Name  := SCRIPT_POWER_CHOP;
    Trees := [TREE_WILLOW, TREE_NORMAL];
    Loads := 50; // Total loads to powerchop
  end;
end;

Then after each load/Inv check if Time > BreakTime and break if true? or Just take breaks wherever the char is when the time > BreakTime?


I agree with keeping TotalTime in minutes.

From: NCDS
Then after each load/Inv check if Time > BreakTime and break if true? or Just take breaks wherever the char is when the time > BreakTime?

It can be just like it is now, if BreakTime = 0 then don't break.

From: NCDS

I agree with keeping TotalTime in minutes.

Sounds good.

E: I'm just trying to get some things more organized for the player setup and progress report so it's easier to add new skills.

E2: Oh, I forgot to ask what you guys thought about taking the Time and Total Loads out of the progress report since we already display the time and loads for each script. Or do you think it's better to keep the totals?

From: Coh3n
It can be just like it is now, if BreakTime = 0 then don't break.

I meant when will you tell it to "break". :p If it goes by time instead of loads then the time could 'expire' at any point in the script. Will you want it to take a break while chopping trees, or have it wait to go to the bank?

From: Coh3n

Sounds good.

E: I'm just trying to get some things more organized for the player setup and progress report so it's easier to add new skills.

E2: Oh, I forgot to ask what you guys thought about taking the Time and Total Loads out of the progress report since we already display the time and loads for each script. Or do you think it's better to keep the totals?

I don't really have an opinion either way on that one to be honest :redface:

From: NCDS
I meant when will you tell it to "break". :p If it goes by time instead of loads then the time could 'expire' at any point in the script. Will you want it to take a break while chopping trees, or have it wait to go to the bank?

Oh, then yeah, it would check at some point in the mainloop, probably after each load like I does now.

E: Also, I think I'll add this little part (script-specific part) to the SMART screen. :) Any good location suggestions?

From: Coh3n
Oh, then yeah, it would check at some point in the mainloop, probably after each load like I does now.

E: Also, I think I'll add this little part (script-specific part) to the SMART screen. :) Any good location suggestions?

I would say put it in the ChatBox to the right side, or keep it small and put it right above chat box all the way to the left.

Good plan though :)

From: NCDS
I would say put it in the ChatBox to the right side, or keep it small and put it right above chat box all the way to the left.

Good plan though :)

I wonder if there's a way to make it look like there's nothing in the chatbox, so the report can be displayed right over all the text.

From: Coh3n
I wonder if there's a way to make it look like there's nothing in the chatbox, so the report can be displayed right over all the text.

Could we just put a .bmp of the ChatBox over the actual chatbox, or would that kill everything?

From: NCDS
Could we just put a .bmp of the ChatBox over the actual chatbox, or would that kill everything?

Absolutely no idea. That's something we'd have to look in to. I'm not sure if anyone's done that before.

You can paint a TPA onto it, and then paint text on top ;) There might be faster ways tho.

And I'd say keep the totals :p They look pretty :)

~RM

From: Sir R. Magician
You can paint a TPA onto it, and then paint text on top ;) There might be faster ways tho.

Yeah could be slow. Will have to test it out. :) If the TPA is only painted at startup it wouldn't make a difference for the rest of the script, it would just be there.

From: Sir R. Magician

And I'd say keep the totals :p They look pretty :)

Sure, the labels (excluding total time) will just have to be edited depending on the skill. It would also display multiple things: Total Loads, Total Time, Total Casts, Total Kills only if the user was to use a script of every skill for that player.

If we're going to have it on the chatbox, I'd like it to be somewhat transparent… It would be slower than normal painting.. about 100% slower I'd guess

From: Zyt3x
If we're going to have it on the chatbox, I'd like it to be somewhat transparent… It would be slower than normal painting.. about 100% slower I'd guess

If possible, I think that would be a neat effect, plus you can still see the chat, which, I'm guessing, is why you suggested it in the first place.

Correct, Coh3n :)

Just to prove that it works, here I'm painting the mining guild purple
the players looks weird because the method I used was quite slow

From: Zyt3x
Correct, Coh3n :)

Just to prove that it works, here I'm painting the mining guild purple
the players looks weird because the method I used was quite slow

Oh cool. I don't think it should be that transparent, but it can be experimented with.

How did you do this? :D

~RM

I didn't save the script, but this is (basically) what I did:

SMART_DrawDotsEx(True, [], 0); // Clearing the canvas...
for Y := MSY1 to MSY2 do
  for X := MSX1 to MSX2 do
  begin
    C := GetColor(X, Y);
    ColorToRGB(C, R, G, B);
    R := R + 30;
    G := G + 0;
    B := B + 30;
    C := RGBToColor(R, G, B);
    SMART_DrawDotsEx(False, [Point(X, Y)], C);
  end;

And just mess around with the + 30 stuff.

From: Zyt3x
I didn't save the script, but this is (basically) what I did:

SMART_DrawDotsEx(True, [], 0); // Clearing the canvas...
for Y := MSY1 to MSY2 do
  for X := MSX1 to MSX2 do
  begin
    C := GetColor(X, Y);
    ColorToRGB(C, R, G, B);
    R := R + 30;
    G := G + 0;
    B := B + 30;
    C := RGBToColor(R, G, B);
    SMART_DrawDotsEx(False, [Point(X, Y)], C);
  end;

And just mess around with the + 30 stuff.

Humm interesting.

We can highly speed it up by using GetColors rather than GetColor.

And we can get the TPA from TPAFromBox

TPA := TPAFromBox(MSBox)
Colors := GetColors(TPA);

for i:= 0 to high(TPA)
//...

SmartDrawDotsEx

This would also speed it up because it'd only draw it once :)


Seems like a possibility to me! :-)

~RM

Yeah, that was just a script to prove the concept :)
Also FindColorsTolerance would be cool, as we don't really need good graphics in the chatbox or W/E.. :p

I like to see the chatbox, and transparent sounds sexy to me. What about over the inventory? Plenty of space, not a whole lot of stuff hapening there, considerably smaller area than the mainscreen/chatbox.

Pros:
Plenty of space
Doesn't cover up important things
Not as big of an area to paint on as opposed to MS/Chatbox (faster)

Cons:
A bit narrow, but it shouldn't be a big problem….


E: And if you're worried about being hard to read text on that area, you could paint over the inventory with a transparent color, and then paint over *that* with the text.

From: nickrules
I like to see the chatbox, and transparent sounds sexy to me. What about over the inventory? Plenty of space, not a whole lot of stuff hapening there, considerably smaller area than the mainscreen/chatbox.

Pros:
Plenty of space
Doesn't cover up important things
Not as big of an area to paint on as opposed to MS/Chatbox (faster)

Cons:
A bit narrow, but it shouldn't be a big problem….


E: And if you're worried about being hard to read text on that area, you could paint over the inventory with a transparent color, and then paint over *that* with the text.

I'd like to see how both of them look. :)

What if we just had a settings file so people could choose if/where they want these kinds of things.

From: NCDS
What if we just had a settings file so people could choose if/where they want these kinds of things.

Like a .simba file or text file?

E: Could add a Settings menu item to the MSI menu and have it work similar to Simba's settings file.

From: Coh3n
Like a .simba file or text file?

E: Could add a Settings menu item to the MSI menu and have it work similar to Simba's settings file.

I was thinking a text file where the user could set certain vars or whatever works really, but a .simba should work just the same.

From: NCDS
I was thinking a text file where the user could set certain vars or whatever works really, but a .simba should work just the same.

Yeah either would work. I like the idea of a settings menu item too, especially if we ever have MSI run from a menu item.

This has been committed with the Magic stuff. Instead of using a pointer, I created a new file, Reports.simba and now there's a case in MSI_ProgressReport.

From: Coh3n
This has been committed with the Magic stuff. Instead of using a pointer, I created a new file, Reports.simba and now there's a case in MSI_ProgressReport.

Never committed Reports.Simba :redface:

Son of a…

Thanks, fixed now.