SRL Archive - Reflection Help

Well there's these two rocks (1 coal and 1 gold) in the Dwarfen Mines that have a static ID (30933) no matter whether they're mined or not. This is extremely unusual seeing as 30933 is also the ID of some unmineable scenery rocks in the area. It seems as if maybe there's a scenery rock under the gold and coal rock which makes you unable to get or detect the ID of the real rock. Any ideas on how I could detect when they're active so I'm not constantly going over to empty rocks?

[Offtopic] Why doesn't Jagex do this to all their rocks, seeing as this makes it significantly harder to create mining bots :confused:

EDIT: Just realized this might be a problem with Heysus' Ref Debugger, I'll see what else I can find…

EDIT: Was going to check them on RSBot, but I can't get RSBot on this computer :\ If anyone wants to try they're the two furthest south (right next to the mining guild entrance from inside the Dwarfen Mines).

procedure FindID;
Var
  UID: UID;
  t: Tpoint;
begin
T := getmypos;
UID := GetObjectAt(T.X-1, T.Y);
writeln(inttostr(UID.ObjType));
UID := GetObjectAt(T.X+1, T.Y);
writeln(inttostr(UID.ObjType));
UID := GetObjectAt(T.X, T.Y-1);
writeln(inttostr(UID.ObjType));
UID := GetObjectAt(T.X, T.Y+1);
writeln(inttostr(UID.ObjType));
end;

An alternative is when you check for rocks to mine, is ignoring those two rocks.

Var
UID: UID;

Is that even possible? lol.

Runescapian, just check for the tile of the rock you are going to mine, if it's the one of this crap one, don't mine it.

you could check a further distance with some simple for loops.

int i,x;
for(i=1;i<=5;i++) {
  for(x=1;x<=5;x++) {
    UID = GetObjectAt(i,x);
    // Print crap
  }
}

That's in Java… but you get the logic.

From: Capricorn

procedure FindID;
Var
  UID: UID;
  t: Tpoint;
begin
T := getmypos;
UID := GetObjectAt(T.X-1, T.Y);
writeln(inttostr(UID.ObjType));
UID := GetObjectAt(T.X+1, T.Y);
writeln(inttostr(UID.ObjType));
UID := GetObjectAt(T.X, T.Y-1);
writeln(inttostr(UID.ObjType));
UID := GetObjectAt(T.X, T.Y+1);
writeln(inttostr(UID.ObjType));
end;

An alternative is when you check for rocks to mine, is ignoring those two rocks.

I'd rather not ignore them, though that's what I'm doing right now.

From: n3ss3s
Runescapian, just check for the tile of the rock you are going to mine, if it's the one of this crap one, don't mine it.

In my script I have an ID, Tile, OreType, etc. for each rock, so that's not a problem. I'd rather not have to ignore them though.

From: Tniffoc
you could check a further distance with some simple for loops.

int i,x;
for(i=1;i<=5;i++) {
  for(x=1;x<=5;x++) {
    UID = GetObjectAt(i,x);
    // Print crap
  }
}

That's in Java… but you get the logic.

Is this for finding the ID? Well, I don't think it's the Debugger's fault after all, but I'll try finding the ID on my own in a sec.

You could always throw in a color check, to see if these special rocks have their ores back.

Yeah I was considering that, seeing as that's probably my only option really. But I'm not really feeling making a whole color system of detecting rocks just because of 2 rocks in a not so common mine :p

I just double checked the ID, and yes, it's 30933 :(

From: n3ss3s
Runescapian, just check for the tile of the rock you are going to mine, if it's the one of this crap one, don't mine it.

Thats the way to go imo :).

Nava and I came across these when coding our script too. It happens in RSBOT's debugging as well as SMART's. Perhaps there is another object on top of the rock and the ID showing is that object's ID. That leads me to think perhaps if you search for the ID of a normal ore rock, maybe you'd still find it underneath the other rock.

From: ZephyrsFury
Nava and I came across these when coding our script too. It happens in RSBOT's debugging as well as SMART's. Perhaps there is another object on top of the rock and the ID showing is that object's ID. That leads me to think perhaps if you search for the ID of a normal ore rock, maybe you'd still find it underneath the other rock.

If that's true then that would mean it's possible to have more than one object on a tile, leaving another hook(s) to be found.

From: ZephyrsFury
Nava and I came across these when coding our script too. It happens in RSBOT's debugging as well as SMART's. Perhaps there is another object on top of the rock and the ID showing is that object's ID. That leads me to think perhaps if you search for the ID of a normal ore rock, maybe you'd still find it underneath the other rock.

Seems like the best explanation thus far. Did you ever find out whether that's possible?

I'll test that theory now.

EDIT: Nope, can't find the ID of the rock. There are 2 gold rocks next to eachother (one of them is the 30933 rock) and the other's ID is 31066. I did a search for everything between 31060 to 31070 and it didn't find the 30933 rock :\

Um, 30933 is not between 31060 and 31070.

From: Runescapian aka Tad
Seems like the best explanation thus far. Did you ever find out whether that's possible?

I'll test that theory now.

EDIT: Nope, can't find the ID of the rock. There are 2 gold rocks next to eachother (one of them is the 30933 rock) and the other's ID is 31066. I did a search for everything between 31060 to 31070 and it didn't find the 30933 rock :\

From: senrath
Um, 30933 is not between 31060 and 31070.

I lol'd.

From: senrath
Um, 30933 is not between 31060 and 31070.

From: ian.
I lol'd.

+1 :p

I was just referring to the rock that way. According to Zeph's theory that rock would actually have a normal ID, but if that's right, I dont think we can detect it.

KBot has a class identified as "SpecialWorldObject" with two accessor methods. One is a "fake" id and the other is supposedly the real id. What we might be seeing is this "fake" id instead of the real one we want. However, I'm not sure how we would access it, because the field is generically stored as another class (KBot calls this GameObject) and would need to be type-casted for us to be able to access it, which SMART can't do right now as far as I know.

From: Method
KBot has a class identified as "SpecialWorldObject" with two accessor methods. One is a "fake" id and the other is supposedly the real id. What we might be seeing is this "fake" id instead of the real one we want. However, I'm not sure how we would access it, because the field is generically stored as another class (KBot calls this GameObject) and would need to be type-casted for us to be able to access it, which SMART can't do right now as far as I know.

So I'm guessing this problem isn't limited to a few select rocks, then?

Other objects may be similar, yes.