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


  • Content Count

  • Joined

  • Last visited

  • Days Won

  • Feedback


IceKontroI last won the day on July 13

IceKontroI had the most liked content!

Community Reputation

296 Excellent

1 Follower

About IceKontroI

  • Rank
    Taking the Turing test 💯💯💯
  • Birthday 03/01/1994


  • Sex
  • Location
  • Bio
    What loser actually writes a bio?

Recent Profile Visitors

3,142 profile views
  1. I'm currently developing an advanced framework to improve on the faults of TRiBot's Keyboard class. If the community and admins assist me in this process I will release the entire source code. To see for yourself, you can use a test script I wrote that observes OSRS client KeyEvents directly: https://pastebin.com/raw/dL0MtDRf. Unless you type with a single finger, you will very likely see how alarming the difference is. Here are some major issues: Typing is not asynchronous. To type the string "ab", the "b" can only be typed after the "a" key has been released. Humans type so that just the presses are synchronized, the releases happen independently. If keys are ALWAYS pressed linearly (and they are), it's easy to see from a KeyEvent log that the player is a bot. Calling Keyboard.sendPress(capitalKeyChar, correspondingKeyCode) will insert a "shift" press event. This is not mentioned in the javadoc. This should be decoupled because it's unintuitive. This directly prevents any scripter from having full control over the base functions typing is comprised of. This is the primary reason I can't write the framework I plan to (and it's almost entirely done). Some events fire incorrectly Typing a single quote (') not only inserts a shift before, but also uses the keyCode for right arrow key (39) instead of the correct one (222). This causes the corresponding events to not properly mimic human behavior: [21:56:57] TRIBOT KEYBOARD [21:56:59] Pressed Shift, code: 16 [21:56:59] Pressed Right, code: 39 [21:56:59] Released Right, code: 39 [21:56:59] Released Shift, code: 16 [21:56:59] ACTUAL HUMAN KEYBOARD [21:57:03] Pressed Quote, code: 222 [21:57:03] Released Quote, code: 222 Not only is the wrong keycode being shown, but also what you can't see is that the press and release KeyEvents have shift modifiers, which would be impossible for a single quote char on most keyboards. I'm sure there are more issues, the Keyboard class seems to have been left unchanged for quite some time. As I've mentioned, I'm almost finished with the framework I'm designing. I just need the decoupling mentioned in bullet point 2 to be taken care of and I'll release it publicly, free, and open source. @TRiLeZ, @Todd, @JoeDezzy1, @erickho123, @Encoded, @wastedbro.
  2. @zippyyy is it consistently on the same VMs each time? Sometimes we try to make connections we think are there but really aren't. I have no way of gauging your objectivity. What percentage of the time does VM A get banned vs VM B? How big is your sample size?
  3. I agree. Proggies and screenshots are easily faked. It's still unclear whether breaks actually matter. This is a band-aid solution. Scripters should be making intuitive GUIs TO BEGIN WITH. An accurate rating system would be very beneficial to the community, however when peoples' accounts get banned they often blame the script rather than themselves. In theory (and not necessarily in practice) this means one of two things: These false ratings will apply to every script evenly, and can easily be corrected by a global score multiplier. These false ratings aren't actually false, and scripts that have a high banrate will be rated lower because people are rightfully down-rating. Overall, the scripters will resist any rating feature because it will change the scripting sales landscape. Scripters that are already established may no longer be preferred by customers. Unfortunately it's the scripters that have the influence needed to implement a change like this. @dondo_supamida
  4. It's been speculated before. Some people use virtual machines to try to get around this but you can still see the hardware IDs through the VM. Others try to use a VPS to get around it and I don't know how effective that is, but it adds a monthly cost.
  5. While it's probably true that they track mouse position, it's not definitive, and it's also not confirmed the only thing they check. I will dig through this deobbed client, but it's likely that any high level analysis against bots is done server-side so it won't be immediately obvious.
  6. This does prove that the OSRS client has access to your mouse, but then again of course it does. Mouse input is a crucial point of interaction with the game world. I couldn't find code to indicate that the mouse position was being used in any sort of bot detection process. From what I could see, and feel free to point what I missed, this is not incontrovertible proof.
  7. Show me this deobbed client
  8. Yeah from what I can tell the only way you can avoid needing membership is if you run a fully automated F2P farming rig, and that comes with its own problems. As for good ways to make money, you'll need to find out for yourself. I doubt anyone will give you their methods/scripts.
  9. Einstein's scripts tend to have really good antiban. That all kinda disappears if you're running F2P though. It generally doesn't matter how good the script is, Jagex tends to be much more trigger happy banning F2P vs. members. Expect your F2P accounts to have significantly shorter lifespans than P2P accounts on principle.
  10. Alright so I'm just gonna preface this by saying what I'm doing is completely unreasonable and excessive, but I'm doing it anyway. I'm effectively rewriting the TRiBot Keyboard typing functions to have a lot of built-in realism. The new functions will do things like automatically make typos and correct them, and will use a finger-queue system to emulate realistic human typing. I'll be using only the following Keyboard functions: sendPress(), sendType(), and sendRelease(). In the KeyEvent class there are various VK (virtual key) constants like VK_BACK_SPACE and VK_ENTER that hold int values corresponding to those keys. I'm wondering if it's appropriate to use those in the following scenarios: If I wanted to capitalize a letter, would I do: sendPress((char)VK_SHIFT, getKeyCode((char)VK_SHIFT)) // Instead of casting it to char and calling getKeyCode() on it, couldn't I just use the int value AS the keycode? sendType(CHAR_UNDEFINED) sendPress('H', getKeyCode('H')) // Should the char be 'H' or 'h'? sendType('H', getKeyCode('H')) sleep sendRelease((char)VK_SHIFT, getKeyCode((char)VK_SHIFT)) sendRelease('H', getKeyCode('H')) If I wanted to press backspace, would I do: sendPress((char)VK_BACK_SPACE, getKeyCode((char)VK_BACK_SPACE)) sendType(CHAR_UNDEFINED) sleep sendRelease((char)VK_BACK_SPACE, getKeyCode((char)VK_BACK_SPACE)) I know this is an uncommon topic as most people use the built-in Keyboard functions without problems. Since I'll be using the keyboard a LOT, I figured I would focus on the details a little bit more than normal and try to innovate a stronger human profile in this area. I'll be posting the source code when it's completed.
  11. I've run into this problem before. I made a click function called click(RSItem item) that clicks that RSItem and then caches it. I had a getter function to retrieve that cached item called getLastClickedItem(). Then I made a boolean function called isInventoryItemSelected() that checked Game.getUptext() to see if I had an item selected. Finally, I would do something like this: if (isInventoryItemSelected()) { click(getLastClickedItem()); } @Peshmerga
  12. Do you think having multiple clients all set up on different cores via task manager would create some sort of manual multi-threading?
  13. If you do plan on implementing price checking to combat this, I would advise you to do it cautiously, as other have previously stated. Intentionally reducing those margins by a few GP or some percentage wouldn't hurt profits much and would be more sustainable.
  • Create New...