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 2

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

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 2

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


  • Recently Browsing   0 members

    No registered users viewing this page.

×