Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
GotZoped

Asynchronous Dangerous Player Detection

Recommended Posts

Introduction

 
The purpose of this tutorial is to help beginner / intermediate scripters get a better grasp on how asynchronous 
threads can be utilized to create "real-time" listeners that can be used to monitor things like Inventory,
Health, or even more complex things, like if a dangerous player or NPC is nearby.
 
This tutorial assumes that you understand the basics of scripting and development in java, so I will not be touching on anything related to the setup of your IDE or where you need to export your scripts to be able to run them within Tribot.
 
For advice on what to do if you need help in those areas, please visit the fourth post in this thread, I will provide links to additional information and links to all threads that helped me make this tutorial possible.
 
Table of Contents
 
   Threads
 
Edited by GotZoped

Share this post


Link to post
Share on other sites

Threads

 
A thread is a thread of execution in a program. The Java Virtual Machine allows an application to have multiple threads of execution running concurrently.
 
  • Provide a Runnable object. The Runnable interface defines a single method, run, meant to contain the code executed in the thread. 
    public class HelloRunnable implements Runnable {     public void run() {         System.out.println("Hello from a thread!");     }         public static void main(String args[]) {          (new Thread(new HelloRunnable())).start();     }}
  • Subclass Thread. The Thread class itself implements Runnable, though its run method does nothing. 
    public class HelloThread extends Thread {     public void run() {         System.out.println("Hello from a thread!");     }     public static void main(String args[]) {         (new HelloThread()).start();     } }
  • Notice that both examples invoke Thread.start in order to start the new thread. Which of these idioms should you use? The first idiom, which employs a Runnable object, is more general, because the Runnable object can subclass a class other than Thread. The second idiom is easier to use in simple applications, but is limited by the fact that your task class must be a descendant of Thread. 

This is the most important difference between a Runnable and a Thread.
When implementing a Runnable you leave the class available to inherit something else.

When inheriting a Thread you are limiting the class from inheriting anything else.

Java does not allow Multiple inheritance:
 

Multiple inheritance--and all the problems it generates--was discarded from Java. The desirable features of multiple inheritance are provided by interfaces--conceptually similar to Objective C protocols.

 
 
Interfaces:
 
In the Java programming language, an interface is a reference type, similar to a class, 
that can contain only constants, method signatures, default methods, static methods, and nested types. 
Method bodies exist only for default methods and static methods.
 
  • An interface declaration consists of modifiers, the keyword interface, the interface name, a comma-separated list of parent interfaces (if any), and the interface body.
    public interface GroupedInterface extends Interface1, Interface2, Interface3 {     // constant declarations     // base of natural logarithms     double E = 2.718282;     // method signatures     void doSomething (int i, double x);     int doSomethingElse(String s); }
  • As you can see an interface is not limited to a single inheritance, it is allowed to inherit from as many other interfaces as we want!
Edited by GotZoped

Share this post


Link to post
Share on other sites

How is this useful:

 
This image gives a good representation on how another thread can be utilized to run many calculations without blocking the processing that happens on the main thread of the script.
bkFnD05.gif
Thanks to @Starfox for this image.
 
Understanding how threads can be used is critical to the development of 'intelligent', 'reactive' scripts and can allow you to react to events in real time without effecting the run thread where most of your actions are being handled.
 
For Example: 
If you have a player performing a repeated action in an area where a player may come to kill you How would you constantly monitor if the player performing the action While also constantly monitoring if a dangerous player is nearby and planning to attack you?
 
  • Without threading we are left with a scenario where we have to create a loop that will monitor both cases, both of these seperate instances will require different actions. On top of that if we wanted to monitor for a dangerous player in a different loop we would have to bring the dangerous player logic to each other case where we might want to perform an action for avoiding a dangerous player. 
 
If the above sentence was confusing to you, do not be ashamed. In a world without multi-threading were left duplicating code and nesting if-statements creating very confusing, hard to follow code. 
 
  • With threading we are able to create another chain of events that will run in parallel (asynchronously) with your already running script code. This allows us to process multiple things at once. Therefore we should be able to monitor the player, making sure it is still performing the repeated action. While also constantly scanning for players that meet the correct parameters (things that make them dangerous).
 
This multi-threaded solution allows us to create ONE instance of each listener and apply it to an entire class. Meaning our main thread is left unblocked and able to perform other changes to the status of the script.
Edited by GotZoped

Share this post


Link to post
Share on other sites

Example Usage:

 

In this example I will combine the things learned above and show you how to asynchronously monitor for dangerous players in the area. This could be useful in ANY situation involving the wilderness, allowing us to respond in real time to an encounter with a dangerous player.

DangerListener

public interface DangerListener {    void dangerFound(RSPlayer player);    void dangerLost(RSPlayer player);}

 

DangerObserver

/** * Created by Zope on 10/19/15. */public class DangerObserver extends Thread {	private static ArrayList < DangerListener > listeners;	private Condition condition;	private RSPlayer[] last_dangerous_players_found;	private RSPlayer[] new_dangerous_players_found;	private final long GAME_TICK = 600 / 10;	public DangerObserver(Condition condition) {		this.listeners = new ArrayList < DangerListener > ();		this.condition = condition;		last_dangerous_players_found = getDangerousPlayers();	}	@Override	public void run() {		while (Login.getLoginState() != Login.STATE.INGAME) {			General.sleep(500);		}		while (true) {			if (Login.getLoginState() != Login.STATE.INGAME) continue;			if (!condition.active()) {				// If the condition is false we want to                                 // subtract the last known dangerous players				if (last_dangerous_players_found.length > 0)                                     for (RSPlayer p: last_dangerous_players_found)				        subtractedTrigger(p);				continue;			} else {				// If the condition is true				// Update new player list				new_dangerous_players_found = getDangerousPlayers();				// Create list of removed objects by removing all of the newly 				// found players (Whatever is left are the removed players)				List < RSPlayer > removed = new LinkedList < RSPlayer > (Arrays.asList(last_dangerous_players_found));				removed.removeAll(Arrays.asList(new_dangerous_players_found));				// Create list of added objects by removing all the last				// found players (Whatever is left are the added players)				List < RSPlayer > added = new LinkedList < RSPlayer > (Arrays.asList(new_dangerous_players_found));				added.removeAll(Arrays.asList(last_dangerous_players_found));				// Add newly found players				for (RSPlayer p: added) {					addTrigger(p);				}				// Remove newly lost players				for (RSPlayer p: removed) {					subtractedTrigger(p);				}				// End of cycle, old equals new...				last_dangerous_players_found = new_dangerous_players_found;				General.sleep(GAME_TICK);			}		}	}	public static RSPlayer[] getDangerousPlayers() {		return Players.getAll(new Filter < RSPlayer > () {@Override			public boolean accept(RSPlayer rsPlayer) {				if (isPlayerDangerous(rsPlayer)) return true;				else return false;			}		});	}	public void addListener(DangerListener dangerListener) {		listeners.add(dangerListener);	}	public static void addTrigger(RSPlayer player) {		for (DangerListener l: listeners)		l.dangerFound(player);	}	public void subtractedTrigger(RSPlayer player) {		for (DangerListener l: listeners)		l.dangerLost(player);	}	public static boolean isPlayerDangerous(RSPlayer player) {		int ourCmbLevel = Player.getRSPlayer().getCombatLevel();		int theirCmbLevel = player.getCombatLevel();		if (!player.getName().equals(Player.getRSPlayer().getName())) if (playerWithinCombatRange(theirCmbLevel, ourCmbLevel)) {			// TODO: getSkullIcon native method is broken, await update / fix			// TODO: Make this check: playerIsSkulled(player)			if (!playerIsSkulled(player)) {				if (playerIsNotRunningOrbs(player)) {					addTrigger(player);					return true;				}			}		}		return false;	}	private static boolean playerWithinCombatRange(int theirCombat, int ourCombat) {		int dangerMinLevel = ourCombat - 7;		int dangerMaxLevel = ourCombat + 7;		// If the players level is within dangerous range		if (dangerMinLevel <= theirCombat && theirCombat <= dangerMaxLevel) return true;		else return false;	}	private static boolean playerIsSkulled(RSPlayer player) {		if (player.getSkullIcon() == 0) return true;		else return false;	}	private static boolean playerIsNotRunningOrbs(RSPlayer player) {		for (int i = 0; i < player.getDefinition().getEquipment().length; i++) {			RSItem wornItem = player.getDefinition().getEquipment()[i];			// Check weapon			if (wornItem.getEquipmentSlot().equals(Equipment.SLOTS.WEAPON)) if (wornItem.getDefinition().getName().toLowerCase().equals("staff of air")) {				// If it is a staff of air				return false; // We assume the player is skulled on accident or a bot that mis clicked and 'running orbs'			}		}		// If the player is NOT wielding a staff of air we know they are NOT running air orbs		return true;	}}

Created by @GotZoped with inspiration from @daxmagex.
 

DemoClass

/** * Created by Zope on 10/21/2015. */@ScriptManifest(authors = {"Zope"}, name = "DangerDemo", category = "Demo", version = 1.0, description = "Should asynchronously detect dangerous players in the area.")public class DemoClass extends Script implements DangerListener {    private ArrayList<RSPlayer> dangerousPlayers = new ArrayList<>();    private boolean firstRun = true;    // Action that occurs when a danger is found    @Override    public void dangerFound(RSPlayer player) {        if (!dangerousPlayers.contains(player)) {            println("Danger Found: " + player.getName());            dangerousPlayers.add(player);        }    }    // Action that occurs when a danger is lost    @Override    public void dangerLost(RSPlayer player) {        if (dangerousPlayers.contains(player)) {            println("Danger Lost: " + player.getName());            dangerousPlayers.remove(player);        }    }    @Override    public void run() {        // This is true on initialization        if (firstRun)            init();        while (true) {            // Print the name of every found dangerous player            sleep(250);        }    }    private void init() {        // Create instance of observer class        DangerObserver dangerObserver = new DangerObserver(new Condition() {            @Override            public boolean active() {                return true;            }        });        // Add this script as a listener for the observer        dangerObserver.addListener(this);        // Start the DangerObserver thread        dangerObserver.start();        // Set firstRun to false after this has been ran once        firstRun = false;    }}

 
 
Credit / Additional Information:
https://tribot.org/forums/topic/45600-snippet-inventory-listener/ (Information on how to declare custom listeners)

Edited by GotZoped

Share this post


Link to post
Share on other sites

Maybe you viewed the thread before I added it, but the last reserved thread is for additional information and credit.  :heart: 

Thanks a lot for the feedback though, I'm trying to write this up in between activities so I might not get around to finishing it until tonight... Stay tuned!

Share this post


Link to post
Share on other sites

Maybe you viewed the thread before I added it, but the last reserved thread is for additional information and credit.  :heart: 

Thanks a lot for the feedback though, I'm trying to write this up in between activities so I might not get around to finishing it until tonight... Stay tuned!

 

 

Sounds awesome, I would love to read it once its finished. You may need to get a mod to change the thread title though, as I don't think regular players can.

Share this post


Link to post
Share on other sites

I sent a message to two online moderators, I didn't realize that was the case.

Thanks for the tip!  :angel:

Edit: Thanks to @Mute for filling me in
In case anyone is wondering you can change your thread title by clicking on "Use Full Editor" while editing the first post...

Edited by GotZoped

Share this post


Link to post
Share on other sites

Great guide even though this is pretty old! Sorry for the gravedig but there's not really any other tutorials for this, and this works great so I assume people still use it.

For anyone using this in the future, I found a great optimization on the code. Replace the gametick sleep at the end of execute in the observer with this; 

int playerCount = Players.getAll().length;
Timing.waitCondition(() -> playerCount!=Players.getAll().length, 60000);	

That way instead of looping every 60ms it will only loop every minute or when the number of players in your area changes. My cpu usage dropped 1.5-2% while the observer is running. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Similar Content

    • By Flax
      Debian 7.0 VPS Setup Guide for TRiBot Botting. 
      By: Flax
       
      Hey guys today I'm going to show you how to setup a VPS for TRiBot botting, I'm making it because I got so many questions from people about this & most VPS guides here are pretty outdated.
      Make sure your VPS operating system is Debian 7 32 or 64bit, or else this guide will not work for you!
      Okay, let's begin.
       
      First off you'll need these programs:
      - PuTTy
      - TightVNC Viewer
      Once you've downloaded those files we can begin setting up your VPS.
       
      Step 1: Open PuTTy and enter your IP and click connect (You should keep the port 22)

       
      Step 2: Now a command prompt will pop up and it'll ask you for a username, Type ' root ' and after that it'll ask you for a password, type in the password that was given to you by your VPS provider.
       
      Step 3: Now you should enter the following commands one-by-one, it can take awhile to install depending on the speed:
      apt-get update apt-get install curl curl https://dl.dropboxusercontent.com/s/jabcbltmn5fuevx/install.sh | sh apt-get install iceweasel Step 4: After that's done you should be able to connect with the VPS through TightVNC.
      REMEMBER: MAKE SURE TO ADD :1 BEHIND THE IP.

       
      This is how it should look:
      Once connected, you can download TRiBot/OSBuddy via the Iceweasel browser(similiar to Firefox).
       
      If you're unable to open TRiBot, try this:
       
      Looking for cheap VPS deals and don't know where to look? Check out Lowendbox, FinalHosting
    • By mrcolour
      Hello!!
      I'm sure there's already a forum post for this, but I can't seem to find it.
      I'm new to botting and needed help getting everything up and running. I've logged in with the tribot client, but don't understand how to load a script that I activated on the site.
      Any help would be appreciated!
    • By we trippy mane
      Looking glass really helps prevent bans. They updated it though so it took me 3 hours to set it up this time while way back it took 10 min max. The issue was 32 vs 64 bit version's of everything. my guide if you want to start looking glass. Link looking glass with osbuddy. Get's complicated. did you download the 32 bit version of osbuddy? Also the 32 bit 102 jdk? and Are you opening tribot with jdk? also make sure you have 32bit version of java. Took few hours for me to figure this out. I had to delete literally everything and redownload everything the right way to make it work. Also fluffee's advice helped me. His thread is
      So here's 
    • By Fluffee
      Fluffee's TRiBot Account Adder v1.00 (Coded in AutoHotKey)
      I was getting sick of adding accounts manually, so I coded this in AutoHotKey. It reads account usernames, passwords, bank pins and rewards from a text file. As well as reading the world you want the account to use from a separate file (so you can loop the f2p worlds).
      To run the program, create a text file for your account formatted as follows:
      AccountUsername:Password:BankPin:Reward
      (e.g. Zezima:hacked:0000:Agility)
      You can leave out the Bank Pin and reward by just not including them, however rewards will not work without a bank pin.
      To format the worlds list, make a list as follows:
      383
      393
      394
      etc.
      I'm aware this will probably be buggy as I coded it in like 20 minutes at 1AM, but hopefully it works for some!

      To start the bot:
      Load up Fluffee's TRiBot Account Adder.exe, or .ahk whichever, insert the full path to your files (i.e. C:\Users\John\Desktop\Accounts.txt)
      Hit Start to save the paths
      Then Open TRiBot, go to the Account Manager, hit Add then hit F1 on your keyboard (F1 is the hotkey)
      Message me with any problems you have, it does work! Well it should anyways!
      NOTE: If you do not have AutoHotKey installed, download the .exe
      Hope it helps
      Virus Scan of both files:
      .exe https://www.virustotal.com/en/file/2267c37e5e2c19ab08f4bc545e3d6b8eed663d0894f2f9ecf61562f325695c54/analysis/1433995283/
      .ahk https://www.virustotal.com/en/file/6fccaa5fe5f1a7eb70396c4b65e7de1e20fd144af90fccf686fe2587be550476/analysis/1433995293/
      AHK - https://drive.google.com/open?id=0B8etMDADCUvKdFBnQnFjaXFnc1E
      EXE - https://drive.google.com/open?id=0B8etMDADCUvKdVozUE9JVjFCbzg
      Code - http://pastebin.com/H2U4cRC5
       
    • By Guki
      One of the most advantageous things you can do in programming is D.R.Y. (Don't Repeat Yourself!) 
      In our scripts, we can practice this by centralizing certain data constants within Enums, and adding in helper methods that will shorten our functioning code and create a level of abstraction that will make script maintenance a breeze.
      For this tutorial, I will just be showing a simple Item enum:
       
      public enum Items { LEATHER(1741), HARD_LEATHER(1743), GREEN_LEATHER(1745), BLUE_LEATHER(2505), RED_LEATHER(2507), BLACK_LEATHER(2509), COINS(995); private final int ID; private Items(int id) { this.ID = id; } public int getID() { return ID; } public int getNotedID() { return RSItemDefinition.get(ID).getNotedItemID(); } public RSItemDefinition getDefinition(){ return RSItemDefinition.get(ID); } }  
      This is for a Tanning script. As you can see, we name each constant by its full name to avoid naming collisions/confusion. 
      In an Item enum, the only required data is a Unique ID for each item. With this, we can create several helper functions that might be specific to the script., but the above is a good base for about any script.
       
      "Why not just use item id's and the standard API's methods you idiot? This is a waste of time..."
       
      As I said before, the above is a very introductory example, but here is a more complex application of the above idea using Interfaces.
      public enum Interfaces implements Clickable { TANNING_SOFT_LEATHER(324, 124), TANNING_BLACK_LEATHER(324, 131); private final int PARENT; private final int CHILD; private final int COMPONENT; private Interfaces(int parent, int child, int component) { this.PARENT = parent; this.CHILD = child; this.COMPONENT = component; } private Interfaces(int parent, int child) { this.PARENT = parent; this.CHILD = child; this.COMPONENT = -1; } private Interfaces(int parent) { this.PARENT = parent; this.CHILD = -1; this.COMPONENT = -1; } public int getParent() { return this.PARENT; } public int getChild() { return this.CHILD; } public int getComponent() { return this.COMPONENT; } /** * Check whether or not the interface is not null, and not hidden * * @return true if interface is open and visible, false if null, false * if hidden */ public boolean isOpen() { /* Null check Interface tree in descending order*/ if (org.tribot.api2007.Interfaces.get(PARENT) == null) { return false; } if (CHILD != -1 && org.tribot.api2007.Interfaces.get(PARENT).getChild(CHILD) == null) { return false; } if (COMPONENT != -1 && org.tribot.api2007.Interfaces.get(PARENT).getChild(CHILD).getChild(COMPONENT) == null) { return false; } /* Component.isHidden() check on Interface tree in ascending order*/ if (COMPONENT != -1) { return !org.tribot.api2007.Interfaces.get(PARENT).getChild(CHILD).getChild(COMPONENT).isHidden(); } if (CHILD != -1) { return !org.tribot.api2007.Interfaces.get(PARENT).getChild(CHILD).isHidden(); } return !org.tribot.api2007.Interfaces.get(PARENT).isHidden(); } /** * Attempts to click the interface component using the given option * * @param option the option to click on the component * @return true if we clicked the component, false otherwise */ @Override public boolean click(String[] option, Point randomness, Point offset) { if (isOpen()) { if (COMPONENT != -1) return org.tribot.api2007.Interfaces.get(PARENT).getChild(CHILD).getChild(COMPONENT).click(option, randomness, offset); if (CHILD != -1) return org.tribot.api2007.Interfaces.get(PARENT).getChild(CHILD).click(option, randomness, offset); return org.tribot.api2007.Interfaces.get(PARENT).click(option, randomness, offset); } return false; } @Override public boolean click(String... option) { return click(option, null, null); } @Override public boolean click(String option, Point randomness, Point offset) { return click(option, randomness, offset); } @Override public boolean hover() { return hover(null, null); } @Override public boolean hover(Point randomness, Point offset) { if (isOpen()) { /* Component.isHidden() check on Interface tree in ascending order*/ if (COMPONENT != -1) return !org.tribot.api2007.Interfaces.get(PARENT).getChild(CHILD).getChild(COMPONENT) .hover(randomness, offset); if (CHILD != -1) return !org.tribot.api2007.Interfaces.get(PARENT).getChild(CHILD).hover(randomness, offset); return !org.tribot.api2007.Interfaces.get(PARENT).hover(randomness, offset); } return false; } } Now as you can see this is far more useful in code.
      We can overload the constructor method of the enum to accept all types of interface components from Parent to Children, to Components. This allows us to directly path to the component we want, similar to org.tribot.api2007.Interfaces.get(int parent, int child). Also, we can implement the Clickable interface to get access to all mouse functionality commonly used within scripts, meaning we can now SAFELY click interfaces within our scripts like so:
      Constants.Interfaces.CONSTANT.click() There are other things this can be applied to such as NPCs and Objects, but I will let you code your on versions of those

      An easy way to manage all of your scripts constants (assuming it is a reasonable amount of code, under 500 lines) is to put all of your enums inside of a Constants class. This will allow you to easily manage imports and give access to all your constants with one import. 
       
      Thank you for taking the time to read this and if you have any questions, comments, concerns, flame, trihards, or otherwise feel free to reply or send me a PM and I will get back to you ASAP.
       
      -Guki
    • By MySmallBox
      Just learning to script and i want my bot to walk to Khalid bank
      this is what i got so far
      package scripts; import org.tribot.script.Script; import org.tribot.script.ScriptManifest; @ScriptManifest(authors = { "MySmallBox" }, category = "Crafting", name = "alkharid crafter") public class TinMiner extends Script { private boolean isAtBank(){ return false;} private boolean walkToBank(){ return false;} @Override public void run(){ while(true){ if(isAtBank()){ //begin crafting leather... this is for later but now i need to know how to walk to bank first }else{ walkToBank(); } sleep(50);}}} so yeah how do i walk to bank i read the api but still hopless
    • By robry
      Request:  Looking for a private tutorial island script
      Description:  Complete tutorial island with an account queue, no need to have account creation implemented (additional features can be discussed, i.e. ge walking, music mute etc.)
      Payment Amount:  Willing to pay whatever is necessary as long as the scripter's rates are within reason.
      Time:  Completed within the next 1-3 weeks.
      Additional:  Feel free to pm me please, I am available 24/7 on the TB forums, I am open to negotiations and I don't mind a higher price for a higher quality product.
      Cheers!
      E: If the script is also shared with other users I do not mind so long as it's a limited amount (TB limit is 20 iirc?).
    • By CyberSecurity
      I want to start a gold farm from scratch. I have no experience whatsoever. I want to learn how to use different proxies for each account and how to manage them all.
    • By joopedro59
      To begin with, I just wanted to make it clear that English is my second language, and I apologise for any ocasional mistakes. 
      Just making it clear, this thread is where I'm going to share with you guys my first small gold farming experience, and try to help you guys with yours and maybe you could give me some advise back. 
      There's probably  a lot of information that you already know, but i'm going to describe the whole process and the results for each method from acc creation to training and go making money. 
      By the way, I used proxies so I that i didn't get chain banned.
       
      Feel welcome to jump to the end if you don't want to know how a noob at goldfarming did on his first 4 days of experience.
       
      Starting the farm
      I invested some money on a few interesting scripts and these are the results (and process):
      (different accs created and methods to train)
       
      Detalis
      I created the e-mails and accounts.
      -The bots all looked different from the standard-looking recently created acc (a male wearing regular brow and green-like clothes)
      -The first 10 bots had different passwords, all the other ones had the same password.
      I made tutorial island myself on 4 accounts. I trained magic and hp on each of them, all without botting. I made them over 20 combat before starting to bot. Those accounts lasted 3 days, except for one that hasn't been banned so far. I have been botting on them pretty much 24/7. Those would run the best scripts, the ones supposed to give the best money/h. 
      Those accounts worked great for at least 3 days straight. 2 of them were running 1 script, and the other, another script. Just now the first one of them got banned, but it was still pretty great profit. The other two are still working. But not for long, I suppose.
      I stopped using one of them and put another one on it's place, simillar stats from the first one, when it had just started. It got banned withing hours. (I botted tutorial island on that one, trained it myself). I suppose bans from tutorial island might be delayed a few hours for them to analyze the acc.
      For the next set of accounts, 6 of them now, I used a tutorial island bot. And then I trained them on chickens with starting equipment only, botting as well. One of them was banned right away. Then I sent the others to bot, all of them doing the same thing. I also put one of the accounts I trained myself to bot with those, and it had membership. Just 1 of them made it for longer than 15 hours. I figured the script was faulty, but it was saying it had the highest anti ban possible. 
      I created 20 more accs and sent all of them to run the same script. It's a paid script by the way. None of them could really profit over 500k before getting banned. Which they all did, at once. (at least when i checked my screen, most of them were already gone)
      Detalis I should add: I sometimes was able to see people coming to me and asking if i was a bot, or someone saying "so many bots"... I simply answered "of course not" or "yes, a lot indeed" and resumed script. The 2 accs that I menaged to do it lasted a lot longer than the others and one of them is not even banned yet. 
      The one account that answered and is yet to be banned is running a script. A friend of mine ran the same script on his main, since it was working just great for me. His main had over 170 qp and he had never botted. He got permanently banned within hours. My bot is still working. I'm guessing he was reported.
      Conclusion
      Okay, I admit I was dumb by sending levels 3 to go skill and make money on free worlds expecting them not to get banned, but... Not even one of them survived. This is slow, and you gotta fail to learn.
      I can not assure that botting tutorial island the reason a few accs got banned, as any of them got banned right away. But when 20 bots that did it got banned, I start to wonder if there's a relation between things.  Also, training accounts myself seemed to make them last a lot more on the long run, even though I didn't really test it for sure, while training accounts using bots didn't seem to help at all.
      But that's a difficult thing to assure, because as answering people make accs last longer. Because that means that reports really make a difference whether the account gets or not banned (even though i'm pretty sure my 20 lvls 3 didn't get all reported). So, if a bot could train combat to... let's say, 40, 50? People wouldn't report it as it's not a shitty level 3 account. Specially if it's wearing any kind of armour.
      I know that this might be going too far, but all the bans that happened at once (or at least in a short period of time) were on accounts with the same password. I'm just saying that using different passwords wouldn't hurt anyone, since the accs were created right after each other with the same password, IDK, just expeculating. 
       
      So... What I really wanted was you guys to share what you've learned so far to save me some time and money creating accs and failing. Is it worth it to invest on a combat bot to train my accs? make them wear armour? get them quest points? Is it just luck based? do you thing reports are really important? Feel free to message me if you feel like helping someone start out. 
       
      Thanks a lot
       
    • By Fluffee
      Fluffee's Ultimate Guide to Botting: Part Four - All About Mules
      Welcome once again to Fluffee's Ultimate Guide to botting series. If you haven't already read part one or part two, please do so here ([Tutorial] Fluffee's Ultimate Guide to Botting: Part One - Account Creation and Management), here ([Tutorial] Fluffee's Ultimate Guide to Botting: Part Two - All About Proxies) or  here ([Tutorial] Fluffee's Ultimate Guide to Botting: Part Three - All About Servers ).
      --What are mules?--
      Well in the real world a mule is an animal, another name for a donkey actually. However, in the RuneScape world, a mule is a slang term for an account used to store excess gold/items. They were commonly used in the dicing days, when the hosts would RWT their gold, and they wanted to make sure they didn't lose everything should something bad happen. And as RWT bans began to rise, mules became a common tool for botters as well.
      --Why should I use a mule?--
      Mules allow you to have a safe place to keep all your botted gold, so you don't lose it when JaGeX cracks down on your bots. That way, when you wake up one day and get that dreaded account disabled message you don't have to be too worried, as all that GP your bots worked hard for is safe and secure on your favorite mule account. With the help of a mule you've managed to thwart JaGeX again, and that's always a bonus.
      --Can mules get banned?--
      The quick and short answer is yes. If you're not careful, and you're lazily just trading all of your GP from your bots to your mule JaGeX can easily track the trade history and ban your mule as well just for having contact with bots. Want proof of this? Ask dicer Fishy what happened to all his accounts when JaGeX decided they were sick of his rampant RWT. He lost all of his accounts, mules included.
      Alright, so maybe Fishy is a bit of an extreme case but it does show that yes mules can be banned, and being lazy with trading only makes that easier. Luckily for you, I have some discrete methods to help reduce the chances of JaGeX cracking down on your mules which will help you keep that precious GP safe.
      --Sidebar--
      Alrighty, before we continue I want to be perfectly clear here and I really want to avoid someone flaming the thread because "they've never had a mule banned". I'm not saying that you will be banned by directly trading gold from your bots to your mule. Heck, some people even sell gold from their mules without issue. What I am saying is that a ban is possible by directly trading your gold from your bots to your mule. These methods that I am going to show you are methods that will help reduce the ban rates, and just because you haven't revived a ban with your lazy methods does not mean you will not receive a ban. With that out of the way, let's get into this.
      --Should I level stats on my mule?--
      If you have to ask, the answer is probably yes. Let's make the assumption that JaGeX knows what everyone's bank is worth, and if that's the case (which considering they own the game, isn't a super far fetched assumption) wouldn't it be rather odd if a fresh account with absolutely no stats has tonnes of GP. That alone would make JaGeX suspicious as how would you possibly have accumulated that amount of money. Therefore, I would recommend you take some time and train up your account a little bit. You don't need any outrageous stats, just enough to make you blend in to the general population of RuneScape.
      --Should I quest on my mule?--
      Once again, if you have to ask the answer is probably yes. Again, we're looking to blend in here and most people who play RuneScape do at least a couple of quests it's just the standard practice. Quests such as Cook's Assistant, Doric's Quest and Goblin Diplomacy can be done in like 15 minutes total assuming you start with the items. As well, getting the 7 quest points (which you will from those quests) allows you to trade anything from an F2P account; which saves you membership fees.
      --How do I trade GP safely to and from my mules?--
      I think this is probably the most interesting part of the tutorial, and for many the part you're probably going to skip to. I'll be going over 4 methods in this tutorial, ranging from simple, higher risk methods to challenging low risk methods. It's up to you which method you chose, but it's nice to have options.
      Method 1: Straight Trading [Risk: High, Difficulty: Easy]
      This method is what you're probably using today, it's the quickest method to move gold from one account to another. Just login to both your bot and your mule, then right click and trade your GP over. It's fast, it's efficient, and it definitely gets the job done. However, we can only assume it provides JaGeX with an easy way to track down your mule as there will be a long log of trading history between the accounts.
      As a result of this, I wouldn't recommend this method, unless you are layering your mules. What this means is that you have all your bots trading a few mules, and then those mules trading one main mule. Even with that setup I still wouldn't advise straight trading your main mule as to me, that's just too obvious. However, it is the easiest method and you might prefer easy over safe.
      A bonus tip, if you chose to straight trade throw some junk in the trades. Hopefully this will help keep JaGeX off your back.
      Method 2: Dueling (Staking) GP [Risk: Medium, Difficulty: Medium]
      This method is rather straight forward, much like straight trading this method just involves dueling your mule to transfer the gold. It is a bit of a pain to do, as you have to walk both your accounts to the Duel Arena, but it should keep everything on the down low. If you don't want to do a lot of work, but want a bit of extra security then I advise this. Just request to duel your mule, stake all the gold/items you would like to transfer over, then have your mule kill the bot; simple as that. If you really want to save time you can have your bot just forfeit the duel however I wouldn't promote it. If you're already committed to going through the process of dueling you may as well see it through and finish the duel.
      Method 3: Falador Party Room [Risk: Medium/High, Difficulty: Medium]
      This method is actually kinda fun. Essentially, run your bots to the falador party room and have them deposit all of their items in the drop chest. Then, start the party, and on your mule run around and pop all of the balloons you can find. When the balloons pop, some will drop some of the items from the chest, quickly pick them up and keep popping! By the time the balloons are done falling, you should have all of the items!
      Now, due to the nature of the Falador Party Room there are some things you need to note.
      1. Other players can come in and start popping balloons, thus stealing all your hard earned items. So make sure you do this on a low population world.
      2. If you don't pick up the items after popping, you can lose the items.
      3. If you add more then 50k on F2P, NPC's in Falador announce that something is going on in the Party Room, so you really do need to be fast.
      4. It costs 10k to pull the lever and start the party.
      Overall, this is a fun method and surely cannot be traced. However, it's quite risky and you could have some guy come in and pop a balloon to find all your GP sitting there on the ground.
      Method 4: Grand Exchange Money Laundering [Risk: Medium, Difficulty: High]
      This method is extremely unknown. I actually attempted to google this, and found one post about it; so you're welcome TRiBot
      This method was popular back when Free Trade was removed, and RWT companies needed to move gold across multiple accounts. Essentially, what you'll be doing with this method is finding an extremely low volume item on the Grand Exchange, and then buying it on your bots for a ridiculous price, while selling it on your mule thus transferring the money from one account to another via the Grand Exchange.
      Essentially, if there's no offers for an item (I'll use a Law Rune as an example) the lowest offer regardless of the price, is the first offer to go.
      So let's say on the Grand Exchange nobody in OSRS is selling Law Runes, and I mean no one. So on your mule, after you confirm nobody's selling Law Runes, you go ahead and sell 1 Law Rune for 10M gold. As there is no other Law Runes being sold, the only sell offer in the Grand Exchange is your offer, and therefore it is at the top of the queue. Then, on your bot with the gold, buy the Law Rune for 10M gold. Again, as there's only one sell offer (the one put in by your mule) you instantly buy that one Law Rune for 10M gold, your bot now has one really expensive Law Rune and your mule has 10M gold, and the accounts never even saw each other in game; making this the best method for laundering money in RuneScape to date.
      Now, due to the nature of the Grand Exchange there's something you need to note:
      1. This can be flawless, if nobody else is buying/selling your item.
      2. Sharing items here on the thread, or with your friends is a terrible idea, as that ruins the method.
      3. You can lose your money, or atleast some of it, if someone starts selling your item while you're trading.
      And that about brings this segment of the guide to the end, to overview, we've covered what a mule is, should you use a mule, should you level/quest a mule and then how to discreetly transfer money to your mule. I hope you've enjoyed, and learned something from this lengthy guide, I apologize for the delay, but these guides really do take work.
      I do have one small question for you guys. As I've written four of these guides (with a total of somewhere around 8000 words), I'm running out of ideas. But I know you guys are not our of ideas. If there's anything you need/want to know more about, feel free to post it here or shoot me a message. And if I do chose your idea, it'll be fully credited when the guide is released!
      Thanks for reading everyone, and I hope you enjoyed another segment of Fluffee's Ultimate Guide to Botting
  • Our picks

    • Hello TRiBot,

      Today we have a significant release that has been in the works for the last month addressing several key issues, features and bugs in the backlog.

      With these changes, we are also including a new TRiBot Loader which will allow you to select any version that is released. This adds the flexibility of allowing you to revert to a previous version should an issue arise, run development only builds, view an accurate change log between versions etc. we are very proud to offer this feature and think it will add a lot more functionality down the road as we continue to release new versions.

      These changes include 80+ commits by our development team, a list of them is summarized below and also available for your viewing pleasure in the new TRiBot Loader.

      In addition, we have taken additional steps to improve as a development team by adding continuous integration and deployment into our workflow to assist in delivering timely releases such as bug fixes as well as new features on a weekly basis depending on our development cycle.
        • Thanks
        • Like
      • 39 replies
    • Over the last three weeks, I've been working on upgrading our server infrastructure. It's finally ready and is now live!

      Why?

      Increased reliability - less server errors


      Increased availability - less downtime


      Increased security - keeping us and you secure


      Increased capacity - ability to serve you better


      Increased speed - less waiting for things to load


      Faster development - server and service updates will come faster


      What are the changes?

      Move from a single AWS EC2 instance to AWS ECS (Elastic Container Service)


      Distributed computing


      Load balancing


      Git management of server files and filesystem


      Redis caching


      How?

      AWS ECS (with 10 EC2 instances)


      AWS ElastiCache (Redis)


      AWS Load Balancing


      AWS EFS (Elastic file system)


      Please bare with us as I continue to tune the server for maximum performance. Slow loading speeds may occur temporarily. I thank everyone for their patience.

      Please post on this thread if you experience any issues other than slow loading times.
        • Like
      • 51 replies
    • This update features:

      Fixed broken hooks from today's update


      Fix wilderness level with RuneLite (Thanks @Todd)


      Add support for Kotlin .class files in scripts (Thanks @wastedbro)


      Overhaul Inventory API (Thanks @wastedbro)


      Add List support for common methods


      Change method grouping to make more sense (by functionality)


      Refactor methods to utilize Java 8 streams instead of cumbersome loops




      Recognize chatbox minimization (Thanks @JoeDezzy1)


      Fix Screen#isInViewport when NPC chat is open (Thanks @JoeDezzy1)


      Fix login bot bugs (Thanks @erickho123)


      Fix hint arrow return values (Thanks @Encoded)


      Fix depositAllExcept functionality (Thanks @wastedbro)


      Change containing box interface bound and adjust for Y values (Thanks @erickho123)
        • Like
      • 151 replies
    • This release will:

      Fix prayers and world hopper API (Thanks @JoeDezzy1 and @erickho123)


      Improve banking API (Thanks @Encoded)


      Adds methods for returning and using Java Lists, rather than arrays


      Slightly randomizes some hardcoded behaviour


      Removes sleeps from waitConditions; the efficiency saving potential is negligible in these use-cases, therefore cleaner code is preferable


      Other back-end improvements





      Note: If you are using LG, please restart both the RS client and TRiBot.
        • Sad
        • Haha
        • Thanks
        • Like
      • 90 replies
    • This release will:

      Add new internal framework for capturing exceptions


      Fix issue with not selecting the last column in world hopper (Thanks @Todd)


      Add a message about pin usage in Banking#openBank (Thanks @Todd)


      Disable the firewall by default (Thanks @Todd)


      Fix handling of the welcome screen after login (Thanks @Encoded)


      Fix wrong amount bank withdrawal (Thanks @Encoded)


      Fix Screen#isInViewport


      Fix Game#isInViewport (Thanks @Encoded)


      Call onBreakEnd for ListenerManager Breaking Listeners (Thanks @Encoded)


      Fix Prayer#getPrayerPoints NumberFormatException (Thanks @JoeDezzy1)



      Note: If you are using LG, please restart both the RS client and TRiBot.
        • Thanks
        • Like
      • 28 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...