Apaec

Trial started Apa

Hey, That's weird, this should be a thing. The script should stop if you run out of ammo, food, or any other item. Are you running in mirror mode? Perhaps it's just not working for mirror for whatever reason I'll take a look Apa

Sure, trial started for rooftop agility, as for crabs, i'm not sure which one you meant - sand or rock? Apa

Hmm, thanks for the feedback. The script didn't use to wait for the end of a spell, this must be in light of a recent update. I'll take a look. -Apa Sure - trial started!

Hey, Unfortunately the script doesn't support wine making (or any other niche cooking activities). wrt. your question, I'd say the risk is fairly even no matter what activity you bot, the only benefit to wine making is it is much faster than traditional cooking so you don't have to bot for as long in total. Apa Thanks for letting me know. In the game update yesterday they moved the hosidius kitchen along with the rest of the landscape, so i'll have to re-grab location data. I'll try and get this done ASAP. Apa

No worries, only scripters really know how the process works as they're the only ones who've been through it. No reason you should have known!

Nope, SDN scripts are uploaded separately via a git repo shared with you and the developers. The unofficial scripts section is for just that - unofficial scripts.

Sure - trial started Apa

How to prevent your script being stolen: Don't upload it to the public forum

It looks like the trial request was rejected server side as you've already had a trial with the expiry timestamp 2017-10-09 08:04:14 UTC Normally I only allow one trial per user, but as this was so long ago (and the script has probably changed since), i've gone ahead and started a fresh trial on your account. GL! Apa

There was a game update, so the client needs to be updated. Please be patient while the developers work on this Apa

No worries - I have to say, that sounds incredibly lucky. MLM is somewhat of a bot hotspot, so it is impressive you only received one ban between 40 and 99. Also, i'd be more cautious now that your account has already been flagged for botting. If you have any other questions, don't hesitate to ask. Best of luck! Apa

Sure - trial started Apa

Sure - trial started Apa

Sure - trial started You can see some progress reports on the front page of the thread in the 'Gallery' section. I'll leave it to other users to discuss their experiences. Hey, In general, bans are much more to do with how you use a script/bot, not the script/bot itself. You should go in with the assumption that you've already been flagged as a potential bot the moment you log in through OSBot (or any other bot). If you keep a low profile, use short sessions with generous breaks, and play legitimately at regular intervals, you should be fine, regardless of script. But don't take the risk on an account you care a lot about. With that in mind, if you'd like a trial of the script, don't hesitate to ask. And if you're not sure what to look for in a script, in my opinion i'd put reliability at number 1 Best Apa

[Dev Build] OSBot 2.5.48 has fixed these issues. Special thanks to @Patrick for fixing it so quickly. You can either run the dev build now, or wait until the version is rolled out as a stable release

This is a dev build, not a stable one. If you want to use this dev build, then you'll have to update manually, but otherwise you can stick with the stable version. The stable version won't contain the dev build changes, but will be stable. ---------------------------- @Patrick thanks for this! I will run a test on the login handler now... Edit: ran a few tests and is working well. Cheers! Apa

I investigated this as well - what is happening is the OSBot login solver is exiting too early, causing the script to run while on the title screen. As the player is not logged in, important game state data is not accessible and the script is subsequently falsely told it is out of nature runes (for example). What makes this more frustrating is the API checks for being logged in are inconsistent and return true even when on the title screen. Not sure what I can do about this as it should not be happening - i'll have to raise this with the developers. In the mean time, i'll implement a temporary messy workaround which will spread the checks temporally. Apa Edit: I've mentioned this to the developers and Pat said he will investigate. I will keep you updated

Ah interesting. Thanks for letting me know -Apa

Your changes: When I said conditional, I meant more that only one line would run with any given onLoop iteration. The reason for this is that the API interacts with the live game - you cannot expect any API call to return successfully every time and as a result chained API calls which depend on one another (for example, opening the bank and then depositing an item) can fail. This is relevant in your code - you are calling getWalking#webWalk and immediately after you are interacting with the altar. What if the walking failed (for whatever reason)? Then you wouldn't be in range of the altar and the script would be stuck. Null checking: As for null checking, at the moment you are grabbing and interacting with the game objects as follows: getObjects().closest("Altar").interact("Craft-rune"); This is fine if getObjects().closest("Altar") always returned a game object, however this is not the case. If closest did not find any object matching your filter, it will simply return null, at which point you are calling 'interact' on null which will result in a Null-pointer error (for obvious reasons). Instead, do something like this: private boolean someMethod() { RS2Object altar = getObjects.closest("Altar"); return altar != null && altar.interact("Craft-rune"); } Sleeps: Again, the script is interacting with a live game, so there are all sorts of barriers between your script and game state. One of these is latency, fluctuations in which mean timing in your script is never going to be perfect. As a result, adding random sleeps here and there gives a false sense of security. Instead, to prevent bans, focus on making your script as reliable as possible, and then use the script carefully and keep a low profile. If you do add any randomisation, doing so in interaction timing is probably not the place. To make the script reliable, conditional sleeps are needed to retry actions only when needed, as well as to maximise script responsiveness (minimise the time the script spends sleeping, and maximise the time it is aware of game state). Stick with conditional sleeps --------------------- Good luck! -Apa Edit: Also, as @ProjectPact mentioned, avoid while loops. Why would you need a while loop if you already have a perfectly good one: onLoop()?

Really nice! This code is, for the most part, well structured, readable and tidy. It's stateless and conditional which is nice. A few suggestions: Replace the static sleeps with conditional sleeps. This will ensure you only sleep as long as you have to. Null check the altar, portal and ruins, otherwise you'll end up with some nasty client crashing errors. You could always write a method to wrap that stuff in an Optional so you don't forget. Make the runecraft() method conditional, at the moment it is not Other than that, well done - this is great for a first script Apa

Sure - trial started. Good luck! Apa

Sure - trial started Apa

Thanks for your custom As for the issue you've mentioned, thanks for letting me know. I have an idea of why it might be - it will only happen on rare occasion but I believe the script is running while OSBot is on the title screen, which should not happen (I'll have to ask the developers if they can look into getting this sorted) Hopefully it doesn't cause too much of an inconvenience, but if it does, please let me know. Apa

Sure - trial started! Apa