Fanny

Just a thought, but Falador Party Room on a dead world perhaps? (not sure if it works though)

When the thread starts with such a low-effort post, it must be balanced somewhere with comprehensive reasoning!

First and foremost, it is important to recognize that the concept of “proven safety” in botting is fundamentally flawed for several reasons. Let’s break down why botting can never be entirely safe and why claims of safety are, at best, anecdotal: 1. The Cat-and-Mouse Dynamic: Botting operates within an environment where developers of the game (or application) are constantly evolving their detection methods to identify and ban users engaging in automated behavior. Anti-cheat systems use increasingly sophisticated algorithms that analyze patterns in player behavior, data consistency, and other markers. On the flip side, bot developers are constantly tweaking their code to avoid detection. This ongoing battle creates a dynamic where no bot can be indefinitely "safe" because the detection methods are continuously improving. Thus, any claim of a bot being “proven” safe is only as valid as the current state of anti-cheat measures, which could change at any moment. 2. Anecdotal Evidence is Not Statistical Proof: Users frequently share stories on forums about how they have used a certain bot script for weeks or months without getting banned. However, these accounts are purely anecdotal. While one user might have used a bot for an extended period without issues, another might get banned within a few hours using the same script. There are countless variables at play, such as usage patterns, geographic locations, account history, and randomness in ban waves. Simply put, what works safely for one person may not work safely for another. 3. User Behavior Matters: Even if a bot script is well-written and designed to mimic human behavior closely, the way it is used still greatly affects its safety. For example: Duration of Usage: Running a bot 24/7 is far more likely to result in detection than using it intermittently. Task Variety: Engaging in the same repetitive task over and over (like fishing or chopping trees) for long periods can raise red flags. A human player would typically engage in various activities and take breaks. Patterns: Even the most sophisticated bots can produce subtle patterns that are detectable over time. The longer you use a bot, the higher the chance that your account will be flagged for further scrutiny. 4. Banning Strategies and Ban Waves: Game developers often delay banning users to conduct large-scale ban waves, catching multiple accounts at once. This tactic allows them to analyze bot patterns more effectively and fine-tune their detection systems. As a result, a script that seems “safe” today might lead to mass bans tomorrow. You might think a script is “proven” to be safe because no bans occurred in the first few weeks of using it, only to face a wave of bans later. 5. Detection Mechanisms are Diverse: Anti-cheat systems use various techniques, such as: Behavioral Analysis: Monitoring in-game activity, including response times, patterns, and the timing of actions. Client-side Monitoring: Scanning for unauthorized software or memory manipulation. Server-side Logs: Analyzing data packets, movement patterns, and time spent on specific activities. Since detection methods are so varied, even a bot that appears to operate undetected by one type of system could be exposed by another. Therefore, labeling a bot script as “proven safe” is risky because no one fully knows all the detection methods in place. Why Learning to Script Might Be the Better Path Given all the risks associated with relying on third-party bot scripts, an alternative path is to learn to script your own bots. While this also carries risks, it provides several advantages: Customization and Control: When you create your own scripts, you have complete control over how the bot behaves. You can tailor it to your specific needs, introduce randomization, and fine-tune it to mimic human behavior more effectively. Understanding Anti-Cheat Mechanisms: By learning how to script, you also gain insights into how detection systems work, allowing you to design more stealthy bots. You can program behavior that mimics natural human actions, such as randomized delays, task switching, and other unpredictable behaviors that are harder for anti-cheat systems to detect. Adaptability: Anti-cheat systems evolve, and so should your bot. When you’re the one writing the code, you can quickly adjust your scripts to respond to new detection methods or update them as needed. Personal Growth and Skill Development: Learning to code, even if it’s initially for creating bots, provides valuable programming experience that can be applied elsewhere. You’ll learn about automation, scripting languages (like Python or JavaScript), and problem-solving skills that can be useful in various fields. Conclusion: Botting is Inherently Risky, and "Safety" is Always Relative In summary, botting is never entirely safe. The idea of a bot being "proven" safe is largely anecdotal and fails to account for the evolving nature of detection systems, user behavior, and randomness in how bans are issued. While some scripts may offer a lower risk for a period, no bot can guarantee long-term safety. Learning to script your own bots provides a greater degree of control, but even this approach carries inherent risks. Ultimately, the most reliable way to avoid bans, penalties, and other consequences is to steer clear of botting altogether. However, if you choose to pursue botting, do so with the understanding that you're participating in a risky activity where even the best-laid plans can eventually lead to detection.

It only occurs about 20% of the time, particularly when gathering Given the repeatability of it, or lack thereof, it must be something to do with what the script is doing at the time, perhaps pausing the entire script during a sleep somehow breaks the onMessage function? Not sure exactly

I usually keep an eye on my scripts when they are running, and sometimes I pause the script to do something (like hop worlds or something) However, sometimes (not always) when pausing the script, the onMessage loop seems to pause indefinitely thereafter (until the script is restarted) Is this intended behaviour? Is there a workaround? I often use onMessage to count tracked items, particularly for gathering, and the count just gets stuck, but other onPaint functionality works so it isn't the onPaint function.

Awesome congratulations + Look forward to seeing the scripts! No suggestions, just be yourself & good luck

I don't know about current scripts as there is no way to view the source code, however, I do have a hoard of scripts from rsbot which are class files not compiled into jar for some reason... Looking through these, it would appear that most scripts were a collection of class files rather than jar packages... Not sure if that is still relevant, but might help

6 minutes - 10 seconds = 5 minutes, 50 seconds (or 350 seconds)

The more groundwork you lay, the faster it will be to produce great scripts using your existing classes

Sounds like you're making some big improvements, nice work! One other little thing I thought of I should probably mention is: try to make generic "utils" functions, rather than specific ones because it will save you time later Say you are crafting, you could write a function to use chisel on uncut sapphire (with functionality to click sapphire or chisel first, and randomly select the closest sapphire to the chisel generally) OR you could make a general script to use X on Y, with a parameter like "CLOSEST_TO_SLOT_1" or "CLOSEST_TO_SLOT_14" That way, you can use the same function for using longbow(u) on bowstring, with parameter "CLOSEST_TO_SLOT_14" to use a method that (most often but not always) gets the closest item to slot 14 in the inventory, similarly, this could be used for fletching (knife on log) or whatever. Make a good solid function, and you can just reuse it in whatever other scripts you make

GUI is going to scale badly I imagine, would definitely just keep it plaintext where possible public void onPaint(final Graphics2D g) { // calculations here g.setColor(Color.WHITE); g.drawString(String.format("Script Runtime: %02d:%02d:%02d", hours, minutes, secs), 10, 40); } then just use y=60, y=80, etc for each line you want to include I generally just do: runtime items made / gathered on one line xp gained (+level count) XP/hr XP till level Easy enough to keep track, and generally enough info for most scripts I think once you've got pretty solid scripts, the next thing to focus on is weird edge cases... Like 1/1000 times the bot will misclick the bank booth and speak to a banker for example, ideally this kind of edge case should be handled - also things like when fishing, there might be a weird angle where the camera rotates at the exact wrong time and clicks on a random event instead of the spot - if there is a dialogue you should handle this immediately to seem more human-like sometimes it's as simple as just checking for continuable dialogue before a sleep, and if so return 0; to re-run the current script loop immediately, which should attempt to click the fishing spot again for example

It would slow it down for sure, if you are using only one or two it would be fine, but if you had 100 bots it would likely have a significant impact The alternative way to do it (hardware limited) would be to ensure that the script ran every cycle (no sleeps) and built a custom sleep looping method into the main script with a SLEEP state in the stateengine, this way the primary onloop function could do things like animation checks first, but this would also mean building the script in such a way that it never processes logic sequentially, always 1 action per loop... (which is ideal as it is "reactive" then to any weird circumstance, but not always practical)... Or you could just do a special check for animation that involves 2 separate checks, half of the expected animation time apart You'd have to check the impact though, if it only checks once per 500ms and that is all the thread does, it might not have much impact even at 100 bots - it depends how efficiently the CPU handles it I guess

Sadly can't answer that - not got any public scripts, just make them for personal use Java is definitely a lot harder to write, not a big fan to be honest, but getting the hang of it Few things I found helpful: I use a class called V for my variables, I find that makes the main script more manageable, can just call V. for those, means you don't have to clog the main script up public final class V { public static final int[] EXPERIENCES= { 0, 0, 83, 174, 276, 388, 512, 650, 801, 969, 1154, 1358, 1584, 1833, 2107, 2411, 2746, 3115, 3523, 3973, 4470, 5018, 5624, 6291, 7028, 7842, 8740, 9730, 10824, 12031, 13363, 14833, 16456, 18247, 20224, 22406, 24815, 27473, 30408, 33648, 37224, 41171, 45529, 50339, 55649, 61512, 67983, 75127, 83014, 91721, 101333, 111945, 123660, 136594, 150872, 166636, 184040, 203254, 224466, 247886, 273742, 302288, 333804, 368599, 407015, 449428, 496254, 547953, 605032, 668051, 737627, 814445, 899257, 992895, 1096278, 1210421, 1336443, 1475581, 1629200, 1798808, 1986068, 2192818, 2421087, 2673114, 2951373, 3258594, 3597792, 3972294, 4385776, 4842295, 5346332, 5902831, 6517253, 7195629, 7944614, 8771558, 9684577, 10692629, 11805606, 13034431 }; public static final Area areaFishing = new Area(3107, 3436, 3110, 3430); etc... I wrote a custom sleep function that handles conditionally sleeping by loop checking on a delay, but it has added functionality like mouse-out chance and stuff, so that is handy to just call Sleep.sleep(maxTime, ()->boolean); If you need to check animations, might be good to make a utility class for that, which starts a new thread that checks when you are animating repeatedly and updates the last animated time, that way you can check a custom function like hasAnimated(withinLastSeconds), rather than directly checking isAnimating() - probably a bit memory intensive, but since there is often a delay between animations it avoids that (think smelting) using a StateEngine is a bit of a cumbersome way of writing stuff, but it is tidier than lots of if-else It was all the static vs. non-static that confused me initially Hope I've been some help anyway! Still learning myself

Basic, but looks like it is functional Consider using conditional sleeps (wait until bank is open for example) rather than a set delay time Also consider using states to handle actions, because the if-else can become extremely long and confusing for a more complex script Quick search on google for states, kind of gives you an idea. The antiban is unnecessary IMO, don't think mouse movement is really monitored, but mouseout on breaks sometimes might be good Better antiban you could add would be to: 1) get the location of the tree object you are cutting 2) check objects at that location to see if it is cut 3) return from break early sometimes when it is cut (e.g. another player chops it) This is also a better way to keep track of them I think

Sweet, good to know it actually works! Not had chance to test it since writing Thanks for the widget numbers! I get the distance part, depends if you are doing static vs dynamic skills Out of curiousity - why not head message?

I'm no expert, but I like to code everything thinking in loops instead of sequentially The main reason being; if you need to handle unexpected events, it is more difficult to implement this in sequential code You could still use craftDartTips() call on each loop, but the logic would be less sequential and more reactive to the situation Khal's example is great for example: loop1: is chisel selected? no: use chisel customsleep (till selected) return 0; loop2: is chisel selected? yes: use gem customsleep (till all crafted) return 0; Obviously with all the appropriate logic there too Scenarios: What if the bot misclicks? What if you get a random event that you want to interact with? i.e. Genie What if you are suddenly in combat? In these cases, since the loop will end quickly or immediately, the next loop with handle these scenarios with priority over the task you were performing Not saying those scenarios are relevant to this necessarily, but planning ahead?

Thanks, that would be awesome! I didn't realise isInteracting() is so broad in scope! It is only following the player, but this is good to know, thanks! I have updated my code: public final class myScript extends Script { private String playerName; ... @Override public final int onLoop() throws InterruptedException { if(playerName == null){ if(getClient().isLoggedIn()) { playerName = myPlayer().getName(); } } else{ randomHandler(); } ... } private void randomHandler() throws InterruptedException { randomGenie(); // Additional randoms later } private void randomGenie() throws InterruptedException { final NPC genie = getNpcs().closest(npc -> npc != null && npc.getName().equals("Genie") && npc.getPosition().distance(myPosition()) <= 1); if (genie == null || !genie.exists()) { return; } if (!genie.isInteracting(myPlayer()) || (genie.getHeadMessage() != null && !genie.getHeadMessage().contains(playerName))) { return; } log("Genie found. Attempting to talk..."); genie.interact("Talk-to"); if(Sleep.sleep(this,3000,() -> getInventory().contains("Lamp"))){ getInventory().getItem("Lamp").interact("Rub"); // Widget code } return; }

This is incredibly helpful, just seeing it in context makes a world of difference compared with reading the documentation; makes it a lot easier to understand what is going on Thanks a lot!

Necropost #2, also interested to see some examples if anyone has any of invokes in actual code? Nice re-discovery, Jelly Looks ideal for a PK script, gear swap/prayer flick/attack style swap on every attack/incoming

Did you ever get this working?

Sadly not, just been using it on my non-jagex accounts

Same issue here, cannot find solution

Still living in hope that we might get an answer on this - it is probably a simple config setting - feel like I have tried everything though Really surprised more people on here don't use linux Also wtf how are there so many MacOS threads? Like usually, this is the issue and the solution is use a different OS How is this happening with linux!?

Excellent, thanks everyone! Back to babysitting the bot in my basement

But then who will babysit the bot?!