RuneMate Beta 6 Bug Reports

Discussion in 'Client & Site Support' started by Arbiter, Mar 31, 2014.

Thread Status:
Not open for further replies.
  1. Same drill as last time. Please remember to repost any bugs that persist from the Beta 5 Bug Reports in addition to any new ones you find.

    In pushing through to RC and a full Bot Store,
  2. 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):
    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.         }
    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.
  3. Not actually a bug, but I find the naming a bit strange.
    Code (Text):
    2.         final GlobalPathBuilder builder = new GlobalPathBuilder(start, destination);
    3.         final GlobalPath path = builder.generatePath();
    Wouldn't builder.buildPath make more sense?
  4. How about just build?
  5. 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:

    Sounds good.
  6. Can you get the widgets for me and if possible a dynamic way to detect them?
  7. Yeah they use settings, I'll get you all info needed

    Code (Text):
    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)
    8. Widgets:
    9. Parent: 548
    10. Children: 75 (hitpoints), 85 (prayer), 93 (run energy)
    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.
    It seems it also tries to click coordinates that are slightly off-minimap, specifically at this location:
    Code (Text):
    2. public final class HudDebug extends LoopingScript {
    4.     private final int parent_index = 548; //label: HUD
    5.     private final Filter<InterfaceComponent> filter = Interfaces.getActionFilter("Cure", "Activate", "Setup", "Toggle Run");
    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. }
    Code (Text):
    2. Detected: parent=548, child=75
    3. Detected: parent=548, child=85
    4. Detected: parent=548, child=93
    #7 Salvation, Mar 31, 2014
    Last edited: Mar 31, 2014
  8. Well I also meant a dynamic way to detect the widgets (for bounds and such)
  9. @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
  10. Code (Text):
    2. Bank.withdraw("Flax", 28)
    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.
  11. Code (Text):
    2. coordinate.minimap().click();
    Does not work (isVisible returns false when it should return true) if plane != 0
    I assume it translates incorrectly
  12. 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.
  13. Fixed
Thread Status:
Not open for further replies.

Share This Page