Maxi

It's definitely something they might look at if you bot at night. But they won't use that to ban you by itself, but I can imagine it definitely ticks a box somewhere.

We will be starting a reality series on it soon, VIP only.

Dear community, We wish you all the best in 2015, may it be a year full of beautiful moments, cheering and laughing. I want to shout out thanks to our staff for all the hard work they have done last year and we will dive in to 2015 with a couple of nice updates planned. I want to give a special shout to @Zach, @Maldesto and @Alek for their loyalty and commitment. Thank you guys! Sincerely, Maxi and the OSBot team

@Alek is doing a great job indeed. With @MGI on board, we will also see a lot of stuff going to happen in the way the bot works on the injection level. Great effort guys .

Firstie

Dear community, Today we have experienced DNS amplification attack, a kind of DDOS attack. Because we were on CloudFlare's plan for the last couple of weeks, CloudFlare got overrun by the traffic and re-routed traffic and our SSL certificate expired. The forums were directly routed to one of our reverse proxies again, instead of being behind CloudFlare, it caused a warning on most browsers that the website was no longer secure. The bot also suffered from the absence of the SSL certificate, rendering the bot to a non working state. Zach immediately warned me and we tried to solve the issues as fast as possible. Everything should be back to normal. We apologise for the inconvenience and wish you a happy botting continuation. Sincerely, Maxi and Zach

The time spent on that project, will remain spent on that project. I, nor anyone, can reverse that. His focus will be with the '07 client and might shift in time to other projects. The '07 client needs priority right now. That is a question you will have to ask him.

Sometimes things change, unfortunately.

Yes.

MGI has not been developing on the oldschool client previously.

Dear community, As of last month there have been a couple of issues arising with @Laz. For his and our own privacy I can't tell much about it, but I'm informing you that he has been removed from the development team. We want to thank him for all his work done and hopefully we can work out everything in a nice manner with him. Although I've moved from development to managing on the top level, I've been keeping in close contact with both @Zach and @Alek. Despite the unfortunate circumstances with @Laz, it was my responsibility to find someone to replace him. With that said, I'd like to introduce @MGI as our newest lead developer. @MGI (also known as Mangis and mgi125) will be working alongside @Alek to improve on the bot. @MGI has a big history in RS related projects and his knowledge of programming is very special. We hope to announce the plans that @Zach, @Alek, and @MGI will be working on once they are ready for release. To finish my post, I would like to thank @Zach, @Maldesto, @Alek and all the other staff members for their hard work over the past time. Sincerely, Maxi

Dear community, To show how the auto updater works for who has downloaded 2.2.11, here we go. Also the following things have been patched in this update: Bank.withdraw(#) with x amounts has been fixed to return proper values at all times Prayer.set(#) has been patched ItemContainer.contains(#) has been patched to accept multiple filters I have also made some updates to the tracker here: http://osbot.org/forum/tracker/project-3-osbot-2/ My current situation has improved so I'll be able to devote some time again on fixing issues with OSBot, so please keep using the tracker and I'll have a look at the issues. You can find the download to v2.2.12 here: http://osbot.org if you didn't get a chance to download v2.2.11 which contains the auto updater. Sincerely, Maxi & the OSBot team

The other issues will be worked at in the coming week.

Dear community, This update consists out of two parts: API updates AutoUp, OSBot's client auto updater The following API updates are added: Fixed NPE in the walking event @author Swizzbeat Fixed Tab.isDisabled() @author Xerion Fixed DepositBox.depositAllExcept() @author Swizzbeat Added ExperienceTracker.getElapsed() @author Swizzbeat Deprecated activateAutoRetaliate(boolean) @author Alek Deprecated setSpecialAttack(boolean) @author Alek Added toggleAutoRetaliate(boolean) @author Alek Added toggleSpecialAttack(boolean) @author Alek Added getFighting() @author Alek Added isFighting() @author Alek Added areRoofsEnabled() @author Alek Added toggleRoofs(boolean) @author Alek Added getBrightness() @author Alek Updated openHouseOptions @author Alek Updated setHouseBuildingMode @author Alek Added Area.getPositions() @author Alek Fixed Bank & Inventory depositAllExcept() methods @author Swizzbeat Fixed canReach() @author Swizzbeat BeeKeeper most ID's fixed @author ytao Extended Dialogues class @author Swizzbeat The OSBot client auto updater has been added in this release. On the release of v2.2.12 you will be able to download the new client and launch it with zero effort. The information of the client auto updater can be found here: http://osbot.org/forum/topic/58559-autoup-automatic-client-updates/ The planned addition of a system where certain API developers will be able to upload API updates through a web interface that get automatically released to the public is not yet started development yet. This will follow shortly. Sincerely, Maxi & the OSBot team

Dear community, We introduce to you AutoUp: a tool that will automatically detect new client updates and notify you to automatically update with zero effort. The tool runs in the background of OSBot 2. Once it detects a newer client version on our server, for example you are running OSBot 2.2.9 and OSBot 2.2.10 has just been released, it will prompt you. You can modify its settings to always automatically update or to only notify you. In the latter case you will have to click a button to update and relaunch. The old jar file will be moved in to the 'old_osbot_jars' directory in the directory of where the initial OSBot jar is and the new jar will take its place. This tool will be in place tomorrow. Another tool we will be developing is a web interface module where certain API developers can upload new clients with API updates without the intervention of one of the Core Bot developers. This means that the randoms events and other parts of the API can be updated more frequently without delays while the Core Bot developers can continue working on updates behind the scenes. This means the API developers get more freedom and power to support the development of OSBot. Some pictures of AutoUp: Tomorrow AutoUp will be released together with the latest API fixes and updates. Sincerely, Maxi & the OSBot team

Generally speaking, yes. There is always a chance of course that an update contains such dramatic client changes that a new OSBot client will have to be made and released but this is not the case usually.

Dear community, I introduce to you: HookCroon, a utility in place that will automatically update the hooks on the server once OSRS updates. Every minute the host list of online worlds is downloaded and then one of those servers is polled for the current revision. If it recognizes an update of OSRS it computes the new hooks. The server reloads its hooks every minute, so in total the entire process of updating the hooks will take around 3 minutes maximum. In order to load the new hooks you will have to close down your OSBot application and restart it. This is how HookCron looks like when running: [2014/08/05 03:13:49] New revision detected: 56 | old revision: 55 [2014/08/05 03:13:49] Starting to update hooks... Grabbing client configuration... Downloading client... Loading application... Loaded 203 classes! Applying visitor : DummyMethodDeobfuscation DONE! Detected 2695 dummy methods! Saving application... DONE! Loading application... Loaded 203 classes! Applying visitor : RevisionIdentifier DONE! Applying visitor : HandlerDeobfuscation DONE! Applying visitor : MonitorDeobfuscation DONE! The client revision is : 56 ..... Identified hooks for revision 56 : ------------------------------------------------------------------------ ** magic happens here ** ------------------------------------------------------------------------ Failed to hook the following hooks... END! Saving hooks...DONE! Saving deob....DONE! Loading application... Loaded 203 classes! Applying visitor : ClassNameDeobfuscator DONE! Deobfuscated 176 class names and identified27 classes! Applying visitor : FieldNameDeobfuscator DONE! Refactored 2754 fields! Applying visitor : MethodNameDeobfuscator DONE! Refactored 1021 methods! Saving application... DONE! [2014/08/05 03:14:44] Hooks successfully updated... [2014/08/05 03:14:44] Going to sleep for 60 seconds... [2014/08/05 03:15:45] No update required... [2014/08/05 03:15:45] Going to sleep for 60 seconds... Enjoy! Sincerely, Maxi & the OSBot team.

Dear community, Over the last couple of days a lot of work has been done towards the final and stable release of OSBot 2. Yesterday I worked on adding some new hooks for OSBot 2 and today Laz updated the hooks file on the server. We forgot that this new hook would break OSBot 1. This release contains the patch for the "black screens". Download can be found here: http://www.osbot.org Sincerely, Maxi & the OSBot team P.S. If you wondered what hooks for OSBot 2 this was about, it were the hooks required for correct ground item on objects model heights:

Dear community, This release contains the fixes to be able to start a script when your character is logged out for scripts that access your equipment information. It should no longer throw errors and will also make script writers aware of the fact that accessing equipment information when logged out is not possible. Download can be found here: http://osbot.org Sincerely, Maxi & the OSBot staff

You can have injection without reflection. You can have reflection without injection. Neither one depend on each other, you can also use both. Reflection: 'reflects' the value of fields, or better said inspects. It's a resource intens system and has its limitations for bots however you can perfectly fine use it to create one, OSBot used it in its early days. It is useful to inspect the state of a program and is more accessible for programmers to use and understand than injection. Injection: 'injects' code, for example getter methods to return value of fields. This behaves as normal code but is done on bytecode level. Getting a field value with injection through an injected getter is faster than with reflection. But it's not limited to injecting getters, one can inject other logic, for example event dispatchers, which makes it a very strong tool.

Dear community, In these two release you will find the following fixes that apply to both versions: The equipment system has undergone further changes. The system will no longer require to open the interface tab for all slots except ring and arrow. Furthermore the system now forces the cache to be updated for ring and arrow slots if information about those slots is required by opening the tab. If in any case the tab can not be opened, for example you are in the bank, the client will notify the user with a log warning which tells them to contact the script writer and ask them to update their script to avoid situations where they check their arrow or ring slot with an open interface (like banking). The world hopper has been fixed to account for the new worlds / world layout. One important notice towards script developers is that the equipment methods to equip items will now return their boolean based on whether the interaction with the item was successful or not and no longer force the client to check whether the item is actually equipped. In practice this won't make much difference, except that if the client is required to double check whether rings or arrows were actually equipped if the interaction went successful it requires to open the tab which a human wouldn't. The download for OSBot 2.1.9 can be found here: http://osbot.org/osbot2_beta/OSBot-packed-2.1.9.jar The download for OSBot 1.8.13 can be found here: http://osbot.org/get/index.php Sincerely, Maxi

The RS client has an update cycle that is called approximately every 600ms. In this update cycle, the RS server tells the client about movement, appearance, things like hit splats etc. The appearance update block is sent by the server when a change of appearance is indicated by actions on the client, for example when you equip or unequip an item that changes the physical appearance of your character. As rings and arrows do not change your physical appearance, this update block isn't called for changes to those two slots. What I've done is injected a call from this appearance update block that will cache the information of the remaining slots (all slots except arrows and rings). To cache the information of rings and arrows the client is required to open the equipment tab as the RS server now only sends updated information of the interface when the interface is open. There will be an additional fix for those but I'm still debating on what solution I will use for those.

It does once the information has been loaded once before, in other words if the tab has been open once before checking your equipment with an open interface will work. It now uses a caching system and a callback that updates on appearance updates. I have updated the main post with more information on the equipment system.

I will. I haven't had the chance to be on since the last time I checked the tracker, I'll check the tracker again tomorrow once I got some rest. I've noted this and I'll review the issue.

Dear community, OSBot 1.8.12 and 2.1.8 were released that both contain fixes for running & equipment. OSBot 2.1.8 download can be found here: http://osbot.org/osbot2_beta/OSBot-packed-2.1.8.jar Edit: I wanted to edit in some more information on the equipment update. The new system in place uses a caching system combined with a callback that updates the equipment cache on the appearance update (which happens when your player changes appearance, in other words when you change equipment except for your ring or arrow slot). The system has a cached item for everything except the ring and the arrow slot when a script is started. Once the system has had the chance to open the equipment tab once while running a script it will have the opportunity to load the ring and arrow information as well. To make sure the data of the item container is thrustworthy, the equipment system requires you to open the equipment tab once to obtain the ring and arrow data to be stored in the cache. If this didn't happen and a script is checking equipment while having a bank interface (or any other main screen interface) open, the equipment tab can't be opened and the script won't have access to the equipment data. This will require some scripters to change some of the logic in their scripts. At this point this should fix many current script. Whoever need to update their scripts please do so. In due time, when I've given other issues attention that are of high priority, I'll change the nature of the item container for equipment to separate checks on the cache instead of requiring the full cache first. This means that if you require a check on the cape slot the system will no longer require to have cached information on all other slots. At this point all information except for the arrow and ring slot is always available because of the injected callback of the appearance update block, so it's indeed for most unnecessary to have the system require a fully in tact cache. Edit 2: I'm aware of the fact that ring and arrow slots are bugged. After I've decided which one of the two solutions I have for them I'll implement I'll release a fix for it. Enjoy Sincerely, OSBot.org