Originally Posted by
MI550
Thanks for the insight about projectiles, I actually don't know anything about the client except it's probably written in ActionScript3 or something like that. But I honestly know absolutely nothing about K-Relay and there's no documentation/information in its post or whatsoever to let me know what is it and what it does.
Overall, I wasn't saying these words to relate to my actual purpose of the thread, enhancing aimbots I was just replying to the dude that talked about anomalies and stuff, but still thank you for sharing the same opinion and suggesting the two approaches.
Speaking of risk of single-threadedness, a small Google showed that there's a 'Worker' API to handle multi-threading, but still don't you think that separating the UI thread from a calculatory aiming one might introduce false aim, or late aim?
Why would the code hang? Shouldn't there be, like any game, a main loop that calls various functions, so the aim process is only a part of a loop and won't hang anything? And subsequently the transitioning itself doesn't necessarily have to be executed in a self-containing loop, it can just be a variable updating every second frame or something and this way we can ensure less overhead.
More information on KRelay can be found here: github(dot) com/TheKronks/K_Relay_Plugin_Documentation/blob/master/README (dot)md.
There are various APIs to help with multithreading. Multithreading isn't intrinsically hard either - it'll just need a big change in workflow. People make aimbots by patching the game client - which is difficult to edit easily as opposed to just making a program.
Of course, having a state where the aimbot is transitioning between two directions will result in reduced accuracy, however, that's kind of the point - to make it more humanlike. It probably will still be pretty pro aim.
Yes, games have main loops which call various functions, however, the functions they call will complete in a very small amount of time. If a transitioning function takes, e.g 200ms to complete - that is a considerable amount - hanging for 200ms every frame (that is, if you had a transition loop on the main thread). (a transition function would need to take a bit of time, to provide a smooth transition - the transition may take 200ms to complete).
Your last point about the transition is valid. It's a synchronous version of the event-based code. It would look like:
Code:
mainLoop(){ //is called once every frame
(other bot code...)
...
(other aimbot code...)
doTransition(); //call transition method
}
doTransition(){
(transition blah blah)
if(transitionDone){
onTransitionDone(); //call this method
}
}
onTransitionDone(){
(do the rest of the aimbot code...)
}
It could of course also look like (variable polling instead of event driven approach):
Code:
transitioning=false; //global variable
mainLoop(){ //is called once every frame
(other bot code...)
...
(other aimbot code...)
if(transitioning){
(transitioning code)
(if finished transitioning, set transitioning to false)
}else{
(other aimbot code...)
//if need to transition, set transitioning to true
}
}
Anyway I'm not saying that these aren't possible, I'm just suggesting why people aren't.
