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

Guide to Implementing ABC2

Recommended Posts

ABC2 is the second version of TRiBot's Anti-Ban Compliance utility, whose aim is to provide scripts with a standardized anti-ban, backed by character profiles. ABC2 has been built upon statistical analysis of human playing data, making our anti-ban the most human-like on the market. Read more about the importance of modeling human playing data here: https://tribot.org/forums/topic/60719-tribot-release-9300-0-abc2/.
 
So now you must be wondering how to implement ABC2 in your script. First, I will link the main utility: https://tribot.org/doc/org/tribot/api/util/abc/ABCUtil.html. Each script should use one instance of ABCUtil, unless the script switches RuneScape accounts during runtime. Since each ABCUtil instance is tied to a single character profile for an account, the script must create a new ABCUtil instance if a new RuneScape account starts to be used throughout the runtime of the script.
 
Upon creating a new ABCUtil instance, a thread will be started which is in charge of tracking XP gains, and making the mouse enter/leave the game screen. For this reason, it is important to call ABCUtil#close when you are finished with a specific ABCUtil instance to stop the background thread from executing, and to clean-up.
 
Now, there are four types of scenarios which ABCUtil oversees:

Timed Actions
 
These are actions which are performed based on internal timers. For each timed action, simply use the should method to check if you should perform the action. If true, call the other corresponding method to perform the action. These actions should only be performed when the player isn't particularly busy at the time. Ex: If the player is woodcutting, these actions should be checked/performed while chopping down the tree.
 
Example on how to use the methods:

// Here our player is idling, so we can check/perform the timed actions.
if (this.abc_util.shouldCheckTabs())
	this.abc_util.checkTabs();

if (this.abc_util.shouldCheckXP())	
	this.abc_util.checkXP();

if (this.abc_util.shouldExamineEntity())
	this.abc_util.examineEntity();

if (this.abc_util.shouldMoveMouse())
	this.abc_util.moveMouse();

if (this.abc_util.shouldPickupMouse())
	this.abc_util.pickupMouse();

if (this.abc_util.shouldRightClick())
	this.abc_util.rightClick();

if (this.abc_util.shouldRotateCamera())
	this.abc_util.rotateCamera();

if (this.abc_util.shouldLeaveGame())
	this.abc_util.leaveGame();

Preferences
 
These are preferred ways of doing things as specified by the player's character profile. Note that the preference generated by each method isn't constant, so we should not store the returned value of the generation method. So when an area covered by ABC preferences comes up, we must call the generation method, and act upon the returned value.
 
Example: Let's say we want to open the bank using custom methods. We then use ABCUtil#generateOpenBankPreference to generate the preferred way to open the bank.

final OpenBankPreference pref = this.abc_util.generateOpenBankPreference();
switch (pref) {
 case BANKER:
  openBankBanker();
  break;

 case BOOTH:
  openBankBooth();
  break;

 default:
  throw new RuntimeException("Unhandled open bank preference.");
}

Note that Banking#openBank, GameTab#open, and web walking all take ABC preferences into account, so we don't have to worry about handling preferences if we use those methods.
 
Next Target Preference
 
ABCUtil#selectNextTarget selects the positionable entity from the given list which should be our next target.  We should store this value until we switch targets (i.e. the entity which we are interacting with), because the output of this method isn't constant. I.e. We call this method to determine which entity to interact with next, and store the returned value so we aren't constantly calling this method. We can re-call this method and re-store the returned value when we move on to a different target entity.
 
If an entity spawns which is closer than the original closest entity, then we can re-call this method to re-select the next target entity. Otherwise, we should stick with the stored value.
 
Note that when we chose an entity which is not the closest, that entity will be within a close distance to the closest, and if the entity implements Clickable07, we will check if it is clickable via Clickable07#isClickable.
 
Example:

final RSObject[] objects = getPossibleTargets();
if (objects == null || objects.length < 1) 
return;

final RSObject next_target = (RSObject) this.abc_util.selectNextTarget(objects);

Action Conditions
 
These are actions which depend on a condition generated by ABCUtil. Note that the conditions generated by each method isn't persistent, and we want a certain level of persistence for each type of action. Therefore, we must store the returned value of the methods for a certain period of time, specified below.
 
HP to Eat At
 
ABCUtil#generateEatAtHP will generate the hitpoints percentage at which we should eat at. We store the generated value and use it until we eat the next food item. At that time, we generate a new value and store it.
 
Example:

int eat_at = this.abc_util.generateEatAtHP(); // Global variable, persistent...
// Inside of a local method
if (getHPPercent() <= this.eat_at) {
 eatFood();
 this.eat_at = this.abc_util.generateEatAtHP(); // Generate a new HP percentage to eat at
}

Energy to Activate Run At
 
ABCUtil#generateRunActivation will generate the run energy at which we should activate run at. We store the generated value and use it until we turn run on. At that time, we generate a new value and store it.
 
Example:

int run_at = this.abc_util.generateRunActivation(); // Global variable, persistent...
// Inside of a local method
if (!Game.isRunOn() && Game.getRunEnergy() >= this.run_at) {
 Options.setRunOn(true);
 this.run_at = this.abc_util.generateRunActivation(); // Generate a new run energy to activate run at
}

Moving to Anticipated Location
 
When we finish interacting with our latest target/resource, there may or may not be a next target/resource available. If there is, then we simply go to that target/resource as usual and ignore this action condition. However, if there is no next target/resource currently available, then we check this action condition.
 
We check ABCUtil#shouldMoveToAnticipated immediately after we finish up with our latest target/resource. If the method returns true, we move to the location in which we anticipate our next target/resource will spawn. If it returns false, we do nothing.
 
Example:

// Here we just finished cutting a yew tree
if (!findNextTarget()) { // If we are here, then there does not exist a next target/resource yet
 if (this.abc_util.shouldMoveToAnticipated()) { // Check if we should move to the anticipated location...	
  performReactionTimeWait(); // Sleep for the generated reaction time		
  moveToAnticipated(); // Move to the anticipated location	
 }
 // Now we simply wait until a new target/resource spawns	
 // Do not keep checking if we should move to the anticipated location	
 // Only perform this check once after each target/resource becomes unavailable
}

Resource Switching Upon High Competition
 
ABCUtil#shouldSwitchResources will decide if we should switch targets/resources based on the amount of competing players. We should check this condition every 20-30 seconds, but only if we are not winning very many resources from the other competing players. This is vague because it depends on the script and individual preferences.
 
Example:

// Here we start mining a rock
long check_time = Timing.currentTimeMillis() + General.random(20000, 30000);
while (isMining()) {
 if (notWinningManyResources() && Timing.currentTimeMillis() >= check_time) { // Check if we should switch resources
  if (this.abc_util.shouldSwitchResources(getCompetitionCount()) {
    switchResources(); //Switch resources			return;
   }
   check_time = Timing.currentTimeMillis() + General.random(20000, 30000); // Generate a new check time	
  }
 }

Next Target Hovering and Menu Opening
 
ABCUtil#shouldHover will decide if we should hover the mouse over our next target. We should use this method to determine if we should hover when we start interacting with each new target entity, and we store the returned value. While interacting with our current target, if the stored value indicates we should hover our next target, then we should do so. Note that we should only employ hovering when the mouse is in the screen boundary.
 
ABCUtil#shouldOpenMenu will decide if we should open the menu for our next target. We should use this method to determine if we should hover when we start interacting with each new target entity, and we store the returned value. While interacting with our current target, if the stored value indicated we should open the menu for our next target, AND if we are hovering the mouse over the next target, then we should open the menu. Menu opening should only be performed if we are also hovering the next target. Note that we should only employ menu opening when the mouse is in the screen boundary.
 
Example:

boolean should_hover = false; // Global variable, persistent
boolean open_menu = false; // Global variable, persistent...
// Inside of a local method
if (the_object.click("Chop down")) {
 this.should_hover = this.abc_util.shouldHover();
 this.open_menu = this.abc_util.shouldOpenMenu(); // Generate other conditions for actions	handleChopping();
}
// Inside of a different local method, 
handleChoppingwhile(isChopping) {
 if (Mouse.isInBounds() && this.is_hovering) {
  hoverNextTarget();
  if (this.open_menu)
   openMenuForNextTarget();
 } // Other code
}

Reaction Times
 
ABC2's reaction time generator relies on about nine different factors, many of which must be specified by the script. There are two different ways to specify these factors: bit flags and properties.
 
With bit flags, you call ABCUtil#generateBitFlags with the necessary options, and that method will generate the bit flags. With properties, you call ABCUtil#getProperties and set the necessary properties with the returned instance of ABCProperties.
 
Generating Reaction Times
 
You must use ABC2 to generate reaction times, instead of using random sleeps. ABC2's reaction time generator was designed to be very generic, allowing it to be used for all things which require a variable response time. However, we are still in need of some human data to allow us to have it totally generic. When generating reaction times for events with a fixed, very low waiting time, the reaction times are often much higher than a human reaction time. Hence, until we collect some more data and adjust our algorithms, ABC2's reaction time generator should be used for the following circumstances:

  • Waiting in response to a condition where we had to wait a variable amount of time typically greater than a second. Examples:
    • Reacting to when our character stops fishing. The response time will be used before we move on to the next fishing spot, or before we walk to the bank.
    • Reacting to when our character stops mining. The response time will be used before we move on to the next rock, or before we walk to the bank.
    • Reacting to when our character kills our target NPC. The response time will be used before we attack our next target, or before we walk to the bank.

We currently will not use ABC2's reaction time generator for the following circumstances, until more data has been collected and we have adjusted our algorithms:

  • Waiting in response to finishing an alchemy spell (the waiting period for casting the spell is fixed, and thus not covered by ABC2 yet)
  • Waiting in response to us finishing our wait for items to be deposited to the bank after clicking the "Deposit All" button (once again, the waiting period is fixed).

These are only limited scenarios which we specified. There are obviously more scenarios than this, but I'm hoping you're able to figure it out based on the examples.
 
Now, to generate reaction times, you have the chose of two methods:

The first method uses properties, and the second uses bit flags, as discussed above.
 
For generating reaction times, there are currently four factors which must be specified by scripts:

  • Waiting Time: The amount of time we were waiting for in order to perform the action we are wanting to do now.
  • Hovering: If we were hovering over the entity we are about to click immediately prior to calling the method.
  • Menu Open: If we have the menu open for the entity we are about to click immediately prior to calling the method.
  • Under Attack: If we are under attack now, or if we were under attack while waiting.
  • Fixed Waiting: Whether the time at which we were waiting can be fixed to a number of client clock cycles or time (currently not used since we lack data for this, but this is here for the future). This will typically not be set because of the reason explained above.

Example using bit flags:

final int waiting_time = getWaitingTime();
final boolean menu_open = this.abc_util.shouldOpenMenu() && this.abc_util.shouldHover();
final boolean hovering = this.abc_util.shouldHover(); // If the condition is met, we specify the relevant flag, otherwise we set the variable to 0
// When we pass 0 into generateReactionTime as a bit flag option, it will not change anything
final long hover_option = hovering ? ABCUtil.OPTION_HOVERING : 0;
final long menu_open_option = menu_open ? ABCUtil.OPTION_MENU_OPEN : 0;
// Generate the reaction time
final int reaction_time = this.abc_util.generateReactionTime(this.abc_util.generateBitFlags(waiting_time, hover_option, menu_open_option));
// Sleep for the reaction time
try {
 this.abc_util.sleep(reaction_time);
} catch (final InterruptedException e) {

}

Example using properties:

final int waiting_time = getWaitingTime();
final boolean menu_open = this.abc_util.shouldOpenMenu() && this.abc_util.shouldHover();
final boolean hovering = this.abc_util.shouldHover();
final ABCProperties props = this.abc_util.getProperties();
props.setWaitingTime(waiting_time);
props.setHovering(hovering);
props.setMenuOpen(menu_open);
props.setUnderAttack(Combat.isUnderAttack() || wasJustUnderAttack());
props.setWaitingFixed(false);
// Generate the reaction time
final int reaction_time = this.abc_util.generateReactionTime();
// Sleep for the reaction time
try {
 this.abc_util.sleep(reaction_time);
} catch (final InterruptedException e) {

}

When using properties, remember to explicitly set all applicable options so that you don't use old data from previous uses.
 
Generating Supporting Tracker Information
 
A core factor in generating reaction times is whether or not the mouse is currently within the game screen boundary, along with other linked factors which I am keeping secret. ABCUtil's background thread will be responsible for manipulating these factors. In order for it to do so, it must know certain information about the activity being performed. We give it this information via ABCUtil#generateTrackers.
 
ABCUtil#generateTrackers generates variables for performing anti-ban while waiting for something. Specifically, variables relating to how often and when to make the mouse leave the game area. This method should be called right after clicking something which requires us to wait a variable amount of time, or a time which we have to try and count off; i.e. where we will produce a variable reaction time. This includes, but is not limited to, clicking a tree, clicking an interface which we have to wai, say, approx. 10 seconds for.
 
This method requires the script to supply two pieces of information:

  • Estimated waiting time: An estimate for the amount of time we will be waiting for, i.e. how long it takes to perform the action at hand. Example: When woodcutting, the estimated waiting time would be an estimate for how long we are going to be chopping the current tree. Typically, using the average waiting time for the specific action is a good estimate.
  • Under Attack: If we think we are going to be under attack for any of the duration of the waiting time.

Like generating reaction times, calling this method can either be done using bit flags or properties.
 
Example using bit flags:

if (successfullyClickedTree()) {
 final int est_waiting;
 if (this.chopping_count > )
  est_waiting = (int)(this.chopping_time / this.chopping_count);
 else
  est_waiting = 3000; // An arbitrary value, only used at the very beginning of the script
 this.abc_util.generateTrackers(this.abc_util.generateBitFlags(est_waiting));
 while (isChopping()) {
  if (this.abc_util.shouldLeaveGame())
   this.abc_util.shouldLeaveGame();
   // Do other things here, such as hovering and menu opening if the mouse is still in the game screen boundary	
 }
}

Example using properties:

if (successfullyClickedTree()) {
 final int est_waiting;
 if (this.chopping_count > )
  est_waiting = (int)(this.chopping_time / this.chopping_count);
 else est_waiting = 3000; // An arbitrary value, only used at the very beginning of the script	
 final ABCProperties props = this.abc_util.getProperties();
 props.setWaitingTime(est_waiting);
 props.setUnderAttack(false);
 props.setWaitingFixed(false);
 this.abc_util.generateTrackers();
 while (isChopping()) {
  if (this.abc_util.shouldLeaveGame())
   this.abc_util.shouldLeaveGame();
  // Do other things here, such as hovering and menu opening if the mouse is still in the game screen boundary	
 }
}

Now you may be wondering where exactly to call this method. Generally, you'd call this after generating a reaction time using ABC2, after we call ABCUtil#sleep for that reaction time, and after we perform the action which we are reacting to.
 
It's important to keep in mind that calling ABCUtil#generateTrackers is very important because it sets up variables which greatly affect reaction times. Also note that we should be calling ABCUtil#shouldLeaveGame and ABCUtil#leaveGame in the period after calling ABCUtil#generateTrackers, as the method is to be used in conjunction with ABCUtil#shouldLeaveGame and ABCUtil#leaveGame. If we do not ever call those two methods, or don't call them often enough, calling ABCUtil#generateTrackers would be essentially useless, and our reaction times wouldn't be the most human-like.
 
Sleeping for the Length of the Reaction Time
 
it is important to use ABCUtil#sleep to perform all of the reaction time sleeps. ABC2's background thread is in charge of making the mouse return to the game screen boundary if the mouse has been outside of the boundary for a certain period of time. Now, the times at which the background thread makes the mouse return has been pre-determined. It's possible that it makes the mouse return while we are sleeping for the duration of the reaction time. If it does this, then why do we have to continue our reaction time sleep if the mouse is moving (i.e. the player is active)? Simply put, when the mouse returns to the game screen, we should stop sleeping the duration of the reaction time because the player is active.
 
When the script calls ABCUtil#sleep, it allows the background thread to interrupt the reaction time sleep immediately after the bot makes the mouse return to the game screen. The method also prevents two mouse movements from happening at the same time, since the background thread doesn't pause the script while moving the mouse back to the game screen.
 
Calculating Anti-Ban Compliance Levels (ABCL)
 
Refer to the first list. Beside each element is an amount of points (Pts). If your script successfully implements the element, then add those points to your score. Scores are out of 100, which determine the ABCL:

  • [99, 100] Points: ABCL 10
  • [90, 99) Points: ABCL 9
  • [80, 90) Points: ABCL 8
  • [70, 80) Points: ABCL 7
  • [60, 70) Points: ABCL 6
  • [50, 60) Points: ABCL 5
  • [40, 50) Points: ABCL 4
  • [30, 40) Points: ABCL 3
  • [20, 30) Points: ABCL 2
  • [10, 20) Points: ABCL 1
  • [0, 10) Points: ABCL 0

Note: "[" is an inclusive boundary, and ")" is an exclusive boundary.
 
Conclusion
 
There you have it, the guide to implementing Anti-Ban Compliance version two. I hope I have made it clear how to implement ABC2. Make sure to read all of the documentation.
 
I am including a persistent extension of ABCUtil, which makes this utility more like the first version, and easier to use:

PersistentABCUtil.java

Edited by erickho123
Forum Software update made all lines one lined. Attempted to fix it.
  • Like 9

Share this post


Link to post
Share on other sites

@Ericho123 & @Tri could you guys please implement this to your scripts? :D

I have a feeling that if it is there they will implement it.   It would be a huge selling point if their scripts had it and others did not.  I thought exShopper and exRunecrafter were already amazing.  I cannot wait to see if after.

Share this post


Link to post
Share on other sites

When generating the reaction time, you are determining if you are hovering or if the menu is open by the values returned by the ABCUtil methods shouldHover and shouldOpenMenu, not if you actually are hovering or have the menu open. Is this intended?

I also found this confusing, and it's worth mentioning that there are many actions in Runescape that humans will spam click, or activities with very little downtime, which humans will react fairly quickly to. What is the ABC2 policy on those? As mentioned in the OP, we're supposed to hold back on implementing any ABC2 reaction time methods for those circumstances until more data is collected? Is there any risk to implementing them now as opposed to short generic random sleeps?

Edited by ineu

Share this post


Link to post
Share on other sites

I've placed the timed actions code inside of a method, antiban(), and I call this method whenever I am idling. Is this ok, because I've been watching the bot for like 30 minutes now and I have yet to see any of the antiban actions happen. Also, does it matter what order I call the timed action checks in? I'm sure it would look suspicious during behavioral analysis if a player always checks xp only before the player cursor leaves the game. Also, if I try to add a System.out.println to happen whenever an antiban action is actually happening, the bot will just spazz out with antiban and do timed actions like crazy

Edited by brainblips

Share this post


Link to post
Share on other sites

I've placed the timed actions code inside of a method, antiban(), and I call this method whenever I am idling. Is this ok, because I've been watching the bot for like 30 minutes now and I have yet to see any of the antiban actions happen. Also, does it matter what order I call the timed action checks in? I'm sure it would look suspicious during behavioral analysis if a player always checks xp only before the player cursor leaves the game. Also, if I try to add a System.out.println to happen whenever an antiban action is actually happening, the bot will just spazz out with antiban and do timed actions like crazy

I have mine print out whenever a check returns true and it does the action, and it does not spazz out. You must have missed a bracket or something.

Share this post


Link to post
Share on other sites

When generating a large reaction time (example, I had one of ~292000 ms) which allowed the bot to get automatically logged out, the Login bot kicks in and logs the bot in even though it should still be sleeping. Are we meant to disable the login bot for the reaction time? Might be worth noting to do so if the reaction time is exceedingly long.

Share this post


Link to post
Share on other sites

Is it normal If I am making tabs in my POH and the only timed action that happens while I do it is mouse leaving the game? I call abcutil.generateTrackers right before the loop of waiting for the tabs to be made begins. My code is arraged this way:

abcUtil.generateTrackers
while ([inventory contains at least one soft clay]) {
  if (abcUtil.shouldRotateCamera) {
    abcUtil.rotateCamera;
  }
  //and so on with the other timed actions
}

Am i doing sth very very wrong or is that meant to be?

Share this post


Link to post
Share on other sites

When tallying up the points to see which threshold you're at as in ABCL 0,1,2, etc. When i come across this

 

Quote

Note that Banking#openBank, GameTab#open, and web walking all take ABC preferences into account, so we don't have to worry about handling preferences if we use those methods.

If i use those Banking#openBank and Web Walking inside my script, would i just count those points aswell?

Share this post


Link to post
Share on other sites
3 hours ago, montreal176 said:

When tallying up the points to see which threshold you're at as in ABCL 0,1,2, etc. When i come across this

 

If i use those Banking#openBank and Web Walking inside my script, would i just count those points aswell?

As examples:

Banking#openBank() will use abc preferences to decide whether it should do Banking#openBankBooth() or Banking#openBankBanker(), for the booth vs the npc.

GameTab#open will use abc preferences to decide whether it clicks the tab or uses the F key shortcuts to open the tab.

So long as you use those methods for those specific actions or implement it via abc if you need to do it in a custom way, you are good.

  • Like 1

Share this post


Link to post
Share on other sites
23 minutes ago, montreal176 said:

Quick question regarding the performTimedActions Method --

I notice mine isnt checking the XP, Is there something special that i have to do to make it check the XP? The reason i ask is because i know you have to use generateTrackers() for the mouse to leave the screen.

Are you gaining xp?  That is an important factor. I also notice that it doesn't check XP very often, although I'm not watching my bots all of the time. I have definitely seen it in the debug, as my scripts print the abc2 action they are doing in the client debug.

  • 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
Sign in to follow this  

  • Similar Content

    • By Optimus
      (Formerly known as Tri AIO Combat & Magic)
      This script is an all in one combat script that can fight every monster in Runescape safely with extensive features
      Combined with a premium all in one magic trainer that can train your magic up using nearly every magic training method available! 
      Features Overview:
      AIO Combat Features:
       VIP is not required!
        10 Hour free trial on the repository 
      Complete all in one combat system that can fight every single monster in Runescape including but not limited too:
       Brutal black dragons! *NEW*
       Wyverns! *NEW*
       Everything in the stronghold of security *NEW*
       Slayer dungeons *NEW*
       Sand crabs (automatically resets aggressiveness) *NEW*
       Rock crabs (automatically resets aggressiveness) 
       Dragons
       Giants
       Goblins
       Ghouls
       Dagganoths
       Druids
       And hundreds more different monsters!
        Can bank at every bank in Runescape
        Can use all teleports
        Supports all food types
        Guthans healing
      Dwarf multicannon support
        Supports all weapons and special attacks
        Re-equips ammo and can withdraw more from the bank
        Supports all potions
        Automatically uses the Looting bag and Herb sack
        Customisable looting by Item Name, Item ID, or items worth more than x price (Automatic price lookup).
      Full prayer support
      Resets Rock crabs and Sand crabs aggro (Including 10k island).
        Safe spotting optional
      Full worldhopping system that can worldhop when many different conditions are met
      Bones to peaches support
      Herb cleaning and dropping
        ABC2 antiban with a 10/10 rating
        Telekinetic grab support
      Progressive training (Upgrade gear, switch training spots & more)
        Can bury bones
        Load & save GUI settings
        Profit calculations and xp tracking 
        Start the script from anywhere
      AND MORE!
      AIO Magic Features:
      This script isn't just an AIO combat script, it's also an All In One Magic script!
      The script can train magic using the following methods:
       
        Every single combat spell available, from air strike to ice barrage; It's all supported
        Every single curse spell available
        Stun/combo alching!
      This is the best magic xp in the game, you cast a regular combat spell or curse, quickly followed by a high level alchemy spell.
      This can earn you up to 180k magic xp/hour!
        Splashing!
        All alchemy spells
        All enchantment spells
        Superheat item
        All teleport spells
      The script can also train with the following lunar spells!
        Humidify
        Plank make
        Superglass make
        Tan leather
        Spin flax
        and More!
       
      Purchase info and script trial info:

      Packages:
      ~Free Trial~
      Price: $FREE
       Every month you're allowed a free 10 hour trial with the script, enjoy
       Complete access to all features

       ~2 week Package~ 
      Price: $5
       VIP is not required to run the script
       The ability to train all of combat and magic effortlessly and safely for 2 weeks
       Complete customer support via discord and the TRiBot forums

      To purchase the script or activate your free trial, click the image below:
      https://tribot.org/repository/script/id/651-optimus-combat-magic/

      Gallery
      Click show on the spoiler to view images of the script running
       
      FAQs
    • By Laniax
      NEW FEATURE
      Track your bots remotely in real-time, monitor chat, inventory, equipment, break & runtime, hitpoints, position and much more!
      All for free, check out the 'Script settings' tab in the GUI.



      Need help?
      Add me on Discord (fastest response): Laniax#2980
      Or PM me the forums
    • By Fluffee
      Fluffee's Tutorial Island v3
      TRiBot's best Tutorial Island Script
      • Completes Tutorial Island
      • Supports loading of bulk accounts
      • Script Argument/Queue/Client Starter support
      • JavaFX Material Design user interface
      • Tons of customization options
      • Random account profiling
      • Full ABC2 support
      • Post tutorial island tasks
      • Account Creation
      • Task based, chose the options for every account
      • Resizable mode support
      Get it here!
      GUI

      Instructions
      Script Arguments
      Script arguments must be entered as follows (with the following keys):
      file:saved_settings_file_name.json; The only argument required now is the name of the settings file to load. If the file specified does not exist, an error will be printed in the debug, and the script will show the GUI instead.
      Source
    • By gef30
      I've decided to update an old script i wrote 3 years ago, and here it is: Multi Fisher v2! Completely rewritten, with a full implementation of ABC2, Multi fisher allows you to fish anything, anywhere! 
      get it HERE
      Source code: https://github.com/frankkeuning/fisher
      Screenshot(s):
       
      Setup guide:
    • By Final Calibur
      Attention: The script has been retired. I'd like to thank everyone who supported FC scripts over the past couple of years! (See the last post for more details)
       
      FC Questing
       
      FC Questing is here for all to enjoy! This script is built on a framework which allows for easy chaining of quests, as well as new quests to be added with minimal effort. I will consistently add new quests to the script.
      Suicide Farm Edition:
      In addition to the full FC Questing script, I'm also offering a cheaper edition specifically for suicide farmers. The suicide farm edition will include the following:
      Tutorial Island Cook's Assistant Romeo & Juliet Sheep Shearer Pricing options are below.

      Features:
      Start anywhere Grand exchange support for quests that should utilize it Quest chaining Clean and detailed paint 15 quests supported and counting (GE indicates grand exchange support, GA indicates manual gathering support, SR indicates that the script will achieve skill requirements on it's own, QR indicates that the script will achieve quest point requirements on it's own)  Tutorial Island Doric's Quest GE GA Sheep Shearer GA Cook's Assistant GA Romeo & Juliet GA Rune Mysteries GA Imp Catcher GE Goblin Diplomacy GE Druidic Ritual GE Witch's Potion GE Prince Ali Rescue GE The Knight's Sword GE SR Ernest the Chicken GA The Restless Ghost GA Black Knight's Fortress GE QR Script Arguments:
      profile_name Simply type in the name of a previously saved profile, and it will be used! 7qp Romeo & Juliet Sheep Shearer Cook's Assistant all All supported quests, random order tut-ge Tutorial island Walks to GE after tutorial island tut Tutorial island Account Queue:
      FC Questing supports an account queue, meaning you can run many accounts through the script with ease. Simply create a file in the directory which is opened by the "load accts" button, and format it like so:
      username:password
      Each account must be on it's own line. The accounts will all be ran with the same settings that you have selected. If a banned / locked / invalid account is provided, it will skip over it.
      GE Support / Gathering:
      The script currently features Grand Exchange support for quests that should utilize it. Also, the script supports gathering items manually as well. Check the quest list above to see what each quest supports. Here are some things you should know:
      If supported, the script will attempt to purchase items from the GE first before gathering manually If the player doesn't have enough gold for all of the items, it will then resort to manually gathering the rest of the materials (if gathering is supported for the quest) The script will attempt to purchase items < 2,000 GP for double their market price, to try and avoid waiting. >= 2000 GP will be bought at 1.3 times their market price (this can be changed if you have suggestions) If the quest does not support manual gathering, and the GE process fails, the script will end The script will abort & resubmit any offers that don't sell instantly, for 15% higher (if the character has enough gp to do so). This helps avoid waiting around for items to sell. General Notes:
      As this is a quest script, there are a lot of moving parts. This almost ensures that bugs will pop up now and then. Please report them when they arise, provide a detailed description, and I will fix it as fast as possible.
      The script generally should be able to start in the middle of a quest, however please be aware that this may result in questionable script behavior and / or the quest not completing properly.
      Bug Reports / Suggestions / Questions:
      Please see the thread here on how to report an issue or suggestion. Direct posts on the thread or private messages will be redirected to here.
      Please join my discord channel here for other miscellaneous inquiries. This is the fastest way to contact me.
      Pricing for FC Questing (FULL):
      1 hour free trial (resets on the first of every month) $3.99 per month, 10 instances (great for the casual user) $9.99 per month, 30 instances (great for the large bot farmer) $14.99 per 6 months ($2.50 per month), 10 instances (great for the long term user) $39.99 per 6 months ($6.67 per month), 30 instances (great for the long term large bot farmer) Pricing for FC Questing Lite (TUTORIAL + 7QP):
      1 hour free trial (resets on the first of every month) $0.99 per month, 10 instances $2.49 per 3 months ($.83 cents per month), 10 instances $3.99 per 6 months ($.67 per month), 10 instances $9.99 per 6 months ($1.67 per month), 30 instances  
      Images:
       


      Time Lapse:
       
       
       
       
    • By Laniax
      Objective
      Kills level 13 Chaos Druids above ardougne for herbs(money) and combat experience.
       
      Requirements:
      - Level 46 Thieving to picklock the tower door.
       
      Need help gaining thieving levels? Check out my other script, LAN Thiever!
       

      Recommended:
      - Level 33 Agility to cross the log shortcut, otherwise we will walk over the bridge.
      - Recommended settings: loot everything above Harralanders.
       
      Features:
      Kills Chaos Druids in the tower above Ardougne and banks in the north bank of Ardougne. Advanced Antiban (ABC2) Level 10 Over 200k/hour GP depending on drops (Recommended settings: Loot everything above Harralanders) Fast combat - will hover over next druid when attacking the first (random by antiban) Intelligent right click menu over the next druid (ABC2) Will auto-detect if your agility is above level 33 and use the agility log shortcut for fast travel between bank and tower. Advanced unstuck system. Use whatever food you want. Bring how many food u want each trip. Only loots after combat. Toggles on run if we gathered some energy. Flawless through stability, even with little updates! Ability to loot any item over X value. Drops items that it looted by mistake. Notification system, get desktop alerts when someone PMs you (and much more!) Support for script arguments! You can auto-start this script without showing the GUI. See list of settings below. Settings are changeable during runtime. Screenshots:
       
      Settings Menu:

       
      Proggies:
       
      New proggies (ABC2)

      by @Gh0sty

      by @PowerGP

      by @Gh0sty

      by @danny689

      Old proggies (ABC1)

       
      How to get:

    • By zoxind
      I've written my first, I would say for now basic script for combat training. 
      One of the main reasons why I chose to use Tribot is because of abc2. But while reading the post on the tutorial on how to implement it in your own code (
      ) I didn't really understand the method(the way) on how to implement it in code. 
      Could anyone please send me a personal message with an explanation on how to implement it correctly, or write a reply here.
      It would be very nice, if you would include an actual code example of it, that would help me to understand it better.
      Thank you in advance.
    • By R0gue
      R0gue EZ Cooker
      Summary
      Start R0gue EZ Cooker from anywhere near a bank and it will get you all they way to 99 cooking without you having to lift a finger. For optimal use, start with enough cash in your bank and some Varrock Tabs and Games Necklaces. The bot will buy the necessary food and supplies as needed.
       
      Supports Travel and Buying Supplies
      The bot supports traveling to the Rogue's Den as well as the Grand Exchange to buy raw food and items to cook. Just start the bot near a bank and it will buy Varrock Tabs, Games Necklaces, and fish as needed (there are limits so you don't spend too much money at once). 
       
      Food supported
      The bot automatically checks your cooking level and will cook the necessary item until you are ready to cook a new fish. It will cook the following:
      Level 1-15: Shrimp
      Level 15-25: Trout
      Level 25-35: Salmon
      Level 35-50: Tuna
      Level 50-75: Lobster
      Level 75-80: Swordfish
      Level 80-99: Shark
       
      Jugs of Wine
      The bot also supports making Jugs of wine after cooking level 50 if the user desires. Just select the option in the GUI on bot startup. If your player is not level 50 yet, it will cook fish until your player reaches level 50 then automatically switch to wine. It will buy the necessary grapes and jugs of water as needed and will make the wines in the GE.
       
       
      Antiban
      The bot implements ABC2 methods as well as custom anti ban methods in order to prevent bans.
       
      GUI

       
       
       
      Paint
      Features a functional paint that includes the bot status as well as training method, time ran, XP gained, and XP per hour.
       
      Feedback
      Would love any feedback as this is our first script and we can make updates and changes as needed!
       
    • By wastedbro
      Elite Chopper FREE - AIO Woodcutter
      Hello Everyone!
      I'm here to bring you an exciting new script. As some of you know, I've been working on a project that I call ABCv3, which is a new form of antiban that improves upon the principles set forth by ABCv2.
      Here is the first script that implements my new experimental antiban.
       
      Repository Link: https://tribot.org/repository/script/id/2611
       
      Features:
      Best Antiban possible. ABCL 10 plus new antiban not seen in ANY OTHER SCRIPT. Yes, I'm talking about ABCv3 Task System for completely automated 1-99 [*] 20+ locations Customer location support! Fast and efficient chopping Start from ANYWHERE Auto axe upgrading (bronze to dragon) Completely Customizable Antiban Control Mouse Speed, Reaction Times, and even play around with Tribot's built-in antiban! Features in Red belong to the Premium Version of this script.
      * Task system is limited to 2 tasks for the Free Version.
      * Some preset locations such as Catherby, Gnome Stronghold, etc are only available in the Premium Version.
       
      Click Here to see the Premium Version!
       
      GUI:
       
      Happy Botting!
       
       
    • By wastedbro
      Summary
      Hello everyone, I've started a project that I hope can benefit our antiban technology. Since ABCv2, there really hasn't been much improvement in antiban. I think the concepts behind Trilez's creation are the key to staying under the heuristic radar of Jagex and prolong bot life.
      This project is an extension of the current implementation of ABCUtil, and serves to replace some functionality, and also add some.
      Since my class extends ABCUtil, you still have access to everything ABC has to offer. I'm not replacing all of it!
       
      Why?
      There are three main reasons behind this project:
      Put simply, ABCv2 is cumbersome. It's annoying to implement in most cases, and very difficult to implement correctly in a lot of cases. This mainly applies to the new addition of Reactions, which requires a lot of unnecessary input from the script. Some of the human data behind the new Reactions of ABCv2 isn't ideal. Bots should not emulate the average player, because the average player plays RS like an AFK game. That's how these reactions were recorded. We want our bot to be very efficient, but not abnormally efficient. We want our bot to be a no-life, caffeine-driven player, but still human. (Though we still want each bot to be heuristically different than other bots, but we'll get to that). There are more things to add!  
      Replacements
      Reactions
      I've already pointed out the problems with the current Reactions System. Anyone who's watched their bot wait 13 seconds between killing seagulls are likely also frustrated. 
      Not to mention, ABCv2 does not cover reactions for predictable events. 
      ABCv3 will offer a set of Reaction Types that allow the scripter to replace nearly all arbitrary sleep times with something that looks human, and takes into account RS username, mouse position, and a dynamic sleep.
      Here are some examples of Reactions that you can use in your script. Each one will use an equation that produces data that matches human data that I will collect:
      SHORT (generally around 200-600 milliseconds) MEDIUM (500-1000) LONG (1000,3000) BANK_APPEARS (used after bank screen opens. Based solely off of human data collected from people opening the bank) BANK_CLOSES (used after bank is closed) INTERFACE_APPEARS (used for non-bank interfaces) INTERFACE_CLOSES (used for non-bank interfaces)  
      Now, we must also account for AFK Reactions, which are performed after long, idling tasks, such as chopping a tree. The current implementation takes into account 9 factors. My system will take into account the majority of those factors, and some of them will be auto-detected.
      For example, ABCv2 forces you to tell it whether or not you're in combat. My reactions will determine that for you.
      Also, the Abc3Util class will now provide helper classes for keeping track of idle events so that it can take into account average idle time. It will also make it easy to keep tasks separate. ABCv2 is really only meant for generating reaction times based off of a single Idle Task. But let's say your bot chops oaks AND Willows. Those each require separate reaction generating variables. Abc3Util will allow you to easily track data for any number of events at the same time, and generate reactions based on them, with only a few lines of code.
      All of the old Reaction Methods will be Overriden and marked "Deprecated" (they will still function normally, however).
       
      Preferred Target
      ABC preferred target is annoying to implement, and sometimes doesn't make sense.
      For example, it requires you to call it for hovering the next Target, then you must store that target for when you decide to actually click something. The problem, however, is that in order for this to make sense, you must make sure that not only is the Target valid, but also that it hasn't moved or anything else has spawned or even if your mouse isn't on it.
      Also, this method only takes into account distance, which isn't a good metric, because it ignores any and all obstacles.
       
      In effect, the ABCLv2 Preferred target system is useless.
      .... but it's a good idea.
      I'm going to replace this by calculating many of the above variables I mentioned inside the API. Therefore, instead of calling the method when going to hover and storing the result, you can just call it whenever. It will be a more expensive call, but it will take into account Mouse Position, Weighted Distance to targets, Competition, and it will be adjusted to allow for human-like decisions, which include not always picking the absolute most optimal targets.
       
      New Features
      Timed Action - Accidental Input
      Performing actions in a human way is important, but our input in general must also look human. Even though our actions are performed at human times, they still all have a purpose. Hell, even most of the times actions have specific purposes. How many times have we accidentally pressed a key on the keyboard while playing a video game? A lot.
      This action in meant to be performed while the game screen is focused, and it simply presses 1 or more keys on the keyboard. It works the same as all timed actions, except the "should" method will rarely return true when the mouse is on screen (though it's possible, to avoid heuristic detection).
      The method will also return different results (over time) based on the RS account username (like normal ABC). This method will also be affected by fatigue. Basically speaking, the longer the script running, the more likely these accidents (although they will still be rare). 
      Predictive Inputs
      Now that we have human reactions, we must explore how humans have compensated for our slow nervous system! The answer is predicting the future. It's not hard. When we click the banker, we expect the bank screen to appear. Our reaction may be slow, but we compensate by moving our mouse near where we think the deposit button will appear.
      My API will simply provide a "shouldPredict()" method, which will return true most of the time, but the actual calculation will be complex. The implementation will be up to the scripter, except for APIs that I package with this project (for example, I might offer a Banking extension that uses this).
      The method will also return different results (over time) based on the RS account username (like normal ABC). This method will also be affected by fatigue. Simply put, the longer the script time, the fewer predictions (although it will normally still be true). 
       
       
      Improvements
      Easier Implementation
      Singleton
      In ABCv2, you must get a new instance of the class and use it in all of your code, until a new RS account logs in. That's not necessary, and really annoying if you have a lot of source files.
      My implementation stores an instance of itself in a thread-local variable (works with tabs, but can only be retrieved on the main thread).
      Here's how you use it now:
      Abc3Util.instance().shouldHover(); You're of course welcome to store the result of "instance()" in your script for easier use, but now you don't have to pass it to all of your objects if you don't want to.
       
      Timed Actions
      In ABCv2, you must do something like "if(shouldDoX) { doX(); }" for each action. You probably have a method that goes through each action and performs it if needed. My implementation has a built in method for that. As a bonus, it randomizes the order in which it checks and performs the actions. By doing so avoids certain behavioral patterns. Even though checking your stats and moving the mouse are humanized behaviors, always performing them in the same order can be dangerous, even if it doesn't happen often.
      Abc3Util.instance().performTimedActions();  
      Release Schedule
      I have not yet decided if I will release this publicly. If it ends up truly helping with banrates, it will be a very valuable tool. I don't want to sound greedy, but I might have to charge for this (maybe offer it to Patreon subscribers?).
       
      How You Can Help?
      I will be asking for private Beta Testers eventually. I will need human data. But the human data I collect will be much more controlled than what Trilez collected in order to produce the results I want. Remember, we want to be human, but an efficient human.
      If I had enough developer support, I would consider allowing this to be open-sourced for contributions.
       
      Other than that, I have no way you can help other that be loyal to Tribot and spread the word. I may eventually have a Patreon where you can subscribe for certain benefits and I will put the money towards things that will speed this development along. Let me know if you'd be behind that.
       
      Credits
      Shotdox - For providing a base set of calculation methods for generating distributions (jogged my statistics memories) TRiLez - For inventing ABC and showing that human data is important. If we want to fight against heuristics, we need to implement heuristics of our own!  
      If you have any question, feel free to post below, or contact me on Discord (wastedbro#9955).
  • Our picks

    • This release will:

      Fix LG for both OSBuddy and RuneLite


      Fix issue where the resizable client isn't able to be made smaller (Thanks @JoeDezzy1)


      Fix detection of the logout game tab when resizable mode and side panels are enabled (Thanks @JoeDezzy1)


      Add initial support for Sentry to allow us to identify and easily debug exceptions happening with all TRiBot users


      Add methods to determine if the bank is actually loaded, and not just the overarching interface (Thanks @wastedbro)



      Upcoming updates:

      Improved CLI support


      Full Sentry support


      Much more
        • Like
      • 46 replies
    • This release will:

      Fix NPE in Camera API (Thanks @wastedbro)


      Update deposit box interface ids (Thanks @Encoded)


      Add various bank methods (Thanks @wastedbro)


      Banking#getWithdrawXQuantity


      Banking#getDefaultWithdrawQuantity


      Banking#arePlaceholdersOn




      Fix resizeable minimap bug (Thanks @wastedbro)


      Remove Java 8 requirement


      Please note: TRiBot is not yet fully compatible with Java 10+




      Fix the break handler issues by ensuring the break handler thread never gets paused


      Fix broken settings hooks



      Upcoming updates:

      Improved CLI support


      Much more



      Note: If you are using LG, please restart both the RS client and TRiBot
        • Like
      • 68 replies
    • This release will:

      Add support for using custom F key bindings to switch between game tabs (Thanks @erickho123)


      Fix tab opening for "Skills" and "Kourend Tasks" (Thanks @erickho123)



      Note: If you are using LG, please restart both the RS client and TRiBot
        • Like
      • 34 replies
    • This release will:

      Fix an issue where breaks would stop firing


      Fix Combat#getWildernessLevel, use dynamic search for text and cache ID for later calls


      Fix an NPE in the Combat API


      Fix Mouse#leaveGame bug where the mouse wouldn't actually leave the game screen
        • Like
      • 21 replies
    • This release will:

      Add LG support for Runelite


      Fix NPCChat issues


      Fix a bug where the camera angle setter would just hold down a key for 5 seconds (the timeout)


      Slightly adjust the rotation via keys to be more accurate


      Add the ability for asynchronous camera movement via keys


      Make Camera rotation via mouse more fluid, with more antiban, and work much better in resizable mode


      Add a "Camera#setCamera" method, allowing the rotation and angle to be set in parallel


      Increase the likelihood of using the mouse for camera movements


      Add support for adjusting the camera to positionable entities (Positionable#adjustCameraTo)



      Upcoming updates:

      Improved CLI support


      Much more



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

    No registered users viewing this page.

×