Apaec

Hey, The nicest way of doing this is pre-recording a list of positions, and feeding that into `getWalking().walkPath()`. Here are the relevant docs: https://osbot.org/api/org/osbot/rs07/api/Walking.html#walkPath-java.util.List- Good luck! (Btw, feel free to PM me your code when you're done - i'd be more than happy to comb through it and give you some feedback ) -Apa

That's very strange; looks like it may be an issue with mirror mode. I am not sure if this will help, but could you try putting your sardines in the main tab of your bank, and ensure they are on-screen when the script starts? I hope that this will resolve the issue. If this does not solve the problem, let me know. Apa

Hey Psychotechno, Yes, exactly! As I mentioned, the script is interacting with a live game, so every game interaction could fail. Therefore, if your script is entirely deterministic, the script will always be in a position to retry an action until it succeeds (which will cause the 'game state' to change, thereby allowing the script to progress). The code that you have shared is not quite deterministic; we can prove this by simply looking at your banking statement: if (!getBank().isOpen()) { // ... getBank().open(); log("Bank was opened"); getBank().depositAll(); log("Stuff was deposited"); // ... } Let's say that the game is in a state where the bank is not open, thus the above condition evaluates to true and the inner code block executes. First, the script will try to open the bank. This may succeed or fail (high probability of success, but non-zero probability of failure). In either case, the script will next try to deposit everything. This will fail and the script will crash if the bank failed to open initially - uh oh! If the bank opens successfully, then the depositAll may or may not succeed (again, high probability of success). So therefore, for our one input state, we have three potential output states: (1) The bank is not open; (2) The bank is open but your inventory is not empty; and (3) The bank is open and your inventory is empty. In this example, the fact that a single input game state maps to more than two potential output states means that the script is prone to failure. So - how do we prevent this? It's actually very simple: if (!getBank().isOpen()) { getBank().open(); } else { getBank().depositAll(); } If this was the sole contents of your onLoop, then a single game state maps to exactly two output game states: A success state and a failure state. If a failure state is reached, the game state should remain unchanged, thus the script will re-try the interaction automatically. Naturally, this is only a simple example, but you can extend this paradigm to your use case. This kind of determinism is what separates low quality scripts, such as those typically written by beginners or found in the local scripts section, from the reliable, high quality scripts found on the SDN (for the most part ). I hope that made sense, please let me know if anything is still unclear - always happy to help! -Apa

Hey, Please could you elaborate on the problem you're experiencing so we can figure out what is wrong here? Specifically: which position are you training at, what exactly happens, and are there any logs/errors in the console logger? Cheers, Apa

Sure thing. Trial activated! Apa

Sure - trial started Apa

Sure - trial started Apa

Hey, This is on my to-do list but there are some complications with how to handle the many-to-one mapping of input to output, so this isn't a trivial change. I hope to get around to implementing this next weekend, but cannot promise it will be ready by then at this stage! -Apa

Yes. Two minutes before a break is due to start, the script will walk to a safe place so that your player logs out successfully for the break -Apa

That's bizarre. Thanks for letting me know. Are you running in low-cpu mode, or on a machine with very limited resources? It may be that the script is lagging and not properly detecting that aggro has been reset. Cheers

Hey, I did a test run with Karambwans and everything seems to be working fine for me. Are you cooking Poison Karambwans or Cooked Karambwans? If the latter and you haven't done the Tai Bwo Wannai Trio quest, then this will cause the script to fail (you need that quest to cook karambwans), so please double check this is not the case! -Apa

Sure - trial started -Apa

Sure, trial started -Apa

This issue should now be resolved thanks to the development team. Please refresh your scripts lists and try again! Good luck with the cooking cape! -Apa

Hey, This will be unrelated to your power outage. I also had this issue with one of my own scripts - i've notified the development team and they have sorted this out Try again now. Let me know if it's now working? -Apa

Hey, Thanks for letting me know both. I've just tried and the SDN version of the script doesn't seem to be loading for me either... I'm not sure why this might be, there don't seem to be any logs either. The script hasn't changed recently so this is likely something wrong with the latest client build. I'll look into what might be causing this, but I hope it will be fixed automatically with the next SDN build or next client release. -Apa

Hey, Sorry for your ban J money- sounds unlucky that you got it so soon, but at least the ban is temporary. As Troro mentions, the key to avoiding bans is to bot cautiously. Keep sessions short, use generous breaks and play legitimately between sessions, and you should be fine. This holds true for any script/bot that you use: you should consider them all equally dangerous! -Apa

Small new years eve update! Version 3.15 Fixed issue where script would occasionally get stuck while walking to bank when using CCI_1/CC_2 spots As usual, please allow some time for the developers to verify these changes before they go live. Thanks to @troro1for reporting this -Apa

Hey, I've done some test runs with the AIO smithing script and everything appears to be working as expected. Perhaps this might be a configuration issue? As @Spacesaid, do check the console logger as this is a common place where scripts to write important information. If you're still having issues, please get in touch! Either a PM or on the script thread is fine -Apa

Ah, wine making would probably fall into the category of a Cooking script rather than a Cooker script. If I were to add wine making (and other cooking activities), I believe the current store rules would require me to increase the price of the script, which is something i'd really like to avoid. For this reason, I probably won't add wine to the script. But I believe there are dedicated wine scripts available already - have you checked any of those out? -Apa

Sure - trial started -Apa

Sure - trial activated Apa

Hmm. Sometimes the break handler doesn't save its settings correctly for some reason (it took me a few tries when I was testing recently). Perhaps try experimenting with short breaks (maybe a minute break and 3 minutes off). If the break handler is correctly set up, you should see a message printed in the console logger saying something along the lines of 'taking a break in x minutes' Thanks. I'll see if I can recreate this issue by testing at those co-ordinates. -Apa

Sure - trial started -Apa

Did this issue happen before october? I am trying to work out if this is an issue with the mirror client or with the script. Also, what is the tile on which the script gets stuck repeating this message (screenshot or co-ordinates would be useful!)? I have so far been unable to recreate this so any extra info is highly appreciated! -Apa