Maxi

Ok, I want to discuss this with you script writers. Basically, we have a system setup which allows you to load random events simply by putting the files in the correct folder and it will be activated once the onActivate() method returns true. For most randoms, this will work fine. For example if you get the strange box, or if you're taken to the surprise exam, you want to solve it on the spot in most cases. But what if you get the evil chicken? Then you want to specify your own way out, either to run away, either to kill it etc. So I was thinking, we need to provide you with a random management system. See, we as OSBot will provide most and eventually all randoms through the SDN. These will be written by us and, as has already been done by some, people from within our community. But what if you're at the fight caves and you get an evil chicken outside? Well obviously the easiest way to avoid the random would be to hop back into the cave again. tl;dr I want to suggest to have a library with an unique id for each random (to be documented in the API), where for each id you can subscribe your own handler to with parameters to completely override the preprogrammed random behaviour, or to extend it in such a way that your handler will perform its logic and after that the code inside the random will take over. Before I start writing an implementation for this, I want you to think about any functionality you see fit in this system that we did not come across. Discuss.

These are just pre programmed values. We can and will change it to load and save the settings, however I'm not sure if with our current list of priorities we will manage to squeeze it in for this update. But in any case, we will make sure debugs are turned off by default initially.

I'm sorry for the delay of this release. I have spend more time than initially calculated to do a couple of these updates, and today and yesterday our country was completely in party mode because of the crowning of the new king, an event I of course had to attend. I will work as hard as possible to get this release out within 2 days.

If it would be the bot, other people would have complained about this too.

That's a very unlogical thing to say. See, we need to spend money to set up a limited liability company which will effectively make our chance on existence in the long future significantly bigger, legally speaking. This is how p****bot more or less manages to stay around. However this is not a cheap investment, so please next time try to gather some important information first, before holding people back to invest in the future of OSBot.

That's caused by errors in your scripts, not OSBot.

OSBot is not open source and won't be in the foreseeable future.

That space will be used to express some more information about OSBot.

Dark background variant: http://i.imgur.com/KfGS2A5.png

Concepts / basic empty layouts: Light background: http://i.imgur.com/Rw27Hd8.png Dark background: http://i.imgur.com/KfGS2A5.png I say yes.

Will be looked into this weekend and an update for it will be pushed.

I have updated the post to link to our Store as it all works now.

Random solvers are easy to do (most of them). We are waiting for our SDN to be deployed so we can distribute them to you without you needing any updates manually.

The red overlay and blue text with the random name indicate you're in a random. It goes away after the random. The paint for the script remains visible underneath it.

We should do this once the SDN is up and running. This way they won't get leaked, otherwise there would be no point.

We obviously are a new bot and didn't base our bot on any other bot, so we're worked from grounds up. If we want to become one of the major bots out there, we will have to do so ;).

Health checking does already work. @Xavier: it's on the list ;)

Food can be used now already, it's really easy to do. You just have to write more than one line, not simply something like eat(id)

Dear community, For the end of this weekend we have planned the release of BETA v1.4.1. With the previous update of v1.3.3 we managed to greatly improve the stability, memory and cpu usage of OSBot. This update will focus on how the current API works. Features/updates you can expect: Fixed area's Completely renewed mouse movement with much higher accuracy (no miss clicking) Improvements on the walking algorithm, also support for paths Improvements on the interaction methods New/improved camera rotation methods Support for local and global area's Fix of the onActivate method from the Login random Food API functions Prayer API functions Magic API functions Anti Ban API functions and more... Stay tuned! OSBot.org

For now you can add the randoms released on the forums in your scripts folder. We ourselves are aiming to release all randoms at once through our SDN, that way no one will have to update their randoms manually. We are still waiting for the person who we outsourced the SDN to, to finish the SDN up. Once he has finished it up, we will write the security around it to protect scripts used in the SDN from being cracked, leaked and stolen. All together, this shouldn't be too long anymore.

Really must be your script this time. Run it in command line to see what output it gives.

It's due to the new hooks file that wasn't uploaded to the server. Hold on for a few minutes ;).

The server will be up in a minute.

So we've been looking as to why only some people were experiencing incredibly low FPS, and as to why in general the obfuscated bot was using so much more memory / CPU compared to the non obfuscated version. I am doing these tests on an 8 year old machine, a 32bit machine, which was experiencing the low FPS too. We have found several causes. First of all, apparently some, not all, people who run 32bit java on a 64bit machine get very low FPS. Most of these people could fix this by installing 64bit java on their machine. Second was that we upped the obfuscation to be harder on string encryption. However the additional string encryption was that severe, it multiplies the memory usage by 2 and by that also making the CPU usage higher, and in some cases also low FPS. We have decided that we will reverse this additional string encryption obfuscation. We are still unsure however on the JVM / machine related influence causing low FPS for some people. Some machines, with the same specs or even lower, run 50 FPS without a problem. A third thing I discovered is a small mistake in the state worker, the component of OSBot responsible for updating the state from the client with callbacks. I will do some tests where I'll use some different approaches to achieve the same. We will keep you updated. OSBot.org

Yes we are aware of that, one of the things we missed when doing the overhaul of the engine. Don't worry though, this should be an easy fix. @Xavier, it was probably doing that because of the new string encryption, which also caused significant memory usage. Running with the new encryption gives me 380MB, running without it between 140 and 180MB. We will remove the new encryption from 95% of the files.