Apaec

Unfortunately not, this script is a `cooker` only! Writing one yourself is a good plan, though I believe there are also a few specific wine making (or even more general `cooking` scripts) on the SDN. Cheers, Apa

Sure - trial started -Apa

Both trials activated thanks for stopping by -Apa

Sure- trial started Apa

Sure -trial started Apa

No worries at all, i've just set you up with a fresh 24h trial Apa

Hey Cheers for taking the feedback on board. Nice one on point 3. As I mentioned before, a nice way to test that you don't have any holes in the journey (and hence places the script could get stuck) is to start the script at various points in-game and seeing if the script can get into the normal flow. As for point 5, yep - that's more or less what I mean. Right now, you are creating your dungeons path each time you enter the method, which is unnecessary as this path is constant. Instead, you could do something like this: List<Position> TELESPOT_TO_DUNGEON = Arrays.asList(new Position(3086, 3488, 0), new Position(3093, 3479, 0), new Position(3094, 3470, 0)); Also, you can add more positions to your path (I like to add every other tile to my paths and I have a script to record such data). As the walkPath method will select the next suitable position from your path (typically, I believe, the furthest point in the path reachable on the minimap), you don't have to worry about the script walking in small increments. As for point 6, local variables e.g. your `telespot_neardungeon` should be camelCase, i.e. `telespotNearDungeon`. That's the only inconsistency with the java conventions that I can see GL! -Apa

Sure thing, trial started! -Apa

Ah, apologies for the delayed reply re. the timings issue. I am currently working on levelling up my test account to access the course, and meanwhile am trying to think of a nice way to incorporate general timing tweaks into the script such that a major overhaul of how obstacles are handled is not needed. Sure, trial started! -Apa

In general, it's best to avoid botting where possible. Alching is something you can do fairly reliably with just an autoclicker, hence my recommendation. (To the best of my knowledge, autoclicking generally results in at most a temporary 'macro minor' ban, whereas botting can result in the permanent 'macro major'). However, this script is quicker to set up, more convenient (you can use your computer at the same time), works with automated breaks, permits the use of different inventory slots for alching (and allows spell filters to be active, etc), and tracks your progress. It's up to you which tool you use; and be sure to keep the risks you are taking in mind at all times!

Hey, This is looking nice! I'm not exactly sure if your conditions cover every case, because I don't know the context of the script. However this is something that you should have a feeling of and something I am sure you can test. A few things to note: All walking events could fail at any point throughout the walk (though this is unlikely). You therefore have to support this, so make sure this is the case. A good way to test this is to start the script at various stages in the journey and see if the script successfully completes the journey (relying on the webwalker as little as possible). getWalking().webWalk() and getWalking().walkPath are both blocking operations; there is no need for a conditional sleep after them. What happens if none of the conditions are met? Checking a Y coordinate like that is a little strange; I would keep things to area checks to make your code more readable! You should pull constants (such as the path) outside of the function. You can also instantiate the ArrayList from an array of positions. Try and stuck to java naming conventions where possible (though this doesn't matter so much, just a nit really). I wouldn't worry about walkPath not being random enough, lots of factors will combine to mean this isn't a problem (e.g. camera angle, network latency fluctuations, clickbox randomisation, etc) Nice one -Apa

Sure - trial activated Apa

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