Jump to content
wastedbro

[Unofficial] ABC Version 3 - An ABC Extension/Replacer [Human Data]

Recommended Posts

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:

  1. 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.
  2. 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).
  3. 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).

Edited by wastedbro
  • Like 4
  • Thanks 3

Share this post


Link to post
Share on other sites

Progress

  • Reactions
    • Predictable Event Reactions (Generic)
    • Predictable Event Reactions (Specific events)
    • AFK Reactions
      • Idle Time Tracker Helper
      • Regression on Human Data
  • Timed Actions
    • Accidental Input
      • Based on RS Username
      • Fatigue Modifier
    • Prediction Chance
      • Based on RS Username
      • Fatigue Modifier
  • Banking API
    • Prediction Implementation

 

Key:

  • Complete
  • In Progress (Started)
  • Not Started
Edited by wastedbro
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
37 minutes ago, YoHoJo said:

Thanks for taking the time to put this together. 

Will be interesting to see what effects this has. 

I'm excited to get it up and running. 

Antiban definitely has many other factors, but many of them are script-specific and can't be implemented in a general utility class.

Share this post


Link to post
Share on other sites

Accidental Input will likely be last on my list, because improper implementation gives Jagex an easy way to detect the bot. And proper implement will take a long time.

 

Reactions are my priority. I'm working on a tool now for recording reaction times and predictions that we make. Once I get enough data, I'll probably calculate a regression model, which will be used for setting the parameters of my generator. The generator will take the parameters and put them through a Probability Distribution Formula and determine the reaction time.

 

It will be neato

Share this post


Link to post
Share on other sites

Added Preferred Target Calculation to the To-Do list. I believe it will be an important factor in not only increasing the anti-ban of scripts, but also the efficiency.

 

And since I can't edit my progress post because of obscure forum bugs, here is the progress:

  • Preferred Targets
    • Weighted Distance algorithm
    • Calculate Mouse Position (to see if the target is being hovered)
    • Competition Measure (with options for targets that aren't at all competitive)
    • Based on RS Username

Share this post


Link to post
Share on other sites

Here's a GIF that shows an example of how the Prediction will work with banking

Animated GIF

 

Basically, when the bank is about to be opened, I give ABCv3 an "intent". It then uses that intent to determine where the estimated area of activity will be when the bank does show up, then moves the mouse there before the bank appears.

Now, it doesn't perfectly move the mouse where it should be, because humans aren't perfect, and we suck ass at estimation. My method accounts for that, and uses "randomSD" to generate a normally distributed random point around the area we wish to use when the bank appears.

 

Here are the "Intents" that are possible:

  • DEPOSIT_ALL (shown above)
  • DEPOSIT (will move the mouse near the inventory)
  • WITHDRAW (will move the mouse somewhere around the main bank area)

The code for this is:

Banking.openBank(Intent.DEPOSIT_ALL);
Banking.depositAll();

 

 

The reactions are performed automatically, and are based on human data (loosely, for now).

Basically, there is a reaction when the player clicks the bank, and then there's a reaction after the bank actually opens. I have a smart algorithm that flawlessly executes these reactions to the millisecond, using multi-threading so that I can determine the exact time the bank opens (which I can't do while the mouse is moving during the prediction).

Edited by wastedbro
  • Like 4

Share this post


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

Cool! If nothing else, intents will give an efficiency boost, especially if you can use them in more situations than just banking.
 

Agreed. Sometimes being more efficient is more human.

In fact, that's exactly the motivation behind my Preferred Target implementation. It takes into account Reachable Distance AND Mouse position.

giphy.gif

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, BoredPanda29 said:

Is it possible for them to see every bot running always has the game in small mode, then when people actually play they bump it up to full-screen? This might be a giveaway. 

Perhaps a trend like that would spark suspicion which would lead to manually bans, though that's highly unlikely. 

 

I wouldn't worry about that at all. It's not a good indicator. 

Share this post


Link to post
Share on other sites
1 hour ago, BoredPanda29 said:

Is it possible for them to see every bot running always has the game in small mode, then when people actually play they bump it up to full-screen? This might be a giveaway. 

It's very unlikely that this is even taken into account, since they already have much more advanced and reliable trackers, that can precisely tell the difference between a human operator and a bot.

Share this post


Link to post
Share on other sites

All they need to do is take the numbers of clicks of a normal person for each xp gain and see how many clicks since the last level up this is VERY important for skills especially agility. I'm sure most of these scripts are like half the average clicks of a real person. An average amount of mistakes need to be thrown in where the person just happens to click the same thing several times, or just makes mistakes, etc... Matter of fact all they do for most bots is probably see how many clicks per XP gain per skill and see if it is within standard deviation for the mean avg for that skills XP or greater. If it's the same or greater your good. Otherwise if it is orders of magnitude lower that's a dead giveaway. It's also very easy to track as it only requires 1 int for clicks. The game probably knows how many clicks we have done since we first signed up.  Perhaps depending on how they check this you could bot from 98 to 98.9 in a long 48 hour marathon and not get caught as long as you then go do something else for a while and come back later to get 99. It's much more likely they track this instead of complex analysis of item positional clicking. 

This probably also explains why it is the easiest for them to detect agility or thieving bots since the most clicks are required. I would assume low click skills would be the hardest to detect like cooking or fletching.

Edited by BoredPanda29

Share this post


Link to post
Share on other sites
4 hours ago, BoredPanda29 said:

All they need to do is take the numbers of clicks of a normal person for each xp gain and see how many clicks since the last level up this is VERY important for skills especially agility. I'm sure most of these scripts are like half the average clicks of a real person. An average amount of mistakes need to be thrown in where the person just happens to click the same thing several times, or just makes mistakes, etc... Matter of fact all they do for most bots is probably see how many clicks per XP gain per skill and see if it is within standard deviation for the mean avg for that skills XP or greater. If it's the same or greater your good. Otherwise if it is orders of magnitude lower that's a dead giveaway. It's also very easy to track as it only requires 1 int for clicks. The game probably knows how many clicks we have done since we first signed up.  Perhaps depending on how they check this you could bot from 98 to 98.9 in a long 48 hour marathon and not get caught as long as you then go do something else for a while and come back later to get 99. It's much more likely they track this instead of complex analysis of item positional clicking. 

This probably also explains why it is the easiest for them to detect agility or thieving bots since the most clicks are required. I would assume low click skills would be the hardest to detect like cooking or fletching.

I'm sorry, but that's just... unlikely.

A more likely explanation is that there are so few actions required for agility and thieving, that the differences between a human and bot are more distinct. This may or may not include "number of clicks", but you're failing to see the big picture here. There is no "one thing that Jagex detects". It's a lot of factors, and the combination of them. 

A good way of understanding it would be to learn Statistics. Multiple Linear Regression, Machine Learning, etc, etc.

 

4 hours ago, YoHoJo said:

I'm really liking the pulsating, 3 testicaled, black penis shape you used to censor your username. Very creative.

Ah, yes, the pulsating black mutant dong censor is among the most advanced post-production techniques.

But yeah, I used Giphy to block stuff and it bugged out on me but I was like "oh well". I now block stuff before making the gif.

Share this post


Link to post
Share on other sites
34 minutes ago, Negos said:

I would love to help you get fatigue monitor data.

I have recently fallen in love with 3-ticking on Runescape lol. You want to measure that?

I will be making a data collecting script for the public to use and submit data.

I'll need a lot.

 

12 minutes ago, 08_335i said:

I have nothing but praise for you doing this. ABC is awesome, but V2 is unfortunately, very annoying in a lot of areas. Most, if not all, you covered as to needing fixed\made better.

I appreciate the support.

  • Thanks 1

Share this post


Link to post
Share on other sites

Hi everyone,

 

I'm working on a new feature that deals with how humans handle information overload. It's called doubt.

When players open the bank and start messing with items, it's much different than our bots. Humans can't analyze all those bank items in less than a second. This causes some patterns that bots don't emulate. 

 

First off, we have analyzing. Depending on what the bot needs to do with the bank, my banking reaction times will be different. Withdrawing items will cause the highest reaction times. These reactions will changed based on the number of items in the bank.

 

Second, we have doubt. Humans often move the mouse to one item, and then click another. This can be due to the player changing his/her mind, or it can be due to the natural tendency to use the mouse to focus our analysis of what we are searching through. Either way, I will be implementing this in my banking.

 

Stay tuned. 

  • Like 1
  • Thanks 1

Share this post


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

Hi everyone,

 

I'm working on a new feature that deals with how humans handle information overload. It's called doubt.

When players open the bank and start messing with items, it's much different than our bots. Humans can't analyze all those bank items in less than a second. This causes some patterns that bots don't emulate. 

 

First off, we have analyzing. Depending on what the bot needs to do with the bank, my banking reaction times will be different. Withdrawing items will cause the highest reaction times. These reactions will changed based on the number of items in the bank.

 

Second, we have doubt. Humans often move the mouse to one item, and then click another. This can be due to the player changing his/her mind, or it can be due to the natural tendency to use the mouse to focus our analysis of what we are searching through. Either way, I will be implementing this in my banking.

 

Stay tuned. 

Cant wait to see the 'doubt' feature :) . Will be following your content

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

  • 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! 
      The script is now capable of training on all monster within this map! And additional monsters in dungeons such as the stronghold of security, slayer dungeon, taverly dungeon and many more places!

      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

       ~1 Month Package~ 
      Price: $10 
       VIP is not required to run the script
       The ability to train all of combat and magic effortlessly and safely for 1 month
       Complete customer support via skype 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 Optimus
      TRiBot's #1 Script For Training Pures & Mains
      Description:
      Tri Experiment Fighter is a flawless script designed to kill Experiments in the Canafis Dungeon.
      The script was designed not just to be fast, but also to be very stable and human like. With many many people often using the script for days at a time without stopping it. Tri Experiment Fighter is one of the fastest & safest script available to train any type of account with.
       
      Experiments are one of the best monster in the game to train on for all account types because:
      They have 100 hitpoints - Which means you don't have to attack another one often.
      They have a max hit of 2 - Which means they are ideal to train on for pures.
      There are ALOT of them to train on, and the script is capable of fighting in all areas of the dungeon
      They are close to a bank - They are about a 30 second walk away from the Canafis Bank.
      Features:
      Pictures:
      Contact Info / Support:
      If you ever need help with the script, feel free to send me a pm on the forums, or add me on skype and I usually reply within a few hours. My skype is: tri.tribot
      Purchase Information / Pricing:
      Simply click the button below or search for the script on the repository

       
      Thanks for reading
    • By YoHoJo
      More Runescape Botting Guides at https://RSBotSpot.com
      Join our Runescape Botting Discord chat channel here
      Original/Updated Article here at RSBotSpot
      This guide contains affiliate links
      How to Use TRiBot Looking Glass & Bot though the Official Runescape Client
      TRiBot’s Looking Glass feature allows you to bot through the official Runescape client by hooking onto and controlling it. Looking glass also supports proxies for botting & other clients like OSBuddy.
      While there’s no evidence that TRiBot is detectable, this feature was released as a form of antiban for users worried about the potential detectability of botting clients. Botters seem to be torn 50⁄50 about the effectiveness of Looking Glass on bans, but it never hurts to have some extra protection. This guide will cover how to use TRiBot Looking Glass to bot through the official Runescape client!
      1. Install Java Development Kit (JDK)
      Download and install JDK here. I will be using 32 bit JDK 8u151.
      Java Development Kit Download
      At the time of writing, only Java 8 is supported. 2. Load Runescape & TRiBot
      Load Runescape up to the login screen, and TRiBot up to the client select screen.
      3. Start Looking Glass
      On TRiBot, click the “New Client (Looking Glass)” button.
      Hooking TRiBot to the Official Runescape Client
      4.(Optional) Set a Proxy
      If you’re using a proxy for runescape botting, now’s the time to apply it. To do this: right click the client’s tab on TRiBot, and select “Set Proxy”.
      TRiBot Looking Glass Set Proxy
      That’s it, you’re done!
      Your TRiBot client is now hooked onto the official client, and you’re ready to start botting Runescape!
      Helpful Links:
      You can find out more about TRiBot’s Looking Glass feature on it’s release thread here You can find out more about using proxies with TRiBot Looking Glass here You can find more working Java/Client version combinations reported here  More setup guides: By Einstein
      Note: Some threads are only visible to TRiBot VIP users. Our Favorite Runescape Botting Proxy Providers
      We've tested and had great results with Runescape botting proxies from:
      Blazing Proxy (Use code RSBOTSPOT to save 5% recurring!)(CHEAPEST) Virmach (Use code SAVE20 to save 20% on your first order!) Proxy Fish (Use code OSBOT20 to save 20% on your first order!) Your Private Proxy Our Other Guides:
      All About Proxies for Runescape Botting How to Create and Register Runescape Bot Accounts Through a Proxy How to Use Proxies With TRiBot How to Expand your Goldfarm with a Botting VPS How to Unlock your Runescape Bot Account
    • By Optimus
      Welcome To Tri Pest Control Pro

       
      Tri Pest Control Pro is a flawless script that plays the Pest Control minigame for you! While creating this script, my primary goal was to make a script that will play the game just as good as a human, if not better, while still remaining safe to use. And after rigorous testing from the community and myself, I believe I have succeeded in my goal. 
      Happy botting, and enjoy your void!
      Features:
        About the three different playing styles:
       
      Screenshots:

       
      Testimonials:







       
      Purchase Information:


      You can purchase the script through the repository or clicking the image below:
    • By wastedbro
      Fresh Splasher By Wastedbro
      Link: https://tribot.org/repository/script/id/2584
      Summary
      Fresh Splasher is a script that is meant for low level Splashing for Magic EXP. It does a few things:
      Buys a Cursed Goblin Staff Buys full Iron Armor Buys Runes for Wind Strike (or Fire Strike if over 13 mage) Splashing on Seagulls Stops when out of runes and money It will take into account any equipment you already have.
      Uses as much ABCv2 allowed for such a script.
       
      Requirements:
      GP (like over 50k) in your inventory  
      Warnings:
      Buys runes from Betty's shop, which can be a bit more expensive than the GE. If you want to save money, buy your runes beforehand and leave them in your inventory. Does not stop antiban threads while splashing. It still moves the mouse and stuff. It's not a big deal, though.  
      Future Improvements
      Fix those warnings ^ Add more NPC splash options. Add a GUI for stopping at a certain level and deciding what NPC to splash on  
      Link: https://tribot.org/repository/script/id/2584
      Source: https://github.com/WBScripts/FreshSplasher
       
      Happy Botting
    • By chakal
      Hello everyone,
      Im a experienced programmer and Im trying to earn money with osrs since a couple months ago...
      I have good ideas, good moneymakings methods, a very complex system of automatic account replace after ban,
      everything is beautiful except by the fact that I dont know how to make a better antiban. People commonly say "have to be human like"
      but, believe me, its human like =s.
      everything that the script make is randomized by a seed, I use abcutil, I change methods in same script after a random time and still getting bans pretty fast.

      I know antiban its very personal and noone will share your methods, but I just find one good thread about antiban here from trilez and its deprecated, there is any good habits that any of you can share? maybe I can pay for a good advice/ code, if it works... just contact me if you can help me avoiding my bans.

      If you dont mind sharing to public, just post here... certainly will help other guys like me.

      cheers
    • By IceKontroI
      Hello, everyone. Recently I've been interested in how Jagex's pattern detection works. I ran a simple easily detected script which opens the GE, buys 1 lobster at 100 GP, waits 30 seconds, then cancels the offer and closes the GE on a loop with tribot's AI antiban turned off. After a few minutes of runtime some abnormal things started happening. Most commonly my input to the game was blocked, meaning I could move my mouse around, but the game server never accepted my input, and as a result my account's actions had no effect on the game world. I've been able to semi-reliably recreate this scenario multiple times on different accounts and IP addresses. It's worth noting that players and NPCs continue their normal action while my account's been frozen, which also indicates no connection errors. The input blockage happens fairly often to the point that it's very unlikely it has anything to do with my network connection or Jagex servers. I believe this is Jagex's first line of defense against bots (or at least one of them).
      Real players will typically try to perform various actions in-game like arranging inventory, clicking on random tiles or objects, world hopping, and even restarting the client. Bots may repeatedly click the same action (big red flag) or do nothing (moderate red flag) I have no doubt that botters/scripters with more experience than me have noticed this, but this is not a thread about Jagex input blocking, it's about preventing it from happening through pattern breaking.
      Pattern breaking is centered around the imperfections and variability of the human mind and judgment. Regular player activity does form patterns to some degree, but typically it isn't as pronounced as those of bots. There are two categories of pattern breaking:
      Large scale More useful for public scripts or large farms Focuses on creating differences between accounts through account preference Different methods of performing tasks Different subsets of antibans per account Each account may be only able to use 7 out of 12 generic antibans available for the script This increases the longevity of the script by allowing less opportunities for Jagex to group accounts via similar actions Different frequencies of antibans per account Account A may perform one antiban more frequently than account B Changes in sleep and delay times per account Accounts all have different run times This is mainly for farm detection, not for public scripts Different accounts running the script in different worlds/locations if possible Unique break patterns per account Different muling cycles Small scale Focuses on preventing accounts from producing patterns through their actions Changes the order of sub-actions within a larger action when order does not matter More useful when incorporated as part of a complex script process Avoid hardcoding script processes as first A, then B, finally C Instead use fluid condition checks to see what action should be performed Then use account preference and probability to determine which of several actions it prefers over the others Action[] actions = getActions(situation); // This should perform action condition checks and return only relevant actions boolean performed = false; for (action : actions) { if (accountPrefers(action) && accountProbability(action)) { performed = performAction(action); if (performed) { break; } } } if (!performed) { performAction(action[General.random(0, action.length)]; } While this may seem excessive, this is how players decide what to do next in a sequence of events
      Antiban is a large part of pattern breaking Performing actions you don't usually do is an effective way to break patterns Misclicking can be seen as a form of antiban as it's infrequent but deviates from your normal activity Avoid randomization Randomizing everything from antibans to sub-actions within a larger action schedule may seem like an appealing idea While it's likely to work to some degree, it will make accounts on the large scale appear too similar to each other We're trying to get our accounts to operate in the grey area between a well defined pattern and no pattern at all If all accounts operate in this grey area their patterns will be loosely defined but dissimilar from each other The idea of pattern breaking shows promise, however it has many requirements. One of which is account preference which is something Tribot has some support for, but this support is limited. For example a scripter has no way of applying Tribot preference to custom made functions. The solution is to make your own preference system where the account's username and a seed value is used to derive a value from 0 to 100. Below is my own way of doing so:
      /** * Performs a probability check on the input value. Input a percentage (0 - 100). */ public boolean chance(double chance) { return General.random(0, 100) <= chance; } /** * Scales a value based on its original range so that its position in that range is in the same position in the new range. */ public double normalizeValue(double value, double oldMin, double oldMax, double newMin, double newMax) { double percentage = (value - oldMin) / (oldMax - oldMin); return newMin + percentage * (newMax - newMin); } /** * Generates a username based preference value for the given seed (0 - 100). */ public double preference(double seed) { try { String hash = Double.toString(Player.getRSPlayer().getName().hashCode() * Math.sqrt(seed)).replaceAll("[^\\d.]", "").replaceAll("\\.", ""); String int1 = Character.toString(hash.charAt(hash.length() - 1)); String int2 = Character.toString(hash.charAt(hash.length() - 2)); String int3 = Character.toString(hash.charAt(hash.length() - 3)); return normalizeValue(Double.parseDouble(int1 + int2 + "." + int3), 0, 99, 0, 100); } catch (NullPointerException e) {return 50.0;} } /** * Generates a username based preference value for the given seed, but normalized to match the provided range. */ public double preference(double seed, double min, double max) { return normalizeValue(preference(seed), 0, 100, min, max); } /** * Performs a probability check on a preference value normalized to match the given range. */ public boolean preferenceChance(double seed, double min, double max) { return chance(preference(seed, min, max)); } Hopefully I've included all the necessary functions for the above to work. If you for example wanted to test an account's preference for performing Action A over Action B, you could take the hashcode of each actions, remove all non-integer characters from each, input them into the functions above, and receive a preference for each. I recommend using custom ranges like preference(100, 15, 85), where 100 is the seed, 15 is the min chance, and 85 is the max chance. That way the preference range will always be within 15% and 85% and you won't ALWAYS or NEVER perform that action above other actions. It should also be mentioned that you shouldn't be using these preferences to determine which actions to do, only to determine which actions should be performed above other actions. All actions should be performed as long as they're part of your script.
      This post ended up being much longer than I originally wanted but it's good to get your thoughts out in writing so I'm glad I spent the time. Going forward I would appreciate a healthy discussion, please add to the thread with your comments rather than just taking up space with pointless nay saying.
    • By drazylate
      Hi,
      I just startet scripting yesterday. I'm trying to use Encoded's Task Framework. I have created a set of tasks, such as fishing, banking, and going from a to b, and they're working together nicely. Therefore, I have a set of classes - I'm not writing every piece of code in the same class, which I like.
      But now I'm finding it a bit confusing to implement ABC2 in my script, because I don't know how I should access the same instance of ABCUtil from each of my classes. Acutally, I'm not evne sure where I should start the instance. 
      If I start the instance in my main java file, then how do each and individual task (class file) get a reference to the same instance? 
       
      Thanks in advance. 
    • 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
      Screenshot(s):
       
      Setup guide:
  • Our picks

    • This release includes:

      Fix shift clicking option selecting


      Fix high paint delay settings saving


      Update prayer IDs for the quick select menu


      Remove RS3 support


      Fix hooks



      RS3 Support Removed

      The RS3 client hasn't been updated since our Old-School version of TRiBot was released, as many of you may have noticed. Keeping all of the RS3 code in the client made the client as a whole harder to maintain, larger, slower, and messier. As hardly anyone still uses the RS3 client, and since the RS3 API was hardly functioning, we made the decision to completely remove it from TRiBot.

      For the average user, this means that the client will be smaller, cleaner, and faster. Future updates will also take less work meaning there will be more frequent updates.

      If you were one of the few users still using the RS3 client, we apologize for the inconvenience. No future support for RS3 is planned. There are many other botting clients which has support for RS3, so we recommend finding an alternative if you wish to continue botting on RS3.
        • Thanks
        • Like
      • 26 replies
    • Please welcome our new developers, @JoeDezzy1, @erickho123, @Encoded, and @wastedbro.

      These members will be responsible for working on, maintaining, and improving TRiBot.

      This means that bug fixes and improvements will now come at a much faster pace! We're committed to providing users with the best botting experience possible!
        • Thanks
        • Like
      • 30 replies
    • This release includes:

      More 3rd party libraries for script writers to use


      Apache Commons Codec


      Apache Commons Collections


      Apache Commons Configuration


      Apache Commons IO


      Apache Commons Lang


      Apache Commons Math


      GSON


      Guava


      JFoenix




      Hint arrow API


      Game#getHintArrowX


      Game#getHintArrowY




      Fix player hooks including Player#getSkullIcon and Prayer#getPrayerIcon
        • Thanks
        • Like
      • 49 replies
    • This update includes:

      Fix broken hooks


      Fix login bot for the message "No reply from login server. Please wait 1 minute and try again."


      Fix bug relating to which bot tab is sent human input


      General#randomLong bug fix involving negative numbers


      Fix GE API



      Please note: There are still some issues with the login bot due to a change in the game mechanisms handling the login screen. We're working on a fix and will upload it when ready.
        • Thanks
        • Like
      • 37 replies
    • This release will:

      Fix key event handling issue


      Fix other event handling issue


      Fix RSServer hook


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


      Use proper disposal of old Graphics objects


      Reformat code


      Rearrange code


      Organize code imports


      Apply around 8000 automated code refactorings


      Make preparations for Java 9


      Fix 11 various bugs


      Add more reliable debugging support


      Fix mouseEntered/Exited event dispatching bug


      Fix minimap walking bug where it opens the map


      Fix broken hooks for today's game update
        • Thanks
        • Like
      • 100 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×