Jump to content

IceKontroI

Registered
  • Content count

    862
  • Joined

  • Last visited

  • Days Won

    5
  • Feedback

    100%

IceKontroI last won the day on January 20

IceKontroI had the most liked content!

Community Reputation

172 Excellent

1 Follower

About IceKontroI

  • Rank
    IRL Bot
  • Birthday 03/01/1994

Personal

  • Sex
    Male
  • Location
    USA

Recent Profile Visitors

2,013 profile views
  1. IceKontroI

    TRiBot heap & garbage collection

    That's interesting, so essentially it's totally fine to adjust the heap size and have a very active GC since the data is faked and the client doesn't see any of the real stats. Thanks!
  2. I read somewhere that a RuneScape bot client needs to implement similar garbage collection to the actual client as a safety measure against detection. Is this true? And if so, is the heap that's getting GC'd the same as the TRiBot heap? If they're the same, does having a TRiBot heap size other than the default 386 mb increase your banrate? I'm writing a script that receives a large volume of data packets very quickly. These packet objects get garbage collected early in their lifespans since I replace them with new ones very rapidly, at which point they become unreachable. This causes a pretty noticeable fluctuation in heap space as can be seen from the Debug > Heap Space TRiBot menu option since I'm creating a lot of objects, and then they get GC'd the next GC cycle. So the heap is expanding and then contracting on a much larger than average scale. Does anyone know if this has an effect on how detectable the script is, or are the two heaps completely unrelated? My suspicion is that they're different but I can't be sure.
  3. IceKontroI

    Buying vs creating accounts - specific

    I would recommend NOT buying from random people, try to get someone that has a lot of vouches/reputation. The reason for this is that it's EXTREMELY easy in RS to get your accounts stolen. All they need to recover the account they sold you is the original email the account was made on. So if you're planning on doing something like Zulrah and you want to put some high level gear on the account, after a few months you might get "hacked" and lose it all after they change the password. What I recommend is that you first learn botting basics if you haven't already by training many accounts to high combat or whatever the requirements for the method you want to try are. In the end you'll have made several accounts that are ready to go and you'll have also learned some crucial information. The training will go quite fast if you do several accounts at once, and you'll also realize that doing the training in-house is always gonna have a higher payoff than outsourcing the accounts to someone else. Overall you will get banned in this business, and if you invest a bunch of money into buying accounts and get hacked/banned you'll quickly get discouraged and drop the project altogether which would be wasteful. Minimizing your costs is probably the most important thing you can do to minimize the losses that come with those bans, and as a result maximize your goldfarming profits.
  4. IceKontroI

    ?????????

    Yes, as long as it's some version of Java 8 you should be fine.
  5. IceKontroI

    Client bugs??

    This happens frequently to me when I first start the tribot client. For me the solution is to minimize, then maximize the tribot client. Should enable user input after that. Not sure about second bug.
  6. IceKontroI

    Einstein's Woodcutter

    Spot on as usual.
  7. IceKontroI

    ?????????

    make sure when you run tribot you're using one of the Java 8 versions, the Java 10 will prevent tribot from loading
  8. Great, thanks! Wasn't sure where to get started with something like this, that doc will be useful for sure
  9. For next time try tribot > repository > instance manager > kill/end script process.
  10. Interesting, yeah sockets seem to be what I'm looking for. I've no problem doing this with dependencies, it's for a local script which is already set up with Maven. Any word on how this can be done across multiple PCs? Or will it only work on the same machine?
  11. Is it possible to relay information directly from a script to another Java process? My program consists of a master program that does a lot of processing, and several scripts that receive data from that processing. It's set up in such a way that nearly everything the script would need to process is pre-calculated by the master program. Currently I'm serializing data on one end and deserializing it on the other. While this process is efficient, I would like to improve it further. I've looked into IPC (Inter-Process Communication) to improve communication, but before I try to implement it, I need to know if it will even be possible with the way the JVM is set up within TRiBot. So is this possible?
  12. IceKontroI

    Coding Convention

    I think what he meant by "positive" is to keep things as they were originally, since that's what the programmer had in mind when he made the function. And I agree, I intentionally don't invert unless I need to since it's easier to go back and see what my intentions were.
  13. IceKontroI

    Shopping Snippets

    If your validation function is expensive and you call it multiple times unnecessarily, then this is true and you should improve your script structure. But who makes their buy() function also validate when there is already a function dedicated to validation? That's just bad practice.
  14. IceKontroI

    Shopping Snippets

    Damn yeah I was trying to edit the post but the site won't let me. Updated version: /** * In the above function you attempt to get a bunch of variables from the RSInterface, and then afterwards check if the interface is valid. * In my case I didn't cache any variables, however if I were to do so, before caching vars I would check the validity of the RSInterface and return false immediately if wasn't valid. * * Note that I've not cached any variables in the function since they did not need to be cached. * This is a very minor memory improvement, however it will serve you well in the future if you only cached things you were going to use multiple times. * * Since you retrieve the same interface 3 times, why not just cache it once and use it repeatedly? * In this example I've passed it in as a parameter so there's no need to manually cache it as a variable. * * Here I've opted to use the newly added API function Interfaces.isInterfaceSubstantiated(...). * It will check if the RSInterface is valid, being drawn, and not hidden, which is more thorough than simply checking the validity. * * I do some lazy caching for String[] actions, so that if the interface isn't substantiated, it won't go on to cache the actions and will just return false. */ public static boolean buy(RSInterface shopItem, int minStock, String ... amountToBuy) { String[] actions; if (Interfaces.isInterfaceSubstantiated(shopItem) && (actions = shopItem.getActions()) != null && actions.length > 0 && shopItem.getComponentStack() > minStock) { General.sleep(500, 1200); return Clicking.click(amountToBuy, shopItem); } return false; } Variable actions for the shopItem are lazy cached, plus support has been added for sleeping before clicking.
  15. IceKontroI

    Shopping Snippets

    Some constructive criticism written in the JavaDoc of my updated version: /** * The whole function can be simplified by reducing it to a single line of code containing 4 boolean statements. * In the above function you attempt to get a bunch of variables from the RSInterface, and then afterwards check if the interface is valid. * In my case I didn't cache any variables, however if I were to do so, before caching vars I would check the validity of the RSInterface and return false immediately if wasn't valid. * * Note that I've not cached any variables in the function since they did not need to be cached. * This is a very minor memory improvement, however it will serve you well in the future if you only cached things you were going to use multiple times. * * Since you retrieve the same interface 3 times, why not just cache it once and use it repeatedly? * In this example I've passed it in as a parameter so there's no need to manually cache it as a variable. * * Here I've opted to use the newly added API function Interfaces.isInterfaceSubstantiated(...). * It will check if the RSInterface is valid, being drawn, and not hidden, which is more thorough than simply checking the validity. */ public static boolean buy(RSInterface shopItem, int minStock, String ... amountToBuy) { return Interfaces.isInterfaceSubstantiated(shopItem) && shopItem.getActions().length > 0 && shopItem.getComponentStack() > minStock && Clicking.click(amountToBuy, shopItem); }
×