Jump to content
IceKontroI

Reading TRiBot source code for certain methods

Recommended Posts

I've been trying to read the source code for various tribot functions such as Mouse.leaveGame() or Mouse.sendClickEvent() so I can create similar but more updated versions of them as part of a small API I'm creating ATM. The problem is that when I decompile TRiBot.jar and look at the source code for those methods it's very difficult to understand how everything ties together. I get that this is Java's way of reducing jar file size but I'm wondering if there is a more conventional way of doing this. It also seems like there's missing code but that could just be me misreading the data structures. If anyone knows of a better way of doing this I would greatly appreciate it as it would speed up my API generation by quite a large amount.

Share this post


Link to post
Share on other sites
3 minutes ago, halfway said:

smh if anyone can just "decompile" this bot 

you can decompile TRiBot.jar just like you can do with any .jar file. Other users have mentioned that they've viewed the source code so either they decompiled it themselves or had access to the real source.

Share this post


Link to post
Share on other sites
9 minutes ago, IceKontroI said:

you can decompile TRiBot.jar just like you can do with any .jar file. Other users have mentioned that they've viewed the source code so either they decompiled it themselves or had access to the real source.

public static void leaveGame(boolean lose_focus) {
        boolean var10000;
        Point a;
        if((a = getPos()) == null) {
            move(General.random(-50, 550), General.random(-15, -40));
            var10000 = lose_focus;
        } else {
            move(General.random(a.x - 100, a.x + 100), General.random(-15, -40));
            var10000 = lose_focus;
        }

        if(var10000) {
            General.sleep(1400, 4600);
            mm.DE().jH().iN().UH(true);
        }

    }

 

It randomizes your x position, and randomizes ur Y position outside of the screen. To duplicate a function like this and add in any side of the screen, you would modify that part along with adding the ability to leave any side of the screen, you also probably wouldn't be able to call mm.DE.W/E in your script so you may need to find out what that does to actually emulate it.

Edited by Deluxes

Share this post


Link to post
Share on other sites
1 minute ago, Deluxes said:
public static void leaveGame(boolean lose_focus) {
        boolean var10000;
        Point a;
        if((a = getPos()) == null) {
            move(General.random(-50, 550), General.random(-15, -40));
            var10000 = lose_focus;
        } else {
            move(General.random(a.x - 100, a.x + 100), General.random(-15, -40));
            var10000 = lose_focus;
        }

        if(var10000) {
            General.sleep(1400, 4600);
            mm.DE().jH().iN().UH(true);
        }

    }

 

It randomizes your x position, and randomizes ur Y position outside of the screen. To duplicate a function like this and add in any side of the screen, you would modify that part along with adding the ability to leave any side of the screen, you also probably wouldn't be able to call mm.DE.W/E in your script so you may need to find out what that does to actually emulate it.

That's the basics of it, yes, but there's more to it than just that which is what I'm getting at. This line of code

mm.DE().jH().iN.UH(true);

is likely the way it "loses focus" to the game screen which I'm unable to replicate on my own because it's obfuscated. I was going to create a method that expanded on this whole process by combining elements of Mouse.leaveGame() and Mouse.sendClickEvent() that would allow the mouse to re-enter the game screen through a different point than the one it left from. This would simulate a player tabbing out and re-entering the screen afterward much more realistically.

Also what decompiler are you using? Your code seems slightly clearer than mine.

Share this post


Link to post
Share on other sites
Just now, IceKontroI said:

That's the basics of it, yes, but there's more to it than just that which is what I'm getting at. This line of code

mm.DE().jH().iN.UH(true);

is likely the way it "loses focus" to the game screen which I'm unable to replicate on my own because it's obfuscated. I was going to create a method that expanded on this whole process by combining elements of Mouse.leaveGame() and Mouse.sendClickEvent() that would allow the mouse to re-enter the game screen through a different point than the one it left from. This would simulate a player tabbing out and re-entering the screen afterward much more realistically.

Also what decompiler are you using? Your code seems slightly clearer than mine.

Actually you can call 

mm.DE().jH().iN.UH(true)

As long as you do not upload the script to the repository. I use Bytecode Viewer 3.0.0.

Share this post


Link to post
Share on other sites
3 minutes ago, IceKontroI said:

I didn't realize that, thanks!

You can also do some useful stuff like this.

public static void setGraphics(boolean value) {
        if (!TRiBot.a.j.get("Disable Graphics").isSelected() && !value)
            TRiBot.a.j.get("Disable Graphics").doClick();
        else if (TRiBot.a.j.get("Disable Graphics").isSelected() && value)
            TRiBot.a.j.get("Disable Graphics").doClick();
    }

You can also change Disable Graphics to Block User Input and such to disable those automatically :)

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Our picks

    • This release will:

      Fix key event handling issue


      Fix other event handling issue


      Fix RSServer hook


      Update world hopper to have it use OCR, thanks to Todd


      Use proper disposal of old Graphics objects


      Reformat code


      Rearrange code


      Organize code imports


      Apply around 8000 automated code refactorings


      Make preparations for Java 9


      Fix 11 various bugs


      Add more reliable debugging support


      Fix mouseEntered/Exited event dispatching bug


      Fix minimap walking bug where it opens the map


      Fix broken hooks for today's game update
        • Thanks
        • Like
      • 86 replies
    • This update will:

      Fix GE inventory item positioning bug


      Fix broken object hooks
        • Like
      • 27 replies
    • This release will:

      Fix some ClosedChannelException bug


      Fix bug in RSObject#getAllTiles


      Add game tab support for "Kourend Favour"
        • Like
      • 15 replies
    • This release will:

      Fix Settings UI placement bug


      Fix game object location bug


      Fix small layout bug making the client shift up and down


      Fix client crashing bug where loading the client with a small display area will cause the client to crash


      Fix annoying Linux bug relating to painting events and peers


      Fix settings saving bug where settings are saved to disk more often than they should


      Fix RSInterface#isBeingDrawn bug affecting a limited amount of people


      Drop Java 1.7 bytecode version for 1.8


      Important: Since the downloadable RS client uses Java 7, it will no longer be compatible with Looking Glass. To make up for this, we will add support for using other clients such as RuneLite (at a later date).


      This change was necessary to allow us to use Java 8 syntax. It also paves the way for Java 9/10/11 support.
        • Like
      • 40 replies
    • This update will:

      Fix the RSMenuNode bug which also fixes the bug with bank opening


      Fix the incorrect object positions bug


      Fix and re-enable the LG Objects API Accelerator


      Fix the RSObject#getAllTiles bug
        • Like
      • 22 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×