Apaec

Make sure you configure the script with unmined rocks only. If you select a mined rock, it will scrape the id of that and try to mine it!

Sure, if you need an example of how an enum could help you or any more help, just let me know & feel free to PM me with questions. When I write scripts for simple tasks, I always do my best to make them as configurable as possible, e.g turning a gold bracelet maker into an AIO bracelet maker! It's nice to have that sturdy code structure running so that you can quickly pinpoint issues and easily expand the script to support more stuff.

Sure, grab the widget with something like this: Point widgetCoord = new Point(X,Y); getWidgets().singleFilter(ROOT_ID, widget -> new Point(widget.getAbsX(), widget.getAbsY()).equals(widgetCoord)); You can store that point in an enum if you were to support different bracelets. Also, you will have to fill in the root id Haven't tested that code as I wrote it in the reply box, but it should work. Glad the issue was solved! Oo, I didn't spot that! looks promising.

If those still are the gold bracelet ids then i'm not sure what to suggest Try using log statements to pinpoint exactly which line isn't working. Also, maybe position is the best way to determine this widget from its horizontal counterparts? Using position would mean adding other bracelets in future would be simple and can be achieved with an enum or something to that effect.

Not sure why it would just stand there, the webwalker should have kicked in! As for the potions, you can hold CTRL to select multiple potions! Apa

Perhaps it's this line? getWidgets().get(446,47).interact("Make-X"); Maybe the id has changed. You can check this in-game and update it, but better would be to future-proof it by using the Widget debugger to try and find a trait of this widget to identify it other than its id. There must be something to identify it from others - perhaps sprite? (This is the reason that static ids beyond root level are not permitted on the SDN! - ids tend to change frequently, whereas text, colour or other properties are more consistent) Edit: This method can also be adjusted: private boolean isEnterAmountPromptVisible(){ RS2Widget amountWidget = getWidgets().singleFilter(getWidgets().getAll(), widget -> widget.getMessage().contains("Enter amount")); return amountWidget != null && amountWidget.isVisible(); } ... to: private boolean isEnterAmountPromptVisible(){ return getWidgets().getWidgetContainingText(162, "Enter amount:") != null; } Apa

Nice work (: Just a few things Be sure to check out the official naming conventions ( http://www.oracle.com/technetwork/java/codeconventions-135099.html ) For your axe level checks, you don't need to check either side of the limit, but that's minor That 'anti-ban' looks like it will if anything increase your chances of being banned Consider making your area global variables final, and private since they don't need to more accessibly than that Consider expanding into multiple classes for scripts which do more than one thing. As was mentioned above, enums are your friend and i'm sure you could make good use of interfaces or inheritance in a script such as this! Thanks for sharing! Apa

Maybe the script is using child/grandchild ids and perhaps these changed with Jagex working on Make-All? Just speculation, without any code i cannot help. You'll have to contact the scripter via the script thread! Apa

Hmm, that's odd. Perhaps due to the recent game update. Restart OSBot and let me know if you run into this again!

Sure, just started your trial. Enjoy! (:

It's very much similar. You just need to be a bit more careful about a few things but on the whole it's quite straightforward, even if you've never programmed anything before. As for a new SSF, if you got permission beforehand, it might be allowed on the SDN but it's pretty subjective. For a list of the SDN restrictions, give this thread a read: https://osbot.org/forum/announcement/62-script-rules-read-before-applying/

There are a few problems with the concept: It's very hard to make it a reliable platform, between issues with the source code and issues with misunderstanding/incompetent users, it turns into a scripter & store headache As you mentioned, in the past there was SSF. On the scripters' return, I believe he developed MacroSuite (this never got launched) but due to a fall out with the developers/admin here involving some doxes and other nasty things, the project was shut down. Since then, it's been against the rules (to my understanding), I don't think you would get permission to develop this for the SDN. My knowledge of the situation is very limited as I sort of stay in my own bubble looking after my own stuff because that's my job, but that's what I think happened. Please correct me if i'm wrong anywhere someone! Edit: It's really not that hard to write your own scripts. Much better read up about a bit of java and follow some tutorials overnight, so that you can write similar & better scripts yourself!

Sure thing, enjoy !(:

Ofcourse; i've given you a 48h trial as I recently pushed an update but this update isn't live to the SDN yet. 48 hours should hopefully be enough to overlap with the release of this update, so you should be able to try the new features which i've added. If the 48h elapses and the update is still not live (i.e the gui does not look like this: ) then let me know and I will sort you out with another trial. Apa

Sure, done! (:

Yes, they need to be 4 dose potions! You can quickly decant them at the Herb dude (Bob barter) at the GE. Hey! You have to almost run the entire length of the island to reset the crabs! Also I wanted to ensure it runs far enough such that it never fails and ends up in a continuous loop of attempting to refresh and failing. Something tells me that would be alot more bot-like! As for messing other areas, I did my best to map the paths closer to the centre, however due to the OSRS pathfinding and also the random tile selection of the script, this doesn't always work out. There's not much I can do about this since at some point most of the paths need to cross to reach the required reset path length! Also, if players are afking in these spots, most of the time the crabs are already aggroing them anyway. Cheers

Hiya folks! Just thought i'd drop it on the thread; i've just pushed version 3.02. While the majority of changes on this version were targeted at the AIO Cooker counterpart, a few new features have found there way to the Den cooker paint: Added anti-aliasing to the paint to make text more readable (Mainly added to host smaller text font sizes) Changed colours to higher contrast counterparts to make data easier to read Changed progress bar code to potentially cater for multiple bars, and adjusted colours to better fit the cooking theme. Added scrolling paint logger to the canvas which shows script run-time details on the screen instead of requiring you to open the console. This should help with future debugging. Made all elements to the paint movable! This means you can drag and drop the paint to wherever you please on the canvas and it will remain there, so you can move stuff off-screen or out of the way of the game interface. Note that the paint remains somewhat transparent so you should still be able to click through it without issues. New settings in the ui allow you to remove elements that you don't need, so you can always hide the logger or paint should you so choose. The Gui has been updated to match the AIO Cooker to house these paint changes, however I have blocked off the premium features - just ignore those ! (: This change hasn't removed any features previously belonging to the Den cooker, and the core function of the script has not been changed in any way. Simply the aesthetics! Apa

No problem - Thank you for the suggestion! (: Please allow around ~24h for my changes to be processed by the developers (they manually check the code to ensure there is no malicious content) before it goes live! Apa

MASSIVE UPDATE!!!!!! (: I've spent the majority of today working on this update as there were a number of features which were in high demand and a couple of things that needed fixing. I also added some QoL changes to make running the script a more pleasant experience. Version 3.08: Fully fledged target system implemented. This system allows you to configure exactly when you want to stop the script, so that it runs no longer than you need it to. You can set stop conditions such as: Exp gained limit (e.g stop after 5000xp gained) Time passed (e.g stop after running for 10 minutes) Level reached (e.g stop when level 66 cooking reached) All stop conditions rest on top of the basic supply conditions, i.e if you run out of fish to cook, the script will stop anyway, even if you haven't reached your target. To host this target system, i've made some changes to the startup Gui - see the updated image below! Speaking of the Gui, i've also added text tool-tips to most of the options to iron out any ambiguity as to what each option does. This means that, if you're not sure about what a setting does, you can just hover over the option and it should explain it in more detail. The Gui also remains fully resizeable to cater for higher resolution displays. The Paint: I've made huge changes to the paint and completely re-worked the back-end to give as much information as possible. The changes that i've made are below: Added anti-aliasing to the paint to make text more readable (Mainly added to host smaller text font sizes) Changed colours to higher contrast counterparts to make data easier to read Changed progress bar code to potentially cater for multiple bars, and adjusted colours to better fit the cooking theme. Added scrolling paint logger to the canvas which shows script run-time details on the screen instead of requiring you to open the console. This should help with future debugging. Made all elements to the paint movable! This means you can drag and drop the paint to wherever you please on the canvas and it will remain there, so you can move stuff off-screen or out of the way of the game interface. Note that the paint remains somewhat transparent so you should still be able to click through it without issues. New settings in the ui allow you to remove elements that you don't need, so you can always hide the logger or paint should you so choose. I've made some additional changes to Karambwan cooking. The script will now use a Gaussian-distribution based string generation algorithm to come up with potentially suffixed make-X values for the 'enter amount' interface. This adds further randomisation to the script incase it was not random enough already! (: I took a look at Hosidius and experimented with alternative arrangements for sequencing the interactions, however I concluded that what is in place at the moment is the optimum solution. Unfortunately it is a bit of a compromise but the safest and most reliably system is already in place! There are probably other things that I changed in addition to the above, but much more minor. Since this is such a large update, I would not be surprised if I missed something while soak-testing and a bug may have slipped through somewhere. If this is the case, please let me know so that I can get it fixed ASAP! Enjoyyyyyyyyyyyyyy! Apa

Cheers for these! Anchovy pizzas are a little tricky since they change name when you eat them, i'd have to think about how to implement this. As for the custom path, I could add this, however recently i've been working on a re-write for this script which will remove the need for a custom path (: Hopefully I can get this re-write out soon, but it's still a long way off being finished. Apa

Hey, To be honest, no-one really knows anything about bans and it's mostly speculation. There's no evidence to back up whether the time of day that you bot increases your chances of being caught - your best bet is to make sure you trust your script to run reliably, and to not bot for too long at once. Have a read of this thread: Basically, bans are pretty much random and bans are anything but quantifiable; Play it safe and bot minimally. Apa

Hey, sounds like you've set it to activate special attack despite these ranged weapons not having one. Disable that setting in the startup Gui and your problem should be solved (: Apa

Hey, I've run into this problem as well, i'm not sure that there's a fix without changing your screen resolution and rebooting. When I investigated, it seemed to be an issue with Swing claiming to be DPI aware to windows, despite it not being. After looking around, it seems there's no viable fix without adjusting a java install file... Take a look here: https://superuser.com/questions/988379/how-do-i-run-java-apps-upscaled-on-a-high-dpi-display Apa

Done & Done. Enjoy! (: -Apa

Replied to your PM! (: