Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited

  • Days Won

  • Feedback


Everything posted by IceKontroI

  1. IceKontroI

    Christmas Money Advice

    With the 300 dollars you should buy an apple watch, wear it for 2 weeks, realize it's garbage, then sell it used on ebay for a loss.
  2. IceKontroI

    Filter class deprecated

    Lambdas are just super useful and clean the code up. It's probably best for TRiBot to shift over to that style of coding anyway.
  3. IceKontroI

    [I][FREE] Taking Script Requests

    A script that sits in the GE and casts teleother camelot repeatedly on spam-bots while saying clever one-liners. The script should mine bitcoin in a concurrent thread.
  4. IceKontroI

    [Suggestion] Best Antiban yet

    Mouse movements already don't have to be emulated at all. Some players in the OSRS userbase reported getting banned when they started playing RS through a touchscreen computer. Soon after these reports, Jagex changed their detection methods to exclude that criteria. As a result, these reports are no longer a thing. That means that the actual mouse movement processes aren't likely to contribute to banrates so reverse-engineering the new mobile client isn't likely to yield any improvements in banrate.
  5. IceKontroI

    Any suggested Agility scripts?

    Nobody's gonna mention Einstein's Relative Agility script? He just released it and new scripts typically have low banrates. Einstein is a great scripter, and that script has pretty good antiban. It's also only $1 right now if I recall correctly. I've not tried the script myself, but it's probably worth checking.
  6. IceKontroI

    OSRS gold transfers across accounts

    Might not be quantity based, could be frequency. Or could be a combination of both, or more factors could play a role.
  7. What other than botting do you plan to use the rig for? If it's purely for botting, just get the SSD since you only really need enough for the operating system, java, tribot, and the jagex cache.
  8. It'll probably be better if you pay the same amount for more GBs of DDR3 RAM. You won't need fast RAM, just lots of it if you want to run many clients. Good that you didn't get a GPU, you won't need one as long as you have onboard graphics. CPU might be a bottleneck depending on how many gigs of RAM you end up getting, but it really depends on how large you want to scale things.
  9. IceKontroI

    Account Banned. Lessons from it for better botting.

    +1 @Naton sample size is 1, which is a statistical no-no. From years of experience, I can say: Script quality is important, but so is the skill you bot and the location you do it in. Part of the banrate comes from player reports, the rest comes from Jagex detection methods. I agree that hiding in a crowd makes it less likely to get player reported. You take more scrutiny in a small crowd so this affects player bans. So you pretty much nailed this one. There is a lot of anecdotal evidence to suggest that getting some quests does help improve a bot's lifespan. Whether this is from the QP or EXP gained from the quest, it's unclear. But if anything, it's only likely to hurt your account's lifespan if you bot the quest. Some users report they get more 2-day bans when they use a real-world payment method (and have recurring payments on). Other than that, it's simply more cost effective and convenient to use bonds. This most likely only is an issue if you're worried about player reports. Combine suspicious behavior with a suspicious name and it'll increase your odds.
  10. IceKontroI

    Low fps with *decent* rig (Regular client)

    What does task manager say your CPU usage is when running 2+ clients? I find when I hit the 50-60% mark my FPS starts to get worse. @filthyfrank Also I've not noticed that upping the heap size improves FPS unless your script is garbage collecting several times per second because it's creating MANY objects at an excessive rate. I would go back to the default 386 unless you have a really good reason to be at 1 GB per client.
  11. IceKontroI

    Cutscene/Instance detection

    If none of the above work, you can look for changes in camera pitch/yaw if your cutscene changes that on its own. It's certainly not the best solution but it could work. Also keep an eye out for interfaces that disappear, you can the use interface.isBeingDrawn() == false as an indicator that the cutscene has started. But try https://tribot.org/repository/script/id/1480-varbit-explorer/ or https://tribot.org/repository/script/id/947-sigma-setting-explorer/ first to detect changes in varbit/settings first as that is the ideal solution to your problem. @grand wizard
  12. IceKontroI

    Relative Agility - Written by Einstein

    Dude... I gotta give credit where credit's due. You really made that theory of relativity pun work.
  13. IceKontroI

    What's the thing you'd like to see the most?

    Bitcoin mining during breaks. It's not client related, but I would like to see the RS3 section of the forums removed. Also it would probably benefit the new users a lot of there were a sort of official post that was stapled to the front page with common questions answered, or that at least points to a post that does answer it.
  14. IceKontroI

    How delayed can a ban be?

    Most users worry that when scripts get stuck they trigger some sort of "obvious bot" alarm, but Jagex probably isn't watching for when bots break as that rarely happens. The most common state a bot is in is a fully functioning one, not a broken infinitely looping one. Doesn't it make more sense for Jagex to focus on the more common state and let the playerbase use the report system to detect broken bots? If your account is to get banned as a result of this bug, I'd put my money on some player reporting you, not some detection system.
  15. IceKontroI

    tribot down

  16. IceKontroI

    Laniax's Event Dispatcher

    Always good to see code that improves the scripter's flexibility. Thanks!
  17. Overview A while back I had to create an implementation of a Server and Client communications system for a personal script of mine. My implementation was shit. Here's a much better one. It's still a bit unrefined so if you have an improvement, post it and I'll consider it for revision. The implementation for a lot of the class events is abstract, meaning the user determines what he wants to do when those events fire. Both Server and Client feature a heartbeat system, where after a certain time interval, the Client will send some info to the Server to let it know it's still alive. Likewise every time interval the Server does the same, but for each Client Connection it has saved. Servers and Clients both always have threads open which wait for Objects to be read. When an Object is read, an event will be fired as mentioned below. If the Object read is a Request (covered later on), then it will be displayed through a separate designated event. Implementations of the following events are not mandatory. If you don't want to handle certain events, simply create a constructor for the Server/Client, but leave the blocks for the unused event blank. Server events public abstract void onConnectionGain(Connection connection); Fired whenever a Client successfully connects to the Server, providing you the Connection that was just established. public abstract void onConnectionLoss(Connection connection, Exception e); Fired whenever a Connection is dropped, except when the Server closes a Connection manually when its shutdown() method is called. The Exception describes the circumstances that lead to the Connection being dropped. public abstract void onWrite(Serializable object); Fired whenever an Object is written to every Connection in the Server's list of current Connections. public abstract void onWrite(Serializable object, Connection connection); Same as above, but fires once for each Connection in the Server's Connection list at the time of writing the Object. public abstract void onRead(Object object, Connection connection); Fires whenever an Object is received on the Server's end from a Client Connection. Does not fire when a Request is received, the following event handles those cases. public abstract void onRequest(Request request, Connection connection); Fires whenever a Request is received on the Server's end from a Client. This class should handle implementation of how exactly you want to handle Requests. Requests will be covered in detail later on in the post. public abstract void onShutdown(); Fires at the end of Server#shutdown(). Client events public abstract void onConnectionGain(); Fired when the Client successfully established a Connection to the Server. public abstract void onConnectionLoss(Exception e); Fired when the Client's Connection to the Server drops. The Exception describes the circumstances that lead to the Connection being dropped. public abstract void onRead(Object object); Fires when the Client receives an Object from the Server. This again does not fire when a Request is received, that is handled by the event below. public abstract void onRequest(Request request); Fires when a Request is received on the Client's end, from the Server. public abstract void onShutdown(); Fires at the end of Client#shutdown(). Functionality The primary function of a Server/Client implementation like this is to facilitate communication between the Client and Server. Communication can happen across multiple scripts and even multiple computers. They must all be on the same network, however. Reading more than one Object at a time is unsupported (would corrupt underlying streams), and the same for writing. You can, however, read and write at the same time. To set this up, the user must specify which port the Server will be set up on, and then create Clients that attempt to connect to that port. You can do this through the constructors like so: Note the implementations of each event in the example above do not need to contain any actual code, they just need to have their headers. Clients will automatically attempt to re-connect to the Server with their designated port number. If the Server connection is lost while a Client is still online, it will fire a onConnectionLoss(...) event and wait 1 second before reconnecting. If a Client connection drops while the Server is still online, the Server will simply fire onConnectionLoss(...) and do nothing special. When a Connection is dropped, either Server or Client, you won't know about it until you try to read/write to it. This is why both Server and Client implement a "heartbeat" system. Every time interval (0.5 seconds) the Server sends a null Object to each Client, and each Client does the same for its Server. This simply ensures a minimum read/write frequency between the Server and Client so that dropped connections can be handled properly. On read/write from a disconnected Connection, an error will be thrown, which will properly remove the Connection from the Server's list and fire onConnectionLoss(...). Writing Communication between Server and Client is two-way, meaning the Server can send Objects and Requests to any of its Connections and the Client can do the same to its designated Server. A Server can have as many Connections as your heap space allows, however a Client can only have 1 Server Connection. Reads happen automatically via their own threads, however writes must be handled directly by the user. Anything you want to write must be Serializable, otherwise you'll get an Exception. Here's how the write methods work: Server public void write(Serializable object) Simply writes the given Serializable to every Connection in the Server's current Connection list. Fires onWrite(Serializable object); public void write(Serializable object, Connection connection) Writes the Serializable to only the specified Connection. Fires onWrite(Serializable object, Connection connection); Client public void write(Serializable object) Writes the given object Fires onWrite(Serializable object); When writing Requests, if the Request is unfulfilled (see section below), it will appear in the recipient's onRequest(...) event. Requests Finally I'll get to Requests, which is one of the main things I built this system to handle. A Request is a specialized Object, sent to a recipient, with the expectation for it to be returned, but with some modification. A Client may want to send a Request containing a Point with coordinates (-1, -1), expecting it to be returned with different coordinates. Here's an example of what that might look like: Simply extend Request<T> where T is the type of Object you want to be able to modify and implement Serializable so that the Request can actually be sent. When you initialize the Request<Point>, it will contain a Point (or otherwise specified type) variable called "target" which will be null until the Request is fulfilled. To fulfill the Request, simply call Request#fulfill(Object ... args) with the proper argument parameters (in this case 2 ints). The Request will automatically process the parameters in the way specified by your abstract implementation of Request#execute(Object ... args), and update the "target" from null to whatever the result actually is. If Request#execute(...) throws an Exception at any point, the Request will simply be processed as unfulfilled and ignored, even if it is written back to the sender. Here's what Request fulfillment looks like: To send Requests, simply call the Client or Server's fulfill(...) method. It will write the specified Request to the target(s), wait for it to be returned as fulfilled, and then return it. If it doesn't receive the Request within a designated time frame, it'll throw a RequestTimeoutException. Requests use System.nanoTime() as an identifier to ensure the originally sent Request is returned at the end of the method call. This is a failsafe to ensure you don't accidentally return a different Request to the one that was originally sent out. Classes That's it. Here are the classes:
  18. IceKontroI

    [SNIPPET] Event driven local Server/Client framework

    I went back and looked at it and the structure isn't actually redundant. Each try/catch does serve a purpose. I've added comments to show the purpose of each, but essentially the first one is obligatory and doesn't do anything, the second actually disconnects the Connection because of a read failure, and the third prevents the user's implementation of events from shutting down the thread. try { // Initial try/catch to deal with error thrown by serverSocket.accept() Socket socket = serverSocket.accept(); if (socket != null) {  Connection connection = Connection.connectServer(socket); if (connection != null) { onConnectionGain(connection); Thread reader = new Thread(() -> { while (!Thread.interrupted()) { // This gets interrupted at the end of method call disconnect(connection, exception) try { // This one catches specifically read() errors, and forces a Connection disconnect Object object = connection.read(); if (object != null) { try { // This one prevents errors caused by user's implementation of onRequest() and onRead(), but doesn't force a disconnect  if (object instanceof Request) { Request request = (Request) object; switch (request.status) { case FULFILLED: { requestQueue.put(request.nanoTime, new Pair<>(request, connection)); break; } case UNFULFILLED: { onRequest(request, connection); break; } default:  break; // Ignore failed requests }  } else { onRead(object, connection); } } catch (Exception e) {e.printStackTrace();} // Prevent user error from killing thread } } catch (Exception e) {disconnect(connection, e);}  } }); reader.start(); connections.put(connection, reader); } }  } catch (Exception e) {e.printStackTrace();}  connect(); // Extend the connection chain
  19. IceKontroI

    How efficiently does this bot avoid detection?

    Over a long enough timeline, everyone gets banned, even legitimate players.
  20. IceKontroI

    Mac running windows??

    That looks like the default OSRS resolution. If you're trying to get the game to display in full-screen, try changing the in-game setting that enables resizeable mode.
  21. IceKontroI

    How to right click and hover over an option?

    Yeah no direct support. You will want to be using this class, specifically the ChooseOption.getMenuNodes() and then Mouse.move(somePoint) where somePoint is on the RSMenuNode you want to hover over. Make sure you check that ChooseOption.isOpen(), and that the value produced by calling getMenuNodes() != null and has array.length > 0 before you actually move the mouse. Be sure to General.sleep() for a small period (around 10-60 milliseconds) between opening the ChooseOption menu and hovering over the target RSMenuNode. Hopefully that's not too much to take in, but the details are important, especially if you'll be calling this method a lot.
  22. IceKontroI

    This is a sham

  23. IceKontroI

    Bug reporting integrated into Tribot

    Belittling them would be insulting them for not figuring it out on their own. The user is likely to fiddle with some settings or do some research on his own and if no solution is found, then they'll make a forum post. And obviously this isn't an ideal scenario when there are enough resources to serve everyone, but tribot isn't Amazon with 24/7 customer support. It would very quickly become overwhelmed. In an ideal scenario, yes, every little problem can be handled internally by a representative, but that simply isn't possible here. This is of course not even mentioning how difficult it would be to generate, filter, and then sort all these automatic error reports. That's an entirely different logistics issue.
  24. IceKontroI

    Bug reporting integrated into Tribot

    A more valid comparison would be selling computer hardware, but not giving customer support until the buyer has spent at least 10 minutes trying to figure the problem out himself.
  25. IceKontroI

    Bug reporting integrated into Tribot

    Forcing bug reports to be posted to the forums adds a small barrier that makes it slightly annoying to ask for help with them. This is a good thing because usually the first thing people do when a bug occurs is to ask for help. Most of the time, if they spent an extra 5 minutes trying to fix it they realize it was user error and then end up fixing it themselves. Not only does this not bother Tribot support with small issues, but it also teaches people how to solve their own problems.