1. A description of the suggestion

Bot#isInjection() - detect if the current bot is running via injection.

Bot#isMirror() - detect if the current bot is running via mirror mode (basicaly !isInjection())

Bot#runningScriptLocal() - detect if the currently ran script is being ran locally (could expand to via auth too?)

2. How will this suggestion impact scripters and/or botters?

Bot#isInjection()/isMirror() - Better script statistics for scripters (provided they collect that sort of data), improve antiban/antipattern accordingly (see q. 3), can internally be used to avoid mouse scrolling/tab/other special keys in mirror mode

Bot#runningScriptLocal() - Can be used to be more verbose for scripters.

3. Post any examples such as code or pictures to supplement your description (optional)

//Simulate OSBuddy stat checking
if (getBot().isInjection()) {
    getMouse().move(1000, 100); //Offscreen roughly where the exp tab would be (if current mouse api supports this ofc)
}
else {
    getTabs().open(Tab.SKILLS);
}

//Avoid use of tab/other special keys in mirror
if (getBot().isMirror()) {
    //Don't use mouse scrolling, interact with widgets
}
else {
    //Mouse scroll
}

if (getBot().runningScriptLocal()) {
    log("This is my super verbose log message. Here I can expose all of my exceptions and methods without anyone seeing unless they locally run the jar!");
}
else {
    log("Something bad happened, man! Tell the scripter :D");
}

if (getBot().runningScriptLocal() && !(insert osbot username here).equalsIgnoreCase("bobrocket")) {
    log("Stop hacking my script n00b!");
    stop(false);
}

org.osbot.rs07.api.util.Utilities

 

I'm going to be moving those methods around say pay close attention to deprecation; I will be letting scripters know when that happens.

org.osbot.rs07.api.util.Utilities

 

I'm going to be moving those methods around say pay close attention to deprecation; I will be letting scripters know when that happens.

 

Didn't see the methods there, sorry!

What about Bot#runningScriptLocal() though? Would be much better than declaring a "debug" global which you could easily forget to toggle with each release build.

 

On a side note (unrelated to the suggestion itself but one of the snippets I posted), is it possible to move the virtual mouse off of the game screen (eg (1000, 100))? I noticed that when it goes offscreen, no matter what, it will then move from (-1, -1) which could really give a lot of patterns away (see below; forgive the poor drawings) - when you move your mouse off the window and then back into the window, you aren't going to constantly have it from (-1, -1).

I would love to se

 

isAuth()

 

apa

if (!getAuthor().equals(client.getUsername())) {

log("Shiiiiiiiiiiiiiiiiiiiiiiiiiet");

stop();

}

Didn't see the methods there, sorry!

What about Bot#runningScriptLocal() though? Would be much better than declaring a "debug" global which you could easily forget to toggle with each release build.

 

On a side note (unrelated to the suggestion itself but one of the snippets I posted), is it possible to move the virtual mouse off of the game screen (eg (1000, 100))? I noticed that when it goes offscreen, no matter what, it will then move from (-1, -1) which could really give a lot of patterns away (see below; forgive the poor drawings) - when you move your mouse off the window and then back into the window, you aren't going to constantly have it from (-1, -1).

pretty sure that is just a visual thing moving to -1, -1, the game does not actually know the mouse is on the screen afaik

Didn't see the methods there, sorry!

What about Bot#runningScriptLocal() though? Would be much better than declaring a "debug" global which you could easily forget to toggle with each release build.

 

On a side note (unrelated to the suggestion itself but one of the snippets I posted), is it possible to move the virtual mouse off of the game screen (eg (1000, 100))? I noticed that when it goes offscreen, no matter what, it will then move from (-1, -1) which could really give a lot of patterns away (see below; forgive the poor drawings) - when you move your mouse off the window and then back into the window, you aren't going to constantly have it from (-1, -1).

 

The client doesn't send mouse movements to the server, the only thing they receive are the mouse clicks. You could use the Mouse 'hop' method as the only form of moving the mouse and they still wouldn't detect it. I have no idea who or why implemented 'random mouse splines' into bots.

The client doesn't send mouse movements to the server, the only thing they receive are the mouse clicks. You could use the Mouse 'hop' method as the only form of moving the mouse and they still wouldn't detect it. I have no idea who or why implemented 'random mouse splines' into bots.

 

Even if the client doesn't send the movements to the server, there's still a chance that the client is actually looking at mouse movements, right? I have no idea, you're obviously much more knowledgeable in this than I am, but surely they could have something that would check the mouse x/y and then graph it, and potentially get a line of best fit and then compare it to other users? There's also some algorithm that can estimate the time taken to move your mouse from point A to point B, they could use that too perhaps?

Like I said, I know nothing on the topic, I just figured that the mouse always being at (-1, -1) could cause some problems.

We already know/handled mouse entering and leaving the screen, don't worry about it. Also, I believe I answered your initial question.