Jump to content

Apaec

Scripter III
  • Posts

    11146
  • Joined

  • Last visited

  • Days Won

    91
  • Feedback

    100%

Everything posted by Apaec

  1. Thanks for the kind words, means a lot. Glad to hear the script is working well - best of luck with your gains!
  2. Woo, awesome proggie - thank you for sharing! That's some pretty amazing exp gains right there. Glad the script is working well! Apa
  3. All trials activated, apologies for the delay. Enjoy! Unfortunately I cannot offer trials to OSBot accounts under a week old - this is an OSBot rule. Sorry about this - please come back in a week or so! Apa
  4. Hmm, yes i'd be more than happy to! I was not aware there was a cooking location here. However I don't have an account with access to the myths guild - If you know anyone who could lend me an account for 20 minutes (or if you would be happy to help yourself - I know it is a lot to ask) I'd be very grateful. (Just have to gather some game data and do an integrity test before putting code live) -Apa
  5. Do you have multiple copies of a script in there with the same script manifest name? (e.g different versions of the same script) The manifest name is hard-coded in the script - if you have two of the same script in your folder at once, then neither of them might show
  6. Local scripts go here: C:\Users\<your name>\OSBot\Scripts Are you sure you've got the correct directory? -Apa
  7. I'll check over the code for the inside of V.east tomorrow - I ran some tests earlier this week and it seemed to handle the door OK from the inside. I'll also add an 'escape' option for varrock east to make it recover from misclicking the stairs (although I can't prevent misclicks in the first place naturally - so many factors affect this) Apa Edit: CLI - as for CLI, i'd like to add some parameters in general. Maybe i'll get around to this over the weekend!
  8. Hmm, i'll check over the code but i'm pretty sure I tested the clue looting recently and it worked! Are you sure you don't already have one in he bank?
  9. Script ID is 492 The script doesn't have any startup parameters beyond that though - sorry about that Apa
  10. Depending on your operating system you can use multi-click control (e.g ctrl+click or shift-click on windows) to select multiple potions. I've been working on an overhaul of this script in recent times which will see to make this a little more intuitive -Apa
  11. No worries You could always consider giving this script a go though if you're having problems with other scripts! Apa
  12. Unfortunately I don't do private scripts - sorry about this -Apa Trial activated Please let me know if it works for you - if not (or if something doesn't seem right), please let me know immediately. Apa All trials activated, thanks for stopping by! -Apa
  13. From the contents of the log you have provided looks like you are running a different script and not this one! (this is APA AIO Herblore) Maybe, i'll see if I have time to look into this over the weekend
  14. If you purchase it, it should just pop up in your scripts list like any other script! Woah!! Awesome progress
  15. No worries - I'm not sure exactly when you would like the trial, and also I would not trust myself with remembering to activate it! It would be better if you reminded me by dropping another reply here on/after Sunday when you feel like giving the script a shot -Apa
  16. Unfortunately I cannot offer trials to OSBot accounts under a week old - this is an OSBot rule. Sorry about that - please come back on Sunday! Apa
  17. Hey - welcome! I've just started your trial - please feel free to message me with any questions that you may have. I'm always happy to help Apa Sure, trial activated!
  18. I believe there's a list here: http://www.itemdb.biz/
  19. Yeah; all combat exp gained since starting the script. Apa
  20. There are a number of structural bad practices here which are likely causing the issue, or unreliability in the script as a whole. If you fix these, you're more likely to fix your original problem! You're writing the script in such a way that you're expecting each line to successfully execute every time. This is not (and can never be) the case as you're interacting with a live game so there is a whole middle layer entirely out of your control (latency fluctuation, game errors, resource throttling, ...). Don't do this! Instead, endeavor to make your script stateless, i.e it is not relying on any instruction to execute successfully before immediately proceeding to another instruction. You can achieve this by only ever having one interaction call per onLoop traversal (the interaction to execute would be determined by the current global game state). For example, a common mistake is as follows with banking: private void withdrawTenEggs() { // An example of how NOT to withdraw 10 eggs getBank().open(); getBank().withdraw("Eggs", 10); getBank().close(); } As you can see, there are three consecutive instructions. What if one of them were to fail - for example, the first 'getBank().open()' ? In this situation, the withdraw would have all sorts of problems as you cannot withdraw items if the bank is not open. This will likely throw horrible errors and potentially crash the script. Also, it is worth noting that jamming static sleeps between each of these calls will not fix the problem. So we've seen how not to do it, but how should you do it? Take a look: private void withdrawTenEggsProperly() { // How to properly withdraw 10 eggs if (getInventory().contains("Eggs")) { if (getBank().isOpen()) { getBank().close(); } } else { if (getBank().isOpen()) { getBank().withdraw("Eggs", 10); } else { getBank().open(); } } } As you can see, the above example will only ever try to do one game interaction each time it is called. Arguably this is poor design, as after calling the method you are not guaranteed to be in the state you need to be in, but luckily this is less relevant in the context of a system where the state is encapsulated externally. The benefits this approach provides far outweigh the negatives, namely that this method is much less error prone as there are no linear dependencies and will always converge to an end goal. Furthermore, this methodology capitalises on the ever-looping nature of onLoop. Hopefully that made sense - it's important to understand why your solution is unreliable rather than to patch up the code and settle for sub-par reliability Good luck, let me know if you have any further questions Apa
×
×
  • Create New...