tbfeonar01

Completely missed that you sent this message until just now and didn't get a chance to actually test the script on Thursday. Would it be possible to send another 24hr trial? I'll be more vigilant about watching for your response so I can actually test it this time

Definitely interested in giving this a try. I'd love a trial

I'd love a trial - I'm a big fan of your other scripts, eager to give this a try and see if it will be suitable for my use

I do personally, on PC I run with resizable mode enabled and maximize the window when I'm into it or shrink it down/put it off to the side while working/programming etc

Quick question - OSB requires fixed viewmode, with most users using resizable when they play legitimately isn't this potentially a detectable vulnerability? Also, another consideration - RuneLite vs normal client, if Jagex can see which type of client is being used and 90% you're using RuneLite but when you bot you're always using regular client this likewise seems like a potential vulnerability Thanks

Might I get a trial? I'm quite interested in a PC script at the moment

Wonderful! Thank you Malcolm! Definitely looking forward to it. Additionally, just to follow up with further suggestions: If possible, maybe add the option to skip X tasks from user defined list when above Y slayer points or maybe some other factors for more efficient execution Maybe some sort of selection for locations (obviously that would require more work in programming, but would be a nice QOL if there is a strong alternative as Demonic Gorillas vs Black Demons for example. I'll pop back in if I have more comments/suggestions

I'd be happy to test/contribute where possible for the v2 beta - with regards to the current iteration: First, it would be nice to be able to specify different armor sets other than Black, as an example - take for example Bandos or Amradyl etc D'hide, that'd be a nice QOL addition. Next, with regards to the loop that buries bones usually it goes something like this: > kill monster > loot bones > loot items >if inventory not full: >bury bones however, >if inventory full: >eat food and only then >bury bones Thus you end up unnecessarily eating a food in those instances, each and every time the inventory is full, perhaps in these cases add an additional logic loop conditional that says if you have a bone you want to bury finish that first then check if inventory is full In addition, it'd be nice to specify which bones to bury, for example a newbie might want to bury any and all bones, whereas a higher level character might want to bury only dragon bones or better as an example for time/action economy. Something worth considering. In addition, is something like a prayer flicking module possible? I don't know how complex such an iteration would be but my imagined method would be like this; _____ In combat with creature or "Prayed Monsters" List Get attackspeed/frequency attribute from list Monitor incoming damage bubbles (if that is a readable thing) Synchronize to incoming damage bubble with some variance for ban prevention say between 0-250ms of the actual damage so you will not do it perfectly every time, just say for example t = attack_timer prayer_toggle_on = expected_attack - random_variance(10, 250) so in that case it woudl trigger anywhere from 10 - 250ms prior to the actual damage tick. I'm not sure if either the read damage step nor the index of attackspeed frequency is even a possible thing but if those values can be read that would be a simple enough solution here. Maybe have an additional synchronization check which detects every few seconds after initial calibration just to confirm that you are still in sync expected issues: multicombat would cause issues unless there is again some way to detect multiple enemies and track those, but perhaps it would be worth in that case to just leave the prayer on in multicombat as an override, not sure. Anyway, great script! Definitely enjoy it. Looking forward to hearing more about v2 and if you are interested in taking me up on my offer with regards to beta testing I would be happy to do so and I can do my best to provide code feasible suggestions. My coding experiences is almost exclusively in Python however. Much love and great work guys!

As promised continued updates as I am using the script - You were correct about the dropping issue I perceived as being normal, I observed the script for an extensive period of time and yes, as you suggested the bot was simply dropping the used buckets. All is well on that front. One small issue with regards to the Hunter script which might be a noticeable behavior - when trapping the first location with two traps after the second trap is already placed the script always walks further away from the mushroom teleport and then quickly turns back around rubberband style - this is no issue on a small scale, but if it can be observed that everyone running this script exhibits this unusual behavior it can plausibly be considered as a potential vulnerability. This is a great script, I've been running it since authorization and have been enjoying the results. One further suggestion - it would be of great benefit to track your supplies in client somehow, for example when the script initializes check ALL supplies, or perhaps only supplies required based on settings indicated and keep a live running count of remaining supplies. Obviously restocking feature once implemented (also, curious when that will be :D) will solve that somewhat but even still on initial execution I had to constantly run the script to have it stop just to read the logger, I had to do this like 8 times before I finally had all the required items. It would have been a lot easier to just have a client-side display with supplies and big red "0"s next to the ones you need Anyway, nice work! I'll continue observing and likewise will continue posting back as development proceeds

Okay, reporting back as promised: One issue observed, character got to plots, went about harvesting items, ran out space, proceeded to drop composts only after which did it go to the tool leprechaun to note items, it proceeded to harvest the rest of the crops and teleported without picking back up the composts. This seems like something worth optimizing, particularly if using higher level composts etc especially given that it is essentially an order of operations issue. Otherwise, appears to be working approximately as intended - haven't figured out why birdhouses aren't working as there is no readout/detailed view to try and ascertain what is missing. In addition, on further observation, it arrived at a new plot, took compost from the tool leprechaun, causing inventory to be full at which time it began dropping composts yet again and again teleported without picking them up even though in both cases the inventory was no longer full. As a proposed solution: It appears the issue is stemming from an automatic response to "inventory full" state, perhaps an override that first checks if there are notable items in inventory to clear space, if so it brings them to the tool leprechaun to note first. Then, and only then does it proceed to drop items until able to fit, then it goes through the noting step and before teleporting perhaps checks ground items for items it has dropped and picks them up. It seems like at least an attempt at a solution. Hope all is well, I will keep testing/observing but I expect this issue to persist between tests.

I'll definitely check this out, if you'd like to auth I can leave notes on operation. What are the starting conditions/prerequisites and preferred test parameters? What functions are you most interested in testing?

Django is awesome, I would definitely recommend that one

I'd love to give this a trial Thanks!

Is it possible to have it just cut logs and bank to a set number and only then start fletching?

Not sure if it is a wrong setting or something but for some reason it is teleporting to Ferox with only approximately half inventory filled - is this intended? Edit: Nevermind, didn't realize using the sickle (b) cost prayer points, that explains why it is stopping prematurely