Jump to content

Apaec

Scripter III
  • Posts

    11168
  • Joined

  • Last visited

  • Days Won

    91
  • Feedback

    100%

Everything posted by Apaec

  1. 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
  2. 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
  3. Ah interesting. Thanks for letting me know -Apa
  4. 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()?
  5. 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
  6. Sure - trial started. Good luck! Apa
  7. Sure - trial started Apa
  8. 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
  9. Sure - trial started! Apa
  10. Thanks for letting me know. This is likely down to mirror mode, as I tested it yesterday with Stealth Injection and it picked up marks just fine! I'd suggest switching over to SI for the time being. Cheers -Apa
  11. Sure - trial started Apa
  12. Probably an auto clicker is better, as you then are risking a macro-minor ban rather than a macro-major. The former results in a short, temporary ban, whereas the latter is permanent. -Apa
  13. Sure - trial started Apa
  14. Sure - trial started Apa
  15. Hmm, weird. I've just tested it and it is alching perfectly for me. Have you by any chance configured your spellbook weirdly? I noticed that recently Jagex have added the option to filter your spells. Apa
  16. Oh, interesting. I haven't accounted for unbankable items in the banking code. I should add a check for this and make the script stop when it cannot bank something - thanks for letting me know
  17. Sure - trial activated ! Apa Hmm, could be mirror related then. Does it work on Stealth Injection? Apa Sure - trial started Apa
  18. Hmm, what are you using as your source of fire runes? I don't think the script supports tome of fire / bryo staff yet - you might have to switch to a fire staff. Hoping to roll support for these out in the near future. -Apa
  19. Hmm, I'll look into this. Might be possible, but can't make any promises without first investigating Apa
  20. Thanks for the screenshots - i'm glad you liked the script Apa
  21. Both trials started Apa
  22. Sure - trial started. I'd be hesitant with mirror mode though, it doesn't work well with many (all?) scripts so make sure you babysit at all times! Apa
  23. Sure - trial started Apa
  24. Hey, Looks like the trial request didn't go through as you've already had one with the expiry timestamp 2018-04-01 18:46:28 UTC. As this was so long ago, i've gone ahead and cleared record of that, setting you up with a fresh trial starting now. GL! Apa
×
×
  • Create New...