Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won

  • Feedback


IceKontroI last won the day on October 16

IceKontroI had the most liked content!

Community Reputation

110 Excellent


About IceKontroI

  • Rank
    IRL Bot
  • Birthday 03/01/1994


  • Sex
  • Location

Recent Profile Visitors

1,347 profile views
  1. {New Release} Market Buddy - AIO Flipper Utility

  2. [ICE] Market Buddy Market Buddy is the ultimate utility script for both manual flippers and users of merching scripts. It's a free and feature rich application designed to provide meaningful feedback to users and botters that flip items on the Grand Exchange. Typically you're only able to run one script at a time on TRiBot, however MB can be run alongside other scripts which makes it compatible with scripts like Tau Grand Exchange. MB doesn't actually perform any actions or antibans in-game so it won't interfere with any script you decide to run with it. This is also the reason this script has a banrate of 0. The only thing to worry about is the banrate of another script you might be running with it and whether or not the TRiBot client is detectable (it's not). It's free, why not give it a try? Features Can be run alongside other scripts Simply activate this script first and you'll find you can run another script after User friendly interface to display information Detailed tooltips for each piece of data on display Can be toggled on/off under settings menu Tracks total profit while using the script Profit per hour Total profit Return on investment (in parentheses) Total profit / Total spending Only takes completed offers into account Displays how much profit each item is bringing in Profit / Time spent being traded More intuitive formula than Profit / Script runtime Displays margin as a percentage of average buy price in parentheses Visual breakdown of how your time is being spent on each item Comprehensive breakdown of the item's trade volume statistics Update mode Average amount of progress made on offers Average time it takes to increment progress for an offer Minute view Quantity traded (bought and sold) in one minute Tracks your progress and buy limits Overall mode Total sold / Total bought Buy limit mode Total bought / Item's buy limit Resets progress every 4 hours Screenshot FAQ What's the banrate of this script? There is no banrate as it doesn't actually perform any actions in-game. Banrate can come from other sources like client detection and any script you run alongside it. What do you mean you can run this alongside other scripts? Run this script first, then you'll find you can run another script immediately after. Can I turn off those annoying tooltips? Yes, you can do this through the settings menu. Why is my Net Profit (Hourly) not as good as the profit of some of my individual items? This is probably because you made a lot of cash quickly from those items but didn't spend a long time trading them. If you make 1000 GP trading 1000 Nature runes in the span of 30 seconds it's going to be a lot of money during those 30 seconds. But the Net Profit (Hourly) is based on Market Buddy runtime so that 30 seconds will have only a small impact on say 1 hour of MB runtime.
  3. Beautiful, worked perfectly. Is this a custom jar for tribot or would this also work with other types of obfuscation?
  4. Just uploaded a script to the repository, the GUI uses JavaFX. It seems the Controller class doesn't work at all, none of the FXML objects like VBoxes and Labels are being initialized from the FXML document, however I'm still able to launch the FXML document. I'm sure it has to do with the unique way Tribot requires you to run FXML applications because the program is completely functional when I launch it from my local files. I can confirm the initialize() function doesn't work and that FXML objects are not being initialized when the controller is being loaded. Any ideas what's going on?
  5. Delete this please :]

    Please delete, meant to post somewhere else. Thank you!
  6. How are buy limits calculated?

    Anyone know how OSRS buy limits are calculated? I know it's a certain amount every 4 hours, but I just bought 12k cosmic runes, sold them, and was able to buy more. Same thing with cooked lobsters, bought 6k of them (known buy limit), sold some, then was able to buy more. These are known buy limits, found here http://oldschoolrunescape.wikia.com/wiki/Grand_Exchange/Buying_limits. Does OSRS limits work differently than RS3? I read somewhere that selling items back allows you to buy more but that was posted in 2011 which is before OSRS even came out.
  7. Pattern Breaking and Account Preference

    I never noticed it until I started looking for it which was recently, but you can semi-reliably make it happen like I stated at the beginning. Yes, ABC2 does use this, but doesn't allow a scripter to apply it to custom methods. A scripter can add in multiple ways of doing a process and prioritize those ways across different accounts by using the functions I've provided at the end. I'm really just publicly advocating variety in activity both from a single account perspective and across multiple accounts. This could be used to improve the longevity of both the account and script.
  8. Hello, everyone. Recently I've been interested in how Jagex's pattern detection works. I ran a simple easily detected script which opens the GE, buys 1 lobster at 100 GP, waits 30 seconds, then cancels the offer and closes the GE on a loop with tribot's AI antiban turned off. After a few minutes of runtime some abnormal things started happening. Most commonly my input to the game was blocked, meaning I could move my mouse around, but the game server never accepted my input, and as a result my account's actions had no effect on the game world. I've been able to semi-reliably recreate this scenario multiple times on different accounts and IP addresses. It's worth noting that players and NPCs continue their normal action while my account's been frozen, which also indicates no connection errors. The input blockage happens fairly often to the point that it's very unlikely it has anything to do with my network connection or Jagex servers. I believe this is Jagex's first line of defense against bots (or at least one of them). Real players will typically try to perform various actions in-game like arranging inventory, clicking on random tiles or objects, world hopping, and even restarting the client. Bots may repeatedly click the same action (big red flag) or do nothing (moderate red flag) I have no doubt that botters/scripters with more experience than me have noticed this, but this is not a thread about Jagex input blocking, it's about preventing it from happening through pattern breaking. Pattern breaking is centered around the imperfections and variability of the human mind and judgment. Regular player activity does form patterns to some degree, but typically it isn't as pronounced as those of bots. There are two categories of pattern breaking: Large scale More useful for public scripts or large farms Focuses on creating differences between accounts through account preference Different methods of performing tasks Different subsets of antibans per account Each account may be only able to use 7 out of 12 generic antibans available for the script This increases the longevity of the script by allowing less opportunities for Jagex to group accounts via similar actions Different frequencies of antibans per account Account A may perform one antiban more frequently than account B Changes in sleep and delay times per account Accounts all have different run times This is mainly for farm detection, not for public scripts Different accounts running the script in different worlds/locations if possible Unique break patterns per account Different muling cycles Small scale Focuses on preventing accounts from producing patterns through their actions Changes the order of sub-actions within a larger action when order does not matter More useful when incorporated as part of a complex script process Avoid hardcoding script processes as first A, then B, finally C Instead use fluid condition checks to see what action should be performed Then use account preference and probability to determine which of several actions it prefers over the others Action[] actions = getActions(situation); // This should perform action condition checks and return only relevant actions boolean performed = false; for (action : actions) { if (accountPrefers(action) && accountProbability(action)) { performed = performAction(action); if (performed) { break; } } } if (!performed) { performAction(action[General.random(0, action.length)]; } While this may seem excessive, this is how players decide what to do next in a sequence of events Antiban is a large part of pattern breaking Performing actions you don't usually do is an effective way to break patterns Misclicking can be seen as a form of antiban as it's infrequent but deviates from your normal activity Avoid randomization Randomizing everything from antibans to sub-actions within a larger action schedule may seem like an appealing idea While it's likely to work to some degree, it will make accounts on the large scale appear too similar to each other We're trying to get our accounts to operate in the grey area between a well defined pattern and no pattern at all If all accounts operate in this grey area their patterns will be loosely defined but dissimilar from each other The idea of pattern breaking shows promise, however it has many requirements. One of which is account preference which is something Tribot has some support for, but this support is limited. For example a scripter has no way of applying Tribot preference to custom made functions. The solution is to make your own preference system where the account's username and a seed value is used to derive a value from 0 to 100. Below is my own way of doing so: /** * Performs a probability check on the input value. Input a percentage (0 - 100). */ public boolean chance(double chance) { return General.random(0, 100) <= chance; } /** * Scales a value based on its original range so that its position in that range is in the same position in the new range. */ public double normalizeValue(double value, double oldMin, double oldMax, double newMin, double newMax) { double percentage = (value - oldMin) / (oldMax - oldMin); return newMin + percentage * (newMax - newMin); } /** * Generates a username based preference value for the given seed (0 - 100). */ public double preference(double seed) { try { String hash = Double.toString(Player.getRSPlayer().getName().hashCode() * Math.sqrt(seed)).replaceAll("[^\\d.]", "").replaceAll("\\.", ""); String int1 = Character.toString(hash.charAt(hash.length() - 1)); String int2 = Character.toString(hash.charAt(hash.length() - 2)); String int3 = Character.toString(hash.charAt(hash.length() - 3)); return normalizeValue(Double.parseDouble(int1 + int2 + "." + int3), 0, 99, 0, 100); } catch (NullPointerException e) {return 50.0;} } /** * Generates a username based preference value for the given seed, but normalized to match the provided range. */ public double preference(double seed, double min, double max) { return normalizeValue(preference(seed), 0, 100, min, max); } /** * Performs a probability check on a preference value normalized to match the given range. */ public boolean preferenceChance(double seed, double min, double max) { return chance(preference(seed, min, max)); } Hopefully I've included all the necessary functions for the above to work. If you for example wanted to test an account's preference for performing Action A over Action B, you could take the hashcode of each actions, remove all non-integer characters from each, input them into the functions above, and receive a preference for each. I recommend using custom ranges like preference(100, 15, 85), where 100 is the seed, 15 is the min chance, and 85 is the max chance. That way the preference range will always be within 15% and 85% and you won't ALWAYS or NEVER perform that action above other actions. It should also be mentioned that you shouldn't be using these preferences to determine which actions to do, only to determine which actions should be performed above other actions. All actions should be performed as long as they're part of your script. This post ended up being much longer than I originally wanted but it's good to get your thoughts out in writing so I'm glad I spent the time. Going forward I would appreciate a healthy discussion, please add to the thread with your comments rather than just taking up space with pointless nay saying.
  9. Delay on Mouse.Drag

    No idea why but it's been quite annoying for me as well. You can always write your own drag function, here's a basic one: I would recommend using your own sleep times instead of the random ones I just put down, but this is the basic structure you'll need.
  10. Noob-account leveler

    A while back I saw a guy training on giant rats in Lumby castle backyard area. He was killing rats, then chopping trees and cooking the meat to heal while getting combat, woodcutting, and firemaking experience. I thought it was a sweet trifecta, not sure if it would be good for this script but hey just throwing some info out there.
  11. How would I read this?

    There's a cool utility that I want to be able to use programmatically. How would I read data from it? Is there a way I could scrape for example how many players were online at 12:00 last Sunday through Java code?
  12. Grand exchange buy second item

    @jelledrc Not sure if you're willing to build your own method for this but if you are, this should put you on track. Look into interfaces. Here's some code that selects the relevant search result from a list. It's very basic, so it can't handle scrolling to find a relevant result at the bottom of a list or anything. String fullName = "Pot"; RSInterface[] searchResults = Interfaces.get(162, 38).getChildren(); for (int i = 0; i < searchResults.length / 3; i++) { String textResult = searchResults[i * 3 + 1].getText(); if ((textResult.toLowerCase()).equals(fullName.toLowerCase())) { // TODO Here is where you would click the interface break; } } The reason I divide the length by 3 is that 3 interface children apply to each separate result. There's one for the image, one for the text, and one is a selection box. What this does is iterate through each result (series of 3 children) and compare the text of that result with the String variable fullName which in this case is "Pot".
  13. time to blow the dust off my scripts

    People favor Dax's webwalker vs Tribot's, and Mute's working on rewriting his AIO slayer script last I've heard.
  14. Question regarding Botting/Bans

    I believe the only time they ban one account because another one is botting is when they think it's part of a gold farm.