Alek

Sure, lets go with the method simply wrapping the awt events just to keep things simple. You still didn't really show anything that proved these claims: 1. "fully custom mouse implementation which clones Sony's touch screen input controls" 2. "Combined with an exact clone of OSBuddy mousekeys behavior" I'm not saying that whatever you have is "ban proof", I just want to see what you're trying to sell actually exists. What you showed was stuff I've seen from the scripters you're calling out.

1. I want you to read the title under my name. 2. Now I want you to read what you wrote in your original post, "come with a fully custom mouse implementation which clones Sony's touch screen input controls" 3. Now I want you to read the default OSBot mouse event code which we created that you have in your snippet.

Seems like your internet is working well, I'll give you 30 minutes to part out parts of the code on a private pastebin.

Ill sandbox it later, in the meantime send me at least part of the script on pastebin. Your 1B pricetag ($1000?) barely pays my rent for the month. Specifically speaking, I want to see your main class and your mouse keys implentation. Either that or Ill ban you.

Your joke was the funniest at "open-license crypto-secure custom random generator" and "exact clone of OSBuddy mousekeys behavior".

This joke thread went serious real quick.

April Fools is over, belongs in the spam section. Edit: Boy you guys on this forum are gullible and eat up any anti-ban garbage someone pulls out.

Only if botters actually read the news on the main oldschool webpage, they would know the answer to this question. Edit: For the illterate, there was a news post about a month ago stating that all auto-clickers including "AHK" are bannable. They made some exceptions for whatever OSBuddy is doing since they can already get away with murder already.

Depends on what you mean by random events. Do you mean the in-game random events only, or do you mean the login screen, welcome screen, and bank pin as well? Also face palm gave some instructions on how to enable it.

Inheritance 101: interface Animal { int getAge(); } class Dog implements Animal { int getBarks(); } class Cat implements Animal { int getWhiskers(); } Dog doggo = new Dog(); doggo.getAge(); doggo.getBarks(); Cat cate = new Cat(); cate.getWhiskers(); cate.getAge();

In C++ you would have to define the function as taking a reference, otherwise this code would behave the same (pass by value). The function would look like: static void addOneTo (int& num)

This shows you all the coding conventions for Java (from an official source): http://www.oracle.com/technetwork/java/codeconvtoc-136057.html It tells you about spacing, brackets, naming styles, etc.

Strange, OSBot "natively" reads the class files; meaning that OSBot will unpack the zip or jar files and then use ClassLoader.

Moving this to the conspiracy theory section.

Moving off to scripting help, it's not a client bug.

Just for clarification "reflection" is not "injection vs reflection", it's to allow the Java reflection library which has nothing to do with detection at all. No randoms means anything thats a random event including auto-login, breaks, bank pin, etc. Edit: Also memory is not the max memory, it's the max heap space for the jvm. Your memory limit WILL exceed the limit you put in that box. Look up "Java Xmx" for more information.

If you didn't set a conditional sleep recheck time, the docs said it was centered around 25 ms. It was actually always at 20 ms and the sleep time which you set was randomized. Sometimes the sleep times you defined would go negative, therefore not sleeping at all. It was actually an issue I discovered with low cpu + grand exchange.

Doesn't take care of scrolling or items with the exact same name but different item ids. /:

No idea what that issue was, hopefully it inadvertently got fixed.

I decided to take a look at some of the reports in the Client Bugs & Suggestions and came up with a few things. 1. @Reveance Reported an issue with gRandom not correctly generating random numbers on a normal distribution, and he was correct. Unfortunately when I went to go back and make the formula correct, it broke a lot of our API. I took the lazy approach and deprecated all the gRandom methods and re-documented the method. 2. There were a few random reports about the GrandExchange buyItem/sellItem methods not working correctly on low cpu mode. I tested it, found a few areas of concern, and made it a bit more stable. It's a lot of code and anyone who says they wrote their own "in a few minutes" is either a blatant liar, doesn't perform all the checks, or is using breakable code (such as static ids). Speaking of performing checks, there was a check to see if you already had the buy/sell interface screen open. It however didn't check to see if there was an offer. Now it does both checks; so if there is an offer already in it backs out to the main Grand Exchange interface and selects the next available box. 3. When looking through Grand Exchange API I realized we had a broken function in ConditionalSleep. Probably lived there for many years, oh well squashed for now. 4. Spaghetti witchcraft mouse methods are getting removed. The following methods are deprecated and do nothing: -moveSlightly(int sleep) -moveVerySlightly() Additionally moveRandomly(int sleep) now only calls moveRandomly() without sleeping. Want the old functionality? Call moveRandomly(); sleep(time);. 5. We also took a look at some of the failed to fetch worlds list errors, hopefully thats resolved. Best of luck, let me know how this version works for you guys!

How do we know your custom methods aren't working? Timing.waitCondition? That doesn't look like an OSBot API class.

If the positions aren't being sent to the server and you are still performing actions, then it's pretty much saying you are playing without a mouse or touch-pad (tablets).

Recently we have reversed some various parts of the client which stores flags triggered in memory regions which are protected. Depending on your operating system you can unprotect these special regions of memory and read its information, but then this triggers another event which automatically disconnects your account. The bytecode (for the technically savvy): 0: invokestatic 3: astore_1 4: getstatic 7: ldc 9: invokevirtual 12: getstatic 17: invokevirtual 20: aload_1 21: ldc 23: iconst_0 24: anewarray 27: invokevirtual 30: pop 31: aload_1 32: invokevirtual 35: astore_2 36: aload_1 37: ldc 39: iconst_0 40: anewarray 43: invokevirtual So what does all this mean and how does this affect you? Well we've found that reaction time is one of the leading causes of bans followed closely by mouse movement. Reaction time: As a player normally plays a game, their reaction time slowly decreases set by fatigue. We urge scripters to write scripts which slowly start becoming less and less responsive as the script continues. At around the 4-5 hour mark, the script should no longer run. Cutting trees, mining rocks, attacking the next monster, all should get slower. Mouse Movement: It appears that most bots use a normal distribution in their algorithms for their mouse movements while natural players use something closer to a modified poisson distribution. Every four game ticks the point of your mouse is recorded, hashed, and sent to the game servers for analysis. It takes approximately 1,000 requests to re-create your movements on the server, which is equivalent to approximately 3 hours of gameplay. From the bot client perspective we will be quickly re-writing our mousemovement event algorithms while we start to work with script writers to evaluate script detection points (such as reaction time). Thank you for your understanding and we hope to be the first client to lead the way in this new era of bot detection!a

Don't feel bad, even scripters were screwing this up for a while.

Read the ConditionalSleep documentation, your sleep won't do anything.