Apaec

Sure, although the latest version (2.0) has not been pushed live yet. I've given you a 48h trial in the hopes that it will be available in that time period, but if not, I will continue to extend the trial by 24 hours until you get to try the latest version, as the script has been re-written from scratch so it would be unfair for the trial not to test what the script really is (: -Apa

\o/ Me! But it took a lot of careful botting with short sessions and no more than 1-2h botting per day.

Yes. I will be looking to re-write the script at some point in the near future to add support for stuff like phials and Rimmington, but for now it only works in Yanille! -Apa

When I give it! (:

PLEASE NOTE: THIS THREAD HAS BEEN UPDATED TO DESCRIBE SCRIPT VERSION 2.0 WHICH WILL BE PUSHED FOR MODERATION TONIGHT. Edit: The update request has been pushed. Version 2.0 should go live once the changes have been checked for malicious content by the bot developers. Considering the scale of this update, this understandably may take some time!

Also seem to be struggling with mouse listeners ): Running on Windows 10: getBot().addMouseListener(....); fires the mouse events when human input is enabled, but does not when human input is disabled. getBot().getCanvas().addMouseListener(....); does not fire mouse events at all, whether human input is either enabled or disabled. The first one worked perfectly for .127, now neither achieve what I was hoping for. Not sure why this is! _____ As a side note, for me the enable/disable human input option is working perfectly and doing its job as it should, thanks for this (: Cheers -Apa Here's a gif illustrating the issue when calling getBot().addMouseListener: http://i.imgur.com/Gl97TOJ.gifv on previous versions, it would respond both when human input is disabled and enabled.

I have no macbook knowledge but I can tell you that it's probably worth investing in a new laptop instead of going for an old one. The way I see it, if you're planning to use it a lot, then it's worth paying a little more and having a nice machine that will last you longer! Apple seem to have pretty poor hardware specs in comparison to competitors, but have very good software optimisation, so if you're looking for super-high numbers then maybe a mac isn't right for you. They're still amazing machines though!

It's a valiant attempt but I think you need to consider the structure a little. Since you're writing a script for a live game, you've got to consider factors such as latency fluctuation and misclicks - these factors mean lines of code which interact with the game cannot be 100% guaranteed successful. As a result, you have to write your script in a state based manner to account for this. Typically, I would suggest aiming for performing a single action per loop of your onLoop. Ofcourse me saying that is very subjective on the structure of the code you have in place at the moment, but for simple scripts where you drop everything in the onLoop, one action per loop seems fair enough. This means at no point should you chain actions that depend on one another - a classic example of this is: getBank().open(); getBank().depositAll(); Instead, you want to make use of the continually looping nature of your onLoop and make the interactions conditional: if (getBank().isOpen()) { getBank().depositAll(); } else { getBank().open(); } I know it's a very simple example, but it illustrates the point - when the second example runs, the first onLoop loop will open the bank, and the second will deposit your items. The first one will attempt to do them in succession, and if the initial getBank()#open call fails, then you will potentially be left with a nasty error and/or unexpected behaviour from there on. As you can imagine, the more actions you chain in this manner, the worse this unpredictability will become. Anyway, with that out the way, your code. Since cooking something is quite a complex task with alot of clicking on this and clicking on that in a particular order, it forms a really good problem for you to try and solve. I would highly recommend the use of ConditionalSleeps in your code to make it more efficient - these can be defined anonymously as follows: new ConditionalSleep(5000) { @Override public boolean condition() { return myPlayer().isAnimating(); } }.sleep(); (Wrote that in the reply box, apologies if there are any typos/anything I missed - it's late!) That code will create an anonymous instance of ConditionalSleep and in this case will sleep until either 5000 milliseconds elapse or your player is animating. ConditionalSleep#sleep() returns a boolean of whether or not the condition was met before the time expired, but we're not using that feature in this snippet. Also, don't use child/grandchild widget ids! Instead, search for widgets containing text, or do something else which doesn't require arbitrary ints in your code which could change when the game is updated. Hope that helped, I know I didn't answer you directly as there's nothing to be learned from spoonfed code! let me know if you need anything else! -Apa (:

Apologies for the delay. The issue has been fixed in version 2.0! ________________________________________________________________________ I am pleased to announce that APA AIO Smither Version 2.0 is almost ready for release! This means big changes. I mean BIG! The script has undergone a complete re-write from scratch. As a result, you can expect a more reliable structure making it easier for me to implement fixes and updates in the future! Version 2.0 is considerably more powerful and features a fully fledged 'activity' system. This allows you to completely customise how your session runs, enabling you to combine smithing activities in one instance. The activity system relies on a configurable activity target setup, which you customise when you create a new activity. This target setup allows you to move onto other activities when you deem a previous activity complete. To host this activity scheme, i've completely re-worked the user interface and have done my best to make it as intuitive as possible - examples are below: When you start the script, the activity editor pops up. This is the panel in which you configure the script session. The activity editor has a 'settings' button for global script settings such as the ability to move your mouse outside the screen while you are idle - i've left space for more global options in the future. The settings panel also has options for the paint, which has also been re-worked. Yes, you can recolour the paint! You can then add individual activities with the 'Add' button. When clicked, this window pops up: Prompting you to select whether you want to add a forging (turning bars into items), smelting (turning ores into bars) or cannonball (turning steel bars to cannonballs) activity. Depending on which one you select, one of three interfaces shows up, as illustrated below: These interfaces can then be customised with a target and added to the activity queue. Here is an example of a script session: When start is pressed, the script will begin running and process activities from the top down. Here is an example of the new paint and on-screen logger: The logger saves timed messages, so each message only sits on screen for 60 seconds, or until it is pushed off the screen by on-coming messages (the logger height is currently set to 6 lines) The paint objects are completely movable, meaning you can re-locate them to where you desire or move them out of the way of something that you're trying to interact with if you're intervening with the bot. They can also be hidden through the startup settings menu if you so desire. When typing the 'Make-X' messages previously, the script would simply drop a random number. Now, I have implemented a more advanced algorithm to generate 'Make-X' strings which uses gaussian-distributed number generations to configure strings to include suffixes such as 'k' and 'm', commonly typed numbers such as '1234' or '99', randomly generated numbers, round numbers like 9000 and much more. This new system renders the previous manual selection text-box obselete. That about sums up the changes that I have made to the script. Rest assured that all features previously supported by the script have been restored and improved upon, alongside the plethora of new changes I have made in v2.0. I am aiming to have this version of the script released for early next week after I have fully soak-tested the code! -Apa

Read!

it should be! (: -Apa

Hey (: This is caused by a recent osbot interaction update, it seems to be happening for most scripts. I'm not sure if there's much I can do about it without writing my own entire interaction system, which in the end may not turn out to be as reliable as the OSBot system. Perhaps the interactions will be changed in the near future but beyond that there is not much I can do as client work is out of my control! Thank you for bringing this up though. -Apa

Perhaps it's just worldhopping behaviour that was implemented in the script; would that make sense for the script in question?

Is this happening for a specific script ?

This is really cool, how did you go about doing this? Did you work with images and apply filters such as cutout, or did you draw the masks from scratch? I'm not very graphics-proficient but this is really nice (: -Apa

grats (:

Haha I love how the video has been disliked to death presumably by rot xD

Posted elsewhere but also relevant here: OSRS was updated only a few hours ago. Expect things to be broken; The developers are aware and will be working on a fix. Nothing else can be done until then - sit tight! Cheers -Apa

OSRS was updated only a few hours ago. Expect things to be broken; The developers are aware and will be working on a fix. Nothing else can be done until then - sit tight! Cheers -Apa

@pallmalled

Yeah the guide is pretty outdated; I should really re-write it, I just haven't found the time recently. Thanks for reminding me!

Also it is worth noting that you can download local scripts and 'decompile' them. A jar file is essentially compiled java code (java byte-code), and 'decompiling' a jar file will attempt to revert this byte-code to the initial source code. Since compiling is not a perfectly reversible process, some decompilers do provide minor inaccuracies to the initial source code, such as wrapping objects in one-item object arrays and such, but the jist of the code should be evident. Java decompilers can be found online, you should be able to find a free online one with no problems. Decompilers running JDCore or similar are a good bet. Things to note: A lot of the local scripts are poorly written. Careful what you learn from! As I mentioned above, the source code might not match the original, but it will be close. Don't use that 'task/node' framework that people say you should use unless you have a good reason to..! I only say this because the local script section is full of these kinds of structures and they bring nothing new to the table above simple if/else statements in your onLoop. Let me know if you have any questions! -Apa

'Ban rates' is a very misleading term. I say misleading because some users manage 2-day straight botting sessions, while others are banned within just a few hours. It's very unpredictable. To reduce your chances of being banned (not removing the chances!) be sure to have a read of this thread: Jagex have seriously stepped up their game detecting bots (ofcourse depending on when you last botted), so you've got to be extremely careful. For example, when botting I usually bot for 20 minute sessions with generous breaks, totalling no more than 2 hours (absolute maximum) botting time per day. This way i've managed to get 90/90/90 stats over the course of a couple of months. Patience is key! Cheers -Apa

Started out here, found a reputable scripter and annoyed them alot with questions!

Okay, After checking it seems you didn't reach the usage threshold to warrant no further trials, so i've gone ahead and enabled another 12 hours to your account. Enjoy! (: -Apa