Jump to content

Apaec

Scripter III
  • Posts

    11160
  • Joined

  • Last visited

  • Days Won

    91
  • Feedback

    100%

Everything posted by Apaec

  1. Hawk has pointed out the problem. It seems that the particular object you are interacting with changes after interacting with it - this is not the case for all objects, but appears to be the case here. Regarding the structure of your code, you should always aim to make the script deterministic based on game state. This essentially means that you should be executing a single game interaction per onLoop iteration. This way, should any given interaction fail (which can happen for many reasons as we are automating a live game here), the script will always be in a state to retry. Here's what I mean in your context with pseudocode: onLoop { RS2Object trapdoor = getObjects().closest("Trapdoor"); if (trapdoor has action "open") { if (trapdoor.interact("open")) { conditional sleep until trapdoor is open; } } else if (trapdoor has action "climb-down") { if (trapdoor.interact("climb-down")) { conditional sleep until climb down is successful (e.g. correct z index) } } } Note that for every iteration of onLoop here, only one interaction can ever happen. Also note that this example doesn't take into account the particular issue you are experiencing wrt. the trapdoor object changing. You'll probably need to initialise two objects (e.g. trapdoorOpen and trapdoorClosed) and act based on which one is null. Hope that helps Apa
  2. Both trials activated! -Apa
  3. Sure- trial started Apa
  4. That's odd -are there any errors in the console logger? not sure why this might be. -Apa
  5. No problem, i've replied in that thread.
  6. Apaec

    APA AIO Miner

    Hmm, thanks for letting me know. I'll test there.
  7. Hmm, it is possible that that's the reason. I'll investigate this weekend. Thanks for flagging this Apa
  8. Apaec

    APA AIO Miner

    Hmm, not sure why this might be. I'll see if I can recreate this over the weekend - are you using mirror mode or stealth injection? -Apa
  9. Sure - trial started Hey, The script should show you how many items you have successfully cooked (and how many you have burnt). I'm not sure why this is not showing up for you; what food item are you cooking? -Apa
  10. Hey, The script goes far enough to ensure a successful reset every time. The small extra distance does not impact efficiency too much; if the script didn't quite run far enough and had to do a reset all over again, that would take more of a toll to efficiency. Also, the extra distance serves as a buffer for fluctuations in latency and availability of RAM Apa
  11. Sure thing - trial started Apa
  12. Hmm, that looks like it is OK. I don't think the issue is with the manifest then. I'm sure you have, but have you tried restarting OSBot? -Apa
  13. Hey, Please could you send a screenshot of your script? Sometimes issues with the script manifest mean the script may not show. -Apa
  14. Sure - trial started -Apa
  15. Sure - trial started -Apa
  16. Update: Version 3.04 Fixed issues with script not letting OSBot solving bank pins. Fixed minor issues with walking to the fire. Stability improvements Big thanks to @S0905523for reporting the bank pin issue. -Apa
  17. Sure - just replied in the cooker thread. -Apa
  18. Sure - trial activated Apa
  19. Fair enough. I've made a note of this and i'll investigate over the weekend. cheers! Apa
  20. Hey, It looks like you have had a trial before, in august of 2017. That was a long time ago - i've set you up with a fresh 24h trial -Apa
  21. Hey, No, it shouldn't do this on purpose. Not sure what might be causing that for you, i'll take a look. Could be something related to mirror, might be worth giving it a go on stealth injection and seeing if that resolves things! Apa
  22. Unfortunately not, no. -Apa
  23. Hey, I've got CLI support on my to-do list for this script, though I am not sure exactly when I will implement it just yet. As for the break handler, what is wrong with the client one? Indeed, the main benefit of using the client handler is future-proofing: the client break handler will be updated by the OSBot team regularly (I believe they have some big updates planned https://osbot.org/forum/topic/163077-osbot-30-ai-transition/) and is backed by many more bug-free hours than a custom-built one would be. -Apa
×
×
  • Create New...