Alek

That issue was fixed a while back. Are you sure it's an invalid password? Is that what it's saying?

TIL there are no auto-flagging system for bots. I think we need to move to the proven ABC method which completely prevents bans altogether.

I flat-out don't allow scripters to use .NET bracket conventions on the SDN. It's one of my triggers.

The issue: Problem: Apparently G-Sync monitors cause this tearing I know this issue effects a handful of members, so let me know for sure if this is completely accurate. Thanks to @cheifkeith69 for telling me his findings.

Too many santa hats, the tree is nice.

Botted on a fresh account, then botted at rock crabs for 15 hours. Unfortunately I think you already know why you were banned. Limit your sessions to less than 4 hours and only start botting after some period of time. That's if you really care about your account and don't want it to banned. Of course everyone wants to be insta-maxed.

Thanks. Didn't make sense for it to be in downloadable scripts section.

:doot:

I do expect Extreme Scripts to follow up and try to remedy the issues you are having; it would be very unbecoming of a Scripter 3 otherwise. Please allow him a week or two to try and catch-up (provided he is physically able to). If you are still having major issues, please contact me.

The "ban rate" is similar among all of the injection/reflection bots (without accounting for Mirror Mode/Looking Glass). Likewise, color bots vary in terms of detection. ABC "anti-ban" harps on older techniques that may have been effective in the past, but are pretty ineffective now. If it was effective, OSBot would be dead and nobody would ever be getting banned. For basics; watch where you bot, how long you bot for, and how many accounts you have running on the same ip. You should be choosing your bot based on the scripts available and features in the client.

The upper-staff at OSBot agreed that we only "tolerate" private script sales; meaning that we allow them to happen but won't get involved with any disputes. This was kind of a general understanding for a while, but I'm now forced to make clear guidelines. Please review the following: http://osbot.org/forum/topic/110929-private-script-sales-warning/ Reason being, OSBot doesn't make money on private script sales so we shouldn't be investing our resources into it. Likewise, other botting communities tax private script sales and are heavily regulated. Now since there were no clear guidance prior to posting my topic, I'll let the staff appropriately handle this individual case.

We've made this announcement in the past but it seems the rules are difficult to find. What the OSBot Staff will NOT do: 1. Provide support for breaches of contract; exceptions are detailed below. 2. Review any script code for viruses or remote shutdowns (which stop the script from working). 3. Test the script for functionality, or review any part of the code. 4. Look into cases where a private script is leaked/re-distributed. 5. Read any correspondence outside of OSBot. This includes Skype, Discord, Facebook, or any other third-party communication. OSBot Staff will disregard any dispute regarding private scripts if the scripter you've hired is NOT an official scripter (S1/S2/S3). What the OSBot Staff Will do: 1. Look at cases where a member was infected by a private script. Remember that the Staff won't review your script unless out of courtesy. Hire someone to review your code if you don't know how. 2. Look at cases where either party was clearly scammed; reviewed on case-by-case basis. -Examples: --Clear Scam: Scripter takes payment and doesn't deliver the script --Clear Scam: Scripter delivers the script and is not paid --Clear Scam: Script does not function at all, (can't complete a full cycle of the task) --Not Clear: Script performs task, but fails after X minutes --Not Clear: Agreed upon script feature is broken, but overall script works --Not Clear: Terms of Service/Agreement not met 3. Look into cases where a private script is being sold multiple times (general rule of thumb would be 3 or more sales). Overall use your best judgement and get recommendations from friends. Use the feedback system to report good and bad experiences, that's what it's there for.

Why is a private script sale in the Dispute section?

Original Story by: @DuaneCiampa

I finally got around to patching web walk teleporting. You should be able to use both normal and lunar spellbooks with various runes and staffs. I tried to not re-write everything and only fix the issue at hand, but at some point a re-write will be needed. Ensure your scripts are working on 2.4.101 before I push this as a stable release. Also travelling to Zeah through Veos should work again. Thanks! Development Build Download: http://osbot.org/devbuilds/osbot%202.4.101.jar

This is so old.

Remove the first two lines, they are doing nothing at all.

Most programmers avoid order of operations by forcing parenthesis to ensure the order is correct. Typical mistake: bool1 || bool2 && bool3 Some people might think it's evaluating (bool1 || bool2) && bool3 when it's really bool1 || (bool2 && bool3).

How is this a community discussion?

if (ore.isVisible()) { if (!myPlayer().isAnimating() && !myPlayer().isMoving()) { ore.interact("Mine"); sleep(random(2100, 3800)); mouse.moveVerySlightly(); } } else { getCamera().toEntity(ore); } Redundant code that essentially does nothing. Default InteractionEvent makes camera movements, checks for object visibility, walks, etc. You will get the exact same results (except the interaction is performed faster) if you just do: if (!myPlayer().isAnimating() && !myPlayer().isMoving()) { ore.interact("Mine"); Also look into ConditionalSleep and replace your static sleeps: sleep(random(2100, 3800)); Additionally, your "random" sleeps aren't really all that random. It's some tinfoil nooby stuff, especially the small delays: return random(210, 320); You can keep the longer sleeps deviations, but the above is kind of pointless. if (oresMined > 200 + random(20, 100) && !myPlayer().isAnimating() && !myPlayer().isMoving()) { sleep(random(3100, 3800)); worlds.hop(hopWorlds[random(0, 9)]); } Not bad, but if you are on a dead world why would you want to hop to a potentially full world?

Watch how you play, then mimic that in your script. It's a repetitive task, there's not much you can do about it. I mean you could try adding misclicks, but that's still a bit "tinfoily" and probably won't yield any different results.

Maybe next dev build, the param will be called "norender" under "allow" flag (in case you want to get your custom loaders ready).

API Docs updated

Changelog: -Added Arceuus Spellbook -Patched norandoms throwing NPE when combined with -script param -Fixed issue with one-time Worlds initialization on first hop Edit: API Docs are updated (finally)

Ive never had OOM exceptions using web walker in my scripts; but the script writer already confirmed it's unrelated to web walking whatsoever.