Closed MadArkael closed 8 years ago
It appears to either be unity, or how the program was written, after some extensive testing. I tried about 5 - 10 different work arounds with AHK with no success.
Hey, sorry for the late reply- I've been really busy lately.
This is a known issue, but unfortunately, I don't think there's anything that can be done script-side to fix that issue. My guess is that, when the game detects a click, it sends it to the mouse coordinates, instead of where the click actually occurred. If it's built how I think it is, that effect could just be the result of raycasting from the cursor to the screen when a click is detected.
The only solution I can think of would be to have AHK position the mouse before each click, but then you lose the core functionality that NIAC was built around. If I'm right about this, it's a pretty simple and devious way to dissuade autoclickers... If you want to go with that approach, though, I think there's a SetMousePos function you could add in just before the click function, and that should take care of it.
Best of luck!
On Fri, Sep 4, 2015 at 11:43 AM, MadArkael notifications@github.com wrote:
It appears to either be unity, or how the program was written, after some extensive testing. I tried about 5 - 10 different work arounds with AHK with no success.
— Reply to this email directly or view it on GitHub https://github.com/Shadowspaz/NIAutoclicker/issues/3#issuecomment-137802830 .
Erik Coburn
Yeah, raycasting was my thought as well because of how the gun vectors to where the mouse is. It's no big deal, I just figured since they made an auto aim feature then expected me to use an auto clicker. Alas, no. However, the world didn't end. Thanks for your time :) On Sep 5, 2015 12:12 AM, "Shadowspaz" notifications@github.com wrote:
Hey, sorry for the late reply- I've been really busy lately.
This is a known issue, but unfortunately, I don't think there's anything that can be done script-side to fix that issue. My guess is that, when the game detects a click, it sends it to the mouse coordinates, instead of where the click actually occurred. If it's built how I think it is, that effect could just be the result of raycasting from the cursor to the screen when a click is detected.
The only solution I can think of would be to have AHK position the mouse before each click, but then you lose the core functionality that NIAC was built around. If I'm right about this, it's a pretty simple and devious way to dissuade autoclickers... If you want to go with that approach, though, I think there's a SetMousePos function you could add in just before the click function, and that should take care of it.
Best of luck!
On Fri, Sep 4, 2015 at 11:43 AM, MadArkael notifications@github.com wrote:
It appears to either be unity, or how the program was written, after some extensive testing. I tried about 5 - 10 different work arounds with AHK with no success.
— Reply to this email directly or view it on GitHub < https://github.com/Shadowspaz/NIAutoclicker/issues/3#issuecomment-137802830
.
Erik Coburn
— Reply to this email directly or view it on GitHub https://github.com/Shadowspaz/NIAutoclicker/issues/3#issuecomment-137923031 .
Hey, let me first off saying, this is a wonderful example of how simple yet powerful AHK can be, well done.
I am having an issue with the locational part of the clicker, in fact the controlclick function doesnt seem to be sending to any locations at all other than my mouse which I don't think is intended. I'm using this in an actual program (not a browser) Time clickers on steam, I have the window in windowed mode so it can run in the background (i've tried fullscreen with no luck as well). The program is sending clicks in the background, but not to any of the locations specified, only where the mouse resides on the screen.
If you have any idea on why this might be happening, would be grateful, thanks!