SRL Archive - MSI Suggestions

I don't know exactly what needs to be changed, but I feel like something does. It would seem that there are a lot of false positives/negatives when working with the items. I don't know if it's the DTMs failing, or the colors from one item being found on another item.

I'll just throw a couple ideas out there.

• This doesn't have anything to do with finding the items, but ItemP isn't used at all. We may be able to save the point when it's found. For example, the script looks for the required tools every load. Doesn't make much of a difference, but it lowers efficiency. Could save the point the first load, then not look for it for the rest of runtime (unless told otherwise).
• Get rid of the tolerance attribute. As far as I know, the item's colors are static, so if we picked 3-4 colors for every item and have 0 tolerance, it's very unlikely to get 2 items mixed up.

Thoughts? Ideas? Suggestions?

I like ItemP idea. Not sure about tol & constant inv colors.

Were they made static recently? Cus I remember quite a few of my functions breaking every now and then due to color changes.

~RM

From: Sir R. Magician
I like ItemP idea. Not sure about tol & constant inv colors.

Were they made static recently? Cus I remember quite a few of my functions breaking every now and then due to color changes.

~RM

I've just always thought they were. I will put that on my to do list for tomorrow. I'll test with a few items and see how it goes. But I'm sure you know what I mean, there are a lot of colors that are similar. Iron/Steel pickaxe and tin/silver ore for example. Same goes for really any pickaxe and it's corresponding ore.

There's just got to be a better way..

For you ItemP suggestion; I say we do it.

In MSI_FindTool we can go one step further and if the tool is found in the Inv, then store the slot number to ItemP.

I did this in my yew cutter, then just stored the data to an array of a record set to the length of HowManyPlayers;

In case I didn't explain it very well (from my yew cutter):

function LocateHatchet: Boolean;
var
  i, cCount: Integer;
  tEtry: Boolean;
  iBox: TBox;
begin
  repeat

    case GetCurrentTab of
      tab_Inv:
        begin

          for i := 1 to 28 do
          begin
            iBox := InvBox(i);
            cCount := CountColor(srl_outline_black, iBox.x1, iBox.y1, iBox.x2, iBox.y2);

            if (cCount = Normal_Hatchet_BL) or (cCount = Dragon_Hatchet_BL) then
            begin
              Result := True;
              AxeInfo[CurrentPlayer].Inv := True;
              AxeInfo[CurrentPlayer].iSlot := i;
              Writeln('Hatchet located in Inventory slot: '+IntToStr(i)+';');
              Exit;
            end;

            if i = 28 then
              GameTab(tab_Equip);
          end;
        end;

      tab_Equip:
        begin
          cCount := CountColor(srl_outline_black, 569, 288, 602, 321);

          if (cCount = Normal_Hatchet_BL) or (cCount = Dragon_Hatchet_BL) then
          begin
            Result := True;
            AxeInfo[CurrentPlayer].Eqpt := True;
            Writeln('Hatchet is equipped.');
            Exit;
          end;

          tEtry := True;
          GameTab(tab_Magic);
        end;

      else
        begin

          if i = 0 then
          begin
            GameTab(tab_Inv);
            Continue;
          end;

          if (i > 0) and (tEtry) then
          begin
            Writeln('Failed to find hatchet.');
            Exit;
          end;
        end;
    end;

  until(Result);
end;                                        

I don't see why we couldn't incorporate the same thing into MSI_FindTool or something.

From: NCDS
For you ItemP suggestion; I say we do it.

In MSI_FindTool we can go one step further and if the tool is found in the Inv, then store the slot number to ItemP.

I did this in my yew cutter, then just stored the data to an array of a record set to the length of HowManyPlayers;

In case I didn't explain it very well (from my yew cutter):

function LocateHatchet: Boolean;
var
  i, cCount: Integer;
  tEtry: Boolean;
  iBox: TBox;
begin
  repeat

    case GetCurrentTab of
      tab_Inv:
        begin

          for i := 1 to 28 do
          begin
            iBox := InvBox(i);
            cCount := CountColor(srl_outline_black, iBox.x1, iBox.y1, iBox.x2, iBox.y2);

            if (cCount = Normal_Hatchet_BL) or (cCount = Dragon_Hatchet_BL) then
            begin
              Result := True;
              AxeInfo[CurrentPlayer].Inv := True;
              AxeInfo[CurrentPlayer].iSlot := i;
              Writeln('Hatchet located in Inventory slot: '+IntToStr(i)+';');
              Exit;
            end;

            if i = 28 then
              GameTab(tab_Equip);
          end;
        end;

      tab_Equip:
        begin
          cCount := CountColor(srl_outline_black, 569, 288, 602, 321);

          if (cCount = Normal_Hatchet_BL) or (cCount = Dragon_Hatchet_BL) then
          begin
            Result := True;
            AxeInfo[CurrentPlayer].Eqpt := True;
            Writeln('Hatchet is equipped.');
            Exit;
          end;

          tEtry := True;
          GameTab(tab_Magic);
        end;

      else
        begin

          if i = 0 then
          begin
            GameTab(tab_Inv);
            Continue;
          end;

          if (i > 0) and (tEtry) then
          begin
            Writeln('Failed to find hatchet.');
            Exit;
          end;
        end;
    end;

  until(Result);
end;                                        

I don't see why we couldn't incorporate the same thing into MSI_FindTool or something.

Seems like it would work well with our current set up, wouldn't it?

Also, AFIAK it's not static. There was a shut/ian argument w/ videos about this a month ago or so.. Check that out maybe?

Okay, so we could change ItemP to Slot and store the inventory slot. If it's not in the inventory then it would just be 0. We obviously wouldn't use this for produce (logs, ore, etc), but it would be useful for tools.

E: Too bad they aren't static. :( As we find items that get mixed up we'll just have to try to make them more accurate with some different colors, etc.

From: Coh3n
Okay, so we could change ItemP to Slot and store the inventory slot. If it's not in the inventory then it would just be 0. We obviously wouldn't use this for produce (logs, ore, etc), but it would be useful for tools.

Yeah, that works for me.

Plus:

program new;
{.include SRL/SRL.scar}
begin
ActivateClient;
Wait(500);
Writeln(ToStr(GetColor(668,268)));
end.   

Writes different colours after I refresh the client. Was using it to grab a lobby colour. We still need tol, or something.

I should have been more specific. When I said static, I didn't mean that every point on the item is the same color no matter what, but that one color will be found somewhere on the item. Meaning if 1234567 was found on a mith hatchet at point 123, 456, when the client is refreshed it may be found at 456, 789.

I remember Nava telling me that he discovered this a while. Things obviously could have changed

Let's start using ItemP and this then?
http://villavu.com/forum/showpost.php?p=724373&postcount=71

To SRL

const
  SLOT_HELMET = 30;
  SLOT_NECK = 31;
  SLOT_WEAPON = 32;
  SLOT_SHIELD = 33;
  SLOT_LEGS = 34;
  SLOT_FEET = 35;
  SLOT_RING = 36;

and store the slot where the tool was found to either 1..28 or SLOT_WEAPON :)

From: Zyt3x
Let's start using ItemP and this then?
http://villavu.com/forum/showpost.php?p=724373&postcount=71

If the blacklists can be effectively implemented I would love to use them. Correct me if I'm wrong, but is the information gathered from the GE? So it's basically automatically updated?

From: marpis
To SRL

const
  SLOT_HELMET = 30;
  SLOT_NECK = 31;
  SLOT_WEAPON = 32;
  SLOT_SHIELD = 33;
  SLOT_LEGS = 34;
  SLOT_FEET = 35;
  SLOT_RING = 36;

and store the slot where the tool was found to either 1..28 or SLOT_WEAPON :)

The only reason we would need to know the inventory slot is for dropping/banking, but knowing the equipment slot could be useful in the future, who knows.

From: Coh3n
If the blacklists can be effectively implemented I would love to use them. Correct me if I'm wrong, but is the information gathered from the GE? So it's basically automatically updated?


The only reason we would need to know the inventory slot is for dropping/banking, but knowing the equipment slot could be useful in the future, who knows.

That's correct. Plus if for some reason jagex puts new or updated items in game that are not in the GE database, you could have an item learning script that instructs users to put 1 of each needed item in the inventory, grabs the uptext/reflection, and generates a blacklist. Or even something that does it automatically during the regular script runtime after detecting a problem, though that won't be needed until you are autoing straight through the weekly updates.

The black pixels on the items on the GE (not in-game) isn't 100% accurate

From: Boreas
That's correct. Plus if for some reason jagex puts new or updated items in game that are not in the GE database, you could have an item learning script that instructs users to put 1 of each needed item in the inventory, grabs the uptext/reflection, and generates a blacklist. Or even something that does it automatically during the regular script runtime after detecting a problem, though that won't be needed until you are autoing straight through the weekly updates.

Perfect!

Is it suppose to work in Simba? I notice there's a lot of {} inside [] in the list of items, which IIRC was a problem in Simba? I also get unknown type HDC (line 56).

Handle: HDC; 

Probably not, I think Niels wrote it for SCAR quite a while ago. If the HDC stuff is for the GE site, you could leave that out, and just update the current list from in game.

From: Boreas
Probably not, I think Niels wrote it for SCAR quite a while ago. If the HDC stuff is for the GE site, you could leave that out, and just update the current list from in game.

Alright I'll have to figure out how to do that later. I'd like to get this system implemented as we seem to be getting a lot of false negatives/positives with some items.

Either blacklists or changing colors/tolerance (which I still have to test).