RuneMate Beta 6 Bug Reports

npc.getInteractingEntity now almost fully works, it returns the correct Actor in all but one cases: when the Actor is the local player.
As demonstrated in this image: The yaks attacking other players do interact with those players, but the one yak attacking the local player has drawn "null" on its model, to indicate getInteractingEntity returned null for said yak.

This must be fixed asap, for it would be incredibly difficult to detect random events without this!

Code (Text):

1.  
2.         for (final Npc npc : Npcs.getLoaded()) {
3.             final Model m = npc.getModel();
4.             final Actor a = npc.getInteractingEntity();
5.             if (m == null) {
6.                 continue;
7.             }
8.             final InteractableRectangle ir = m.getBoundingRectangle();
9.             if (ir == null) {
10.                 continue;
11.             }
12.             final Rectangle r = ir.getBounds();
13.             g.drawString(a != null ? a.getName() : "null", r.x + (r.width / 2), r.y + (r.height / 2));
14.         }
15.  

Also, when I started Beta 6 for the first time my stored account information had corrupted and showed only partially. I guess that that is the result of changing a few things around, but in case it actually is a bug, I thought I'd post it.

 

Not actually a bug, but I find the naming a bit strange.

Code (Text):

1.  
2.         final GlobalPathBuilder builder = new GlobalPathBuilder(start, destination);
3.         final GlobalPath path = builder.generatePath();
4.  

Wouldn't builder.buildPath make more sense?

 

How about just build?

 

A slight issue with walking and "Data orbs", when clicking a coordinate on the minimap these data orbs sometimes cover the coordinate, making the script bot unable to click on said coordinate. The interactable area should deduct the boundaries of the orbs if the orbs are turned on.

Data orbs: http://puu.sh/7QUTM.png
Setting: http://puu.sh/7QV3x.png

Sounds good.

 

Can you get the widgets for me and if possible a dynamic way to detect them?

 

Yeah they use settings, I'll get you all info needed

Edit:

Code (Text):

1.  
2. Settings:
3. Index: 1055
4. Values: 0, 8
5. Game: OSRS
6. Returns whether data orbs are enabled (first value) or not (second value)
7.  
8. Widgets:
9. Parent: 548
10. Children: 75 (hitpoints), 85 (prayer), 93 (run energy)
11.  
12. The bounds of above widgets partially cover the minimap region, meaning the client should not attempt to click within the bounds of any of these widgets if trying to click on a coordinate.
13.  

It seems it also tries to click coordinates that are slightly off-minimap, specifically at this location: http://puu.sh/7QX7g.png

Code (Text):

1.  
2. public final class HudDebug extends LoopingScript {
3.  
4.     private final int parent_index = 548; //label: HUD
5.     private final Filter<InterfaceComponent> filter = Interfaces.getActionFilter("Cure", "Activate", "Setup", "Toggle Run");
6.  
7.     @Override
8.     public void onLoop() {
9.         for (final InterfaceComponent ic : Interfaces.getAt(parent_index, filter)) {
10.             System.out.println("Detected: parent=548, child=" + ic.getIndex());
11.         }
12.         stop();
13.     }
14. }
15.  

Code (Text):

1.  
2. Detected: parent=548, child=75
3. Detected: parent=548, child=85
4. Detected: parent=548, child=93
5.  

 

Well I also meant a dynamic way to detect the widgets (for bounds and such)

 

@Cloud camera rotations are still off, rotating to NPC's not on the game screen causes and infinite left + right camera rotation.
No stack trace for it

 

Code (Text):

1.  
2. Bank.withdraw("Flax", 28)
3.  

Two issues:
A: if the item it's trying to withdraw isn't found within the first 48 slots (in other words: it has to scroll), it severely fucks up trying to find the item.
B: it does not actually withdraw the item, it hovers the item looking for the correct withdrawing action instead.

 

Code (Text):

1.  
2. coordinate.minimap().click();
3.  

Does not work (isVisible returns false when it should return true) if plane != 0
I assume it translates incorrectly

 

The camera is designed to go in the correct direction until it reaches or exceeds the specified value. It doesn't have the ability to switch directions in case of an overshoot (intentional). If it's going back and forth, it's most likely on your end.

Edit: Camera.setYaw would occasionally return false when it shouldn't have, I have fixed this in the next release.

 

Fixed