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

Zully

Registered
  • Content Count

    113
  • Joined

  • Last visited

  • Feedback

    N/A

Community Reputation

10 Good

About Zully

  • Rank
    Botter

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for the link, I was thinking I would need some sort of pathfinding algorithm if I can't use walkingQueue. I probably won't be getting into this now as I've spent too much time on this hoverPoint method and need to get the rest of my scripts running well, but it's definitely something I'd like to add if I get time in the future.
  2. Mental overkill surely, I've driven myself insane accounting for all the factors but it's only math calculations so the call doesn't seem to be affecting my cpu usage that much.. if at all really. Honestly probably going to leave it as is as the method already works great, just guesses wrong if your character changes direction while the mouse is moving. Accuracy is easily above 95% if your character doesn't change direction though, and I actually am using it inside AccurateMouse atm, I just have it call my hover point method instead of the default one. My main goal with this was to remove AccurateMouse's correction pattern on moving targets & differentiate how my scripts click from others which it does pretty well. Edit: No shade to Dax btw, his walker is great and is something I literally couldn't even think of trying to make. I'm just trying to use private functions wherever it makes sense so my scripts don't do things that every script does.
  3. Thanks.. would there be an easy way to figure out which directions my character is going to turn over the next 2-4 tiles? My new humanHoverPoint method is pretty accurate accounting for moving targets although an issue I encountered is when the character changes direction during the mouse movement, as it converts the direction the player is facing to an angle to use, if the player is going to change direction during the movement I need an average angle between the turns the character is going to make during the movement. I already have a way to figure out how many tiles I should be accounting for and figured out how to determine how far I am through the current game tick but I can't find a way to determine which way I'm going to be turning in advance so I can use that to get an average angle for the rest of the method.
  4. I've messed around with seeing what results I get from it, and from what I can tell the results seem pretty volatile I'm not sure how I can work with them. When you first login your current tile is the first bin, when your walking queue gets longer your current tile gets pushed further down the array, and then when your walking queue gets shorter the bins that should be empty keep old data in them so your current tile ends up being somewhere randomly in the array with random outdated data after it. Not only that but when your running 1 direction the array only returns every other tile, as soon as you start changing directions it will return a tile for each turn your making. I wanted to try and use it to calculate an average direction for my new humanHoverPoint method but I'm not sure how I can use the queue to do that now based on how it appears to be working, I'm not even sure how to go about figuring out which result in the array would be your current tile. As even though the results are local, your current tile seems to shift a bit it's not constant.
  5. Couldn't edit the last post.. but after looking into this more I believe what I'm trying to achieve is called a rotation or projection matrix which has pretty much brought me down to the fundamentals of coding in relation to games I think. This is going to take me a bit to learn.. not sure if anyone here could even help me with this I think I just have to go and learn how to do projection matrices on YT. The projection matrix would modify the targets movement angle (movement angle is grabbed from targetMovingDirection+sets of targetTile corners based on direction) and change it based on camera rotation and pitch.
  6. Well that's good that it works for interfaces, I guess it's just Dax's accurate mouse that messes it up because his uses Mouse.moveBox for menuNodes, at least I won't have to generate a point for items or interfaces even though that would be the easy part.. Currently trying to figure out a way to account for player&target movement in my humanHoverPoint method. I have an idea on how to go about it there's just 1 thing I need to do it, is it possible to get the Points of the corners of RSTiles in a way where a certain point is always a specific corner of the tile for example? If I can do that I can get my player or target walking direction, and then get a set of tile corners that corresponds to the direction the target is moving, then measure the angle between those points to get a walking angle in relation to the points on my screen. Then I can use that angle to set the angle of my offset.
  7. I believe RSItems might be the only case where tribot decides on a point to click is accurate, I'm not sure how it handles interfaces but since there is no .getHumanHoverPoint for interfaces I think it clicks fully randomly within the bounds. For Objects/Characters/GroundItems though, hover does not work and needs to be rechecked afterwards to see if it actually moved to the target (to handle your player and targets moving) that is why my goal is to replace the .getHumanHoverPoint method with one that handles all scenarios and accounts for player and target movement. Still working through how I'm going to do it but it's looking like I'll have to use a nested switch for player and target direction and then do calculations in there to determine the offset. Edit: I know you shouldn't need to use threads to move the mouse but there's a bug that deadlocks the mouse thread so how is one supposed to do anything about that other than using their own threads to get past the bug or restart the script whenever it happens. I will have to see how it works out I guess, because I actually don't know what happens with Mouse.getDestination when the hang occurs, which depending on the result could break my fix.
  8. So my approach of running mouse.move in my own threads should work so long as it's properly confirming whether or not the thread it started is stuck? I guess over time as mouse hangs occur it would leave behind threads stuck in a deadlock but I don't think that would be too big an issue? and I figured as much.. I knew we couldn't access the way it generates a path but I thought there might be at least a way to access the Point[] that the method generates, with that I could try rewriting Mouse.move.. I still could try but my option would be either use much simpler path generation or try and make human paths but that's another whole problem on it's own. Currently trying to find a way to make my own hoverpoint method which when called would give you a point that is where the target is estimated to be when the mouse finishes it's movement. I pretty much already know how I can do it, just trying to convert camera position+running direction+target movement direction to a point offset direction then with that I can calculate some movement speeds and spit out a point offset.
  9. I guess this question might be able to be answered by someone here too actually, when the mouse hang bug occurs and it gets stuck in a thread sleep what happens with that thread, does it sleep indefinitely or will it eventually move the mouse? I have a way to bypass the bug if it sleeps indefinitely using threads, my only worry is that eventually it unhangs and I get double mouse movements. (My current solution is to basically start a mouse move thread, wait to see if the mouse starts moving and if it doesn't start moving it starts another mouse move thread)
  10. Not sure where I insinuated that you would do that but that's not what I mean't. You would have a class that starts 2 threads, one for replacing tribots Mouse.move robot wrapper and the other for tracking target position. Every time the tracker detects the target has moved more than X amount (to reduce cpu usage) it would grab a new human hover point and calculate a new path from the current mouse position to the new hoverpoint, pass the new path to the replacement robot wrapper and then when the robot wrapper gets sent a new path from the tracker thread it will update it's path and continue, that way you can do the calculations without having the mouse stop moving mid path to do them. Although after this post I realized a potentially simpler solution to this that I'm trying to work through right now which involves replacing the humanHoverPoint method to generate my own that takes into account player and target movement direction and speed along with how long it will take the mouse to move to the target with my current mouse speed to determine an offset so that when the mouse move is called it will already be moving towards a point that is where the expected target location is. Pretty sure if I implement this second method properly it will have a 100% success rate in clicking.
  11. So I've run into some deep seeded issues with how botting clients work in general around moving targets and mouse movement. I've thought up a possible solution to clicking accuracy on moving targets. Essentially dax's accurate mouse just gets a hover point, moves to it, then checks if the point it moved to is still on the object, if it's not it will move the mouse again, when clicking a moving target almost all the time it will move to the wrong spot(outdated point) and then correct towards the object again, which ends up creating jagged mouse movements and clicks the edge of targets often. My idea to improve upon this is to use 2 threads and essentially rebuild how tribot moves it's mouse, one for moving the mouse and the other for tracking the target, and if the target has moved generate a new path and pass it to the movement thread. (Yes I know this is harder than I make it sound) If you're wondering how I came to the conclusion of attempting to do this I've already tried replacing every layer of input for the mouse and the last one I'm having issues with is tribots internal robot and the fact that it takes a point as input. Currently it's not possible to actually move the mouse towards a target, you can only grab a point on the target and move the mouse there which creates issues when anything moves because the point is not tied to the model.
  12. Nice release! I agree on the script arguments although I think the best way to handle it is have a GUI with presets you can save, and then load presets through args. as using just args might not be easy for a small scale user. Especially with more advanced options like buy lists with prices..not sure how many items you might need in there but the args could get long. Either way whatever you end up doing I'm sure it will work great for the majority of users.
  13. Don't think that's the case.. probably different factors that come into it but I got temp banned on rs3 pre 1000 total and then botted to over 2.5k total after without any bans, and then botted like 11b profit and still not banned so.. They definitely don't track you too much more after a temp if at all. Ik others here have botted long after a temp with success too. If you care about the acc don't do it I guess but if your farming gold with it just keep farming and mule lmao
  14. A quick search came up with this from reddit, not sure how you would handle this scenario but a few people on reddit have complained about getting skulled in the rev caves by auto retaliate. Maybe adding in a check to make sure you aren't skulled, otherwise teleport would cover most of the issue, although I'm sure you could still die before it teleports.
  15. No idea how that's supposed to relate to pst lol.. plenty of rich white people in est, like New york and Miami are both in EST.
×
×
  • Create New...