Fanny

Wow that does look very neat. Yeah, mine looks nothing like that. Not sure where I went wrong, the other classes are what should be my dependencies like you have it Also my script is the entire project? You seem to be able to access individual projects from the same screen Dunno about IntelliJ Idea, my setup is more like No Idea

When I started out with OSBot scripts, I used this guide which was very helpful - thanks @Token I am still unfamiliar with intellij though really - I can output scripts, but that is about it - I am limited to a directory of classes, which has been OK so far However, moving forward, I would like to make a library similar to the osbot.jar file whereby I can import my classes in a similar way for example; import org.osbot.rs07.api.ui.Skill; import org.fanny.utils.whatever; How do I go about this in intellij idea? This is a pretty major step to producing scripts faster and more accurately

private Item selectItemFromInventory(String itemName) { List<Integer> itemSlots = new ArrayList<>(); for (int i = 1; i <= 28; i++) { if (getInventory().getItemInSlot(i) != null && getInventory().getItemInSlot(i).getName().equals(itemName)) { itemSlots.add(i); } } // If the item exists in any slot, return the last one if (!itemSlots.isEmpty()) { int lastSlotIndex = itemSlots.get(itemSlots.size() - 1); // Get the last index return getInventory().getItemInSlot(lastSlotIndex); // Return the last item } // Return null if no item was found return null; } Just off the top of my head (untested)

I mean, it's a 23 year old, crappy (by todays standards) java game at the end of the day... Oldschool launch was squeezing the teat a bit, but these days with all the speedrunning servers, deadman mode, etc, they're having to squeeze pretty hard to milk every last cent... The whole game is dwindling. It isn't attracting new people, particularly since the majority of young people these days need instant gratification which this game definitely is not, although even the level grinds are less of an accomplishment now as there are so many ridiculously fast ways to train skills that used to take months of botting.

It sounds like user error tbh I mean, for starters, hand training, then botting on brand new accounts? They are more likely to get banned if brand new regardless, but mixing methods can be a clear indication of botting since the average behaviour drastically changes between hand training and botting Also, what scripts are you running? Suggestion would be run a better one...

Tried and failed this myself - seems like nobody else runs linux on here surprisingly! Even mac is more supported!! My solution was to only use legacy accounts...

What use cases are you thinking?

Nice script! Just a thought, but maybe an area of improvement might be to make a custom sleep class/function, with optional "antiban", although I must say, I haven't found that the addition of antiban type features actually does reduce ban rate private void waitForChop(Entity tree) throws InterruptedException { while (tree.exists() && !getInventory().isFull()) { sleep(random(1000, 1500)); triggerAntiban(); // Trigger antiban during chopping } } Here for example, you are waiting a fairly fixed amount of time, then performing an antiban action It would be better to write a class hosting a function that runs a while loop that sleeps every 50ms or so, and boolean checks for the tree to be chopped, however, unlike conditionalsleep function that already exists, you can add antiban into the loop such as changing tabs, examining a random nearby object, etc You would have to refactor the % chance though to accomodate for the while loop running so often

A Venezuelan? Your IP may be flagged, or may not - difficult to say. Don't bot on any account you are not willing to lose

Nice work! If you are looking for potential improvements, I'd consider adding some logic to check that the emote succeeded by checking the players animation state continuously, if you can be bothered, you could even check the animation IDs to ensure that they did play in the right order too Also conditional sleeping until the emote is finished or varying the time between emotes

Not had any issues so far

See other thread:

The requirement to verify your identity during login is a crucial part of the security measures implemented by many services, including bot managers like OSBot. I understand that it can be a bit of a hassle sometimes, but there are several critical reasons behind it. Let me break down the details for you. 1. Understanding Multi-Factor Authentication (MFA): Verification prompts, like those that require you to enter a code sent to your email or phone, are commonly part of Multi-Factor Authentication (MFA). This process is designed to ensure that even if someone knows your password, they still can’t access your account without a second form of verification. Think of it as adding another lock to your door—just because someone has the key doesn’t mean they can easily break in. 2. Preventing Unauthorized Access: In the botting world, accounts are often targeted by unauthorized users for various malicious activities. Once a botting account is compromised, the damage can be significant, not just for you but also for the platform itself. By introducing a verification step during login, OSBot is ensuring that any unusual login attempt—like logging in from a different device, IP address, or location—is challenged with a verification prompt. This way, if a malicious actor tries to access your account from a different country or even a different city, they’d be blocked unless they have the verification details. 3. Dynamic Security in a High-Risk Environment: Botting platforms, due to their nature, are more susceptible to attacks and breaches. Verification steps are often dynamically triggered based on risk factors. For example: Device Recognition: If you usually log in from a PC and suddenly try logging in from a mobile device, that’s a flag. IP Address Changes: If you log in from one IP address today and a vastly different one tomorrow, the system might request verification. Unusual Activity Patterns: Sudden spikes in activity, like running multiple bot scripts at once, can trigger security prompts to confirm that it’s actually you making those changes. 4. Bot Managers and Account Safety: OSBot, like other similar platforms, likely uses a combination of automated systems and algorithms that determine when verification is needed. This is especially crucial for users who engage in high-volume botting or switch accounts frequently. Verifying your identity ensures that your assets (bots, scripts, configurations) remain secure. 5. Reducing Potential Account Recoveries: A lot of platforms deal with account recovery requests due to compromised credentials. By implementing a verification step, OSBot decreases the likelihood that they’ll have to process recovery claims. The more layers of security in place, the harder it is for someone to compromise your account in the first place, reducing recovery demands overall. 6. The Human Factor: Remember that even if you’re cautious with your password, many people are not. Password reuse is rampant—people often use the same password across multiple sites. If one of those sites suffers a data breach, hackers could potentially use your credentials to access your OSBot account. Verification steps help to mitigate this risk. Conclusion: While it might be inconvenient at times, these verification prompts are in place to safeguard your account, your progress, and ultimately your time investment. Every time you’re asked to verify, it’s a reminder that OSBot is actively working to keep your account secure from unauthorized access. The security benefits far outweigh the occasional inconvenience, ensuring you can continue botting with peace of mind. Hopefully, this gives you a clear idea of why you’re encountering verification prompts and why they’re actually a good thing in the long run. If you’re still facing issues or have questions, feel free to ask—there are always people around willing to help!

Wow, you're on fire with these releases... Literally with this one! Had a quick glance over it, looks good!

Very nice, looks good!

Probably best to abandon the account for a while, and return to it in a few months

Agility is an extremely high ban risk skill nowadays Would not bot more than 30 mins to 1 hr at a time, maybe work your way up to longer periods as your agility level increases. Regular play times also help.

I have actually been putting off writing a combat script since I started scripting OSBot All my scripts are skilling and buying/selling I reasoned to myself that until I can write scripts pretty flawlessly, it is going to die a lot!! Without overcomplicating the food eating, you could perhaps implement a new int eatBelowHealthMin if (enableEating && getSkills().getDynamic(Skill.HITPOINTS) <= eatBelowHealth) { boolean shouldEat = false; // Always eat if health is below eatBelowHealthMin if (getSkills().getDynamic(Skill.HITPOINTS) <= eatBelowHealthMin) { shouldEat = true; } else { // 3% chance to eat when below eatBelowHealth but above eatBelowHealthMin if (RANDOM.nextDouble() <= 0.03) { shouldEat = true; } } if (shouldEat) { if (getInventory().contains(selectedFood)) { log("Eating food..."); getInventory().getItem(selectedFood).interact("Eat"); // Set sleep down to 1000 to prevent locking out your script after failing to eat i.e. misclick or something new ConditionalSleep(1000) { @Override public boolean condition() { return getSkills().getDynamic(Skill.HITPOINTS) > eatBelowHealthMin || !getInventory().contains(selectedFood); } }.sleep(); } else { log("No food in inventory while trying to eat, walking to bank..."); currentState = State.WALK_TO_BANK; return; } } } Yeah the world hop is fair enough, it's a thought for later, but most importantly it works for the minute!! For the looting, maybe something like this: (implement a list of priority items) private List<String> itemPickupAlways = Arrays.asList( "item1", "item2", "item3" ); private void pickupLoot() { if (enableLooting) { GroundItem loot = getGroundItems().closest(item -> itemsToLoot.contains(item.getName()) && npcAreas.get(selectedNPC).contains(item)); if (loot != null && loot.exists()) { boolean inventoryFull = getInventory().isFull(); boolean isPriorityItem = itemPickupAlways.contains(loot.getName().toLowerCase()); // If the inventory is full and the loot is a priority item, handle freeing space if (inventoryFull && isPriorityItem) { boolean spaceFreed = false; // Try to eat food if available if (getInventory().contains(selectedFood)) { log("Inventory full, eating food to free space..."); getInventory().getItem(selectedFood).interact("Eat"); spaceFreed = new ConditionalSleep(2000) { // Wait for the eating action to complete @Override public boolean condition() { return !getInventory().isFull(); } }.sleep(); } else { // No food available, drop the least valuable item to free space log("No food available, finding least valuable item to drop..."); Item leastValuableItem = getInventory().stream() .filter(item -> !itemPickupAlways.contains(item.getName().toLowerCase()) && !item.getName().equalsIgnoreCase(selectedFood)) .min(Comparator.comparingInt(item -> getItemValue(item))) // Assuming you have a method to get item value .orElse(null); if (leastValuableItem != null) { log("Dropping least valuable item: " + leastValuableItem.getName()); getInventory().drop(leastValuableItem); spaceFreed = new ConditionalSleep(2000) { // Wait for the dropping action to complete, but not too long! @Override public boolean condition() { return !getInventory().isFull(); } }.sleep(); } else { log("No suitable item found to drop."); } } if (!spaceFreed) { log("Failed to free inventory space for priority item."); return; // Exit if space couldn't be freed } } // Proceed to pick up the loot if there is space if (!inventoryFull || isPriorityItem) { log("Picking up loot: " + loot.getName()); loot.interact("Take"); new ConditionalSleep(3000) { @Override public boolean condition() { return !loot.exists(); } }.sleep(); } else { log("No space to pick up loot: " + loot.getName()); } } else { log("No more items to loot."); currentState = State.FIGHTING; } } else { log("Looting disabled, returning to fighting."); currentState = State.FIGHTING; } } // Helper method to get the value of an item - you could hardcode or retrieve values from DB or wiki or something private int getItemValue(Item item) { switch (item.getName().toLowerCase()) { case "iron ore": return 100; case "steel bar": return 300; default: return 1; } }

Looks like a pretty solid script! I haven't had chance to look over it in great detail, but a couple of little concerns/tips: 1) Loot looks like it would probably loop indefinitely if there is an item that cannot be picked up (i.e. inventory full or ironman and its not your loot) - also consider players would eat regardless of HP to relieve an inventory slot for certain pieces of loot 2) Perhaps for the hop worlds logic it would make more sense to keep an average of the number of players in the local vicinity over a short period of time (1 min), and if it goes above a certain number for a certain amount of time then hop... Or an average of how many attackable NPCs there are even better! 3) The eating food logic looks like it would work fine, but on low-hitting mobs, it will be very obvious over time that you always eat at a specific hp level, perhaps consider checking the NPCs max hits, and consider having a random chance to eat on each loop below a certain hp, but 100% chance to eat before you enter 1 hit range? 4) I'd also break the conditional sleep AFTER attempting to eat on being within 1 hit range (so you tried to eat before, but if that failed, you will definitely try again quickly instead of waiting out the sleep!)

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.