So basically what I am trying to achieve and why I bought the Arduino at least the main purpose that is was to have the mouse plugged into it and then while I push down the Left Mouse Button on the mouse it sends rapid fire mouse clicks to the game (Call of Duty) on my computer. Basically I thought this would make it look like the mouse is clicking from the actual mouse, and I understand the code libarary since the Due can use USBHost which means it has the getButtonStatus which in theory will work?
I literally just ordered the Arduino Due, will this board achieve this small problem?
You need two USB ports; one a USB Host to attach your mouse, and one a USB device to connect to your computer.
In theory this should be possible; the "programming port" should be usable as a device port. But I'm not sure that the mouse/etc libraries for Due are set up to use that - the more common case would be to use the "USB Native" port for the direct connection to PC or a device...
I literally just ordered this board for this purpose and I thought that it was the right thing for it? Hopefully can find a way around it if it doesn't work.
Blasted forum, I had written a longer reply, but submission failed and I lost it! Here's a short version.
Is your intention to have 1 mouse and pipe all the controls to the PC? I wouldn't do it this way. In fact, I wouldn't even use an arduino unless I needed extra functions that couldn't be mapped to a keyboard easily. Rapid fire of the Left Mouse Button can be mapped to key on the PC keyboard using autoit:
Do you have 'extra' mouse buttons? mapping to these is feasible. You could map directly to the left mouse but it's trickier and you need a key to disable the function otherwise you'll be having fun in the game menus.
There are some options for using the Arduino, you could connect a mouse to the native port then emulate a serial mouse via the programming COM port. This could be quite involved. You'll need a button on the Due to enable/disable the function as well.
You could also use mouse emulation and connect it as a 2nd mouse. Either control the rapid fire with a button on the Due or send commands to the due via the programming COM port which then tell the Due to rapid fire. An autoit script could map a key or mouse button to the sending of the command to the Due. I'm not sure if you could map the left mouse button for this as you'd have the real mouse button held down and the Due 'mouse' rapid firing, I suspect this wouldn't work.
See, using autohotkey/autoit is a great idea in theory and I have used that before for other small games and I do have a fair amount of knowledge about it. The reason I would prefer to use the Arduino is because it's an external device so it would appear to the computer as if it's coming from the actual mouse. The thing with software on these types of games nowadays is that the Anti-Cheat on games scans through the memory and all the files on your PC. So using software is not a good option for me, basically defeats the purpose why I got the arduino.
So are you saying that the issue with my design is that I couldn't do it with the left mouse button behind held down because that is what is clicking? So it would be better to do it off a side button on my mouse or something???
This is the code I prepared for it but since but Arduino hasn't come in yet, I don't know if it will work: while(mouse.getButton(LEFT_BUTTON)) {
loopNumber = random(x, y) //number of times clicks before stops
for (int x = 1; x > loopNumber; x++) {
if (!mouse.getButton(LEFT_BUTTON)){
break;
}
Mouse.press(MOUSE_LEFT);
delay(random(minDelay, maxDelay));
Mouse.release(MOUSE_LEFT);
delay(random(minDelay, maxDelay));
if (!mouse.getButton(LEFT_BUTTON)){
break;
}
}
David1937:
See, using autohotkey/autoit is a great idea in theory and I have used that before for other small games and I do have a fair amount of knowledge about it. The reason I would prefer to use the Arduino is because it's an external device so it would appear to the computer as if it's coming from the actual mouse. The thing with software on these types of games nowadays is that the Anti-Cheat on games scans through the memory and all the files on your PC. So using software is not a good option for me, basically defeats the purpose why I got the arduino.
So are you saying that the issue with my design is that I couldn't do it with the left mouse button behind held down because that is what is clicking? So it would be better to do it off a side button on my mouse or something???
This is the code I prepared for it but since but Arduino hasn't come in yet, I don't know if it will work: while(mouse.getButton(LEFT_BUTTON)) {
loopNumber = random(x, y) //number of times clicks before stops
for (int x = 1; x > loopNumber; x++) {
if (!mouse.getButton(LEFT_BUTTON)){
break;
}
Mouse.press(MOUSE_LEFT);
delay(random(minDelay, maxDelay));
Mouse.release(MOUSE_LEFT);
delay(random(minDelay, maxDelay));
if (!mouse.getButton(LEFT_BUTTON)){
break;
}
}
Thanks for the help.
Not like remapping the rapid fire button to the left click is the biggest priorotiy here but what I basically am trying to achieve is to have the mouse plugged into whereever, doesn't really matter where, but I am assuming it has to be plugged into the Due to get information on the mouse. Preferlly the left mouse button (but like I said, that isn't the biggest issue), but as a button is held down I want the Due to send clicks to the PC and as soon as the button is released stop. I appreciate your long answer as although I do know a fair bit about the code and such already, I literally know nothing about the Arduinos and their coponents and in fact the Due is coming in during the next couple of days.
Now that I think of it back in the day maybe a few years ago I used a script back in the day with AutoIt and it indeed did use the left mouse button being held down to produce the clicks. It really does suck because with the insane advance of Anti-Cheat's in competitive games you can't use software at all anymore even if it is external which is one of the main reason I got the Arduino like I said. This was the only option that would be easy to handle as the only other option that wouldn't be detected by the anti cheat was to take another mouse, and somehow make it click by accessing the mouses Hardware.
I really do appreciate the help though, as I am new to this and don't really understand much and really want to make this as it was the whole reason I bought this thing. @weird_dave
If anti-cheat is an issue with using autoit to generate the mouseclicks [I have seen anticheat stop the use of controlclick() but not yet mouseclick() ] then I would probably use autoit to send a control to the Arduino via USB COM port to do rapid fire, pretending to be a 2nd mouse via the Native USB. You'd probably still need to use a spare keyboard key or extra mouse button to trigger autoit to send the command to the Arduino rather than the left mouse button, but you can always try it and see what happens
I'd do this in stages, hook up a button to the due and get it doing mouseclicks as a 2nd mouse, then move on to serial comms and mapping to a key/button. Finally, I'd then implement the rapid fire on the due.
I would be surprised if the anticheat was unhappy with a script that didn't interact with any game binded keys, if it does then the only options left are to use a button on the arduino to do the rapidfire as a 2nd mouse, which is probably inconvenient, or, plug a mouse into the Due Native USB and forward all the movements to the PC as a serial mouse via the USB COM port. This may not be easy. You won't be able to plug the PC and mouse into the Native USB port and use something along the lines of the code you posted as this would require the port being a host and slave simultaneously and the PC would also see the mouse. The programming USB (COM) port can't be used as a generic USB device.
I may have a go at this myself at some point, there are times when 'hardware macros' do work better (the autoit/Due version, not the in-line method, too crazy for me )
weird_dave:
If anti-cheat is an issue with using autoit to generate the mouseclicks [I have seen anticheat stop the use of controlclick() but not yet mouseclick() ] then I would probably use autoit to send a control to the Arduino via USB COM port to do rapid fire, pretending to be a 2nd mouse via the Native USB. You'd probably still need to use a spare keyboard key or extra mouse button to trigger autoit to send the command to the Arduino rather than the left mouse button, but you can always try it and see what happens
I'd do this in stages, hook up a button to the due and get it doing mouseclicks as a 2nd mouse, then move on to serial comms and mapping to a key/button. Finally, I'd then implement the rapid fire on the due.
I would be surprised if the anticheat was unhappy with a script that didn't interact with any game binded keys, if it does then the only options left are to use a button on the arduino to do the rapidfire as a 2nd mouse, which is probably inconvenient, or, plug a mouse into the Due Native USB and forward all the movements to the PC as a serial mouse via the USB COM port. This may not be easy. You won't be able to plug the PC and mouse into the Native USB port and use something along the lines of the code you posted as this would require the port being a host and slave simultaneously and the PC would also see the mouse. The programming USB (COM) port can't be used as a generic USB device.
I may have a go at this myself at some point, there are times when 'hardware macros' do work better (the autoit/Due version, not the in-line method, too crazy for me )
What do you mean by sending commands? Serial?
This anti-cheat is insane, it literally scans through what you are running with your ram. Macros are a big think in competative Call of Duty, so I am just afraid that since AutoHotkey/AutoIt is such a popular method of making macros, that it will be picked up or picked up as a even a cheat.
I am pretty new at this stuff which kind sucks and limits me on what I wanna do.
You could probably use a PS/2 mouse with a Due and USB computer port. And a lot of mice still have PS/2 support built in, I think. Or the other way around. Or all PS/2 if your computer still has PS/2 ports. Or all PS/2 on the Arduino, with an external commercial PS/2 to USB adapter.
weird_dave:
If anti-cheat is an issue with using autoit to generate the mouseclicks [I have seen anticheat stop the use of controlclick() but not yet mouseclick() ] then I would probably use autoit to send a control to the Arduino via USB COM port to do rapid fire, pretending to be a 2nd mouse via the Native USB. You'd probably still need to use a spare keyboard key or extra mouse button to trigger autoit to send the command to the Arduino rather than the left mouse button, but you can always try it and see what happens
I'd do this in stages, hook up a button to the due and get it doing mouseclicks as a 2nd mouse, then move on to serial comms and mapping to a key/button. Finally, I'd then implement the rapid fire on the due.
I would be surprised if the anticheat was unhappy with a script that didn't interact with any game binded keys, if it does then the only options left are to use a button on the arduino to do the rapidfire as a 2nd mouse, which is probably inconvenient, or, plug a mouse into the Due Native USB and forward all the movements to the PC as a serial mouse via the USB COM port. This may not be easy. You won't be able to plug the PC and mouse into the Native USB port and use something along the lines of the code you posted as this would require the port being a host and slave simultaneously and the PC would also see the mouse. The programming USB (COM) port can't be used as a generic USB device.
I may have a go at this myself at some point, there are times when 'hardware macros' do work better (the autoit/Due version, not the in-line method, too crazy for me )
I literally know nothing of what you are talking about, since I am so knew at this. Could you give me subjects I could research so I have a better understanding of this communication stuff, because of right now I barely have a clue what that means or how it applies to AutoHotkey. If you do end up trying it yourself do you mind giving me the code of how you did it?
David1937:
What do you mean by sending commands? Serial?
Yes
David1937:
This anti-cheat is insane, it literally scans through what you are running with your ram. Macros are a big think in competative Call of Duty, so I am just afraid that since AutoHotkey/AutoIt is such a popular method of making macros, that it will be picked up or picked up as a even a cheat.
You can compile the autoit code, so as long as it doesn't directly interact with the game, it shouldn't be picked up. A lot of mice and keyboards have macro options built-in, are they going after those as well?
The windows OS is pretty insecure which is why autoit works, you can hook into most of the system and do things, like pretend to be a mouse, up to a certain point, the system doesn't know if it's a real mouse, there's a number of layers to jump through between the real mouse and what the OS and/or games can see, a quick google:
"There is no way to detect if the mouse is a real one or a really well simulated one. The Windows HID/MacOS/Linux driver layer abstracts away the distinction between Mice, TrackPens, TrackBalls, draw-pads, touch screens... and of course script-mice.."
I would go for an autoit version until they break it, then redirect the control to the Due via serial
David1937:
I am pretty new at this stuff which kind sucks and limits me on what I wanna do.
That will change
David1937:
I literally know nothing of what you are talking about, since I am so knew at this. Could you give me subjects I could research so I have a better understanding of this communication stuff, because of right now I barely have a clue what that means or how it applies to AutoHotkey. If you do end up trying it yourself do you mind giving me the code of how you did it?
There's the autoit com port stuff:
and obviously the arduino com port stuff:
The Due just has to sit and listen to the serial port (the programming USB port looks like a serial port on the PC), autoit could send a single byte, 'N' for 'oN' F for 'oFf' and the Due reacts by autofiring as a mouse via the native USB port when it sees 'N', then switches the autofire off when it sees 'F'
You can compile the autoit code, so as long as it doesn't directly interact with the game, it shouldn't be picked up. A lot of mice and keyboards have macro options built-in, are they going after those as well?
The windows OS is pretty insecure which is why autoit works, you can hook into most of the system and do things, like pretend to be a mouse, up to a certain point, the system doesn't know if it's a real mouse, there's a number of layers to jump through between the real mouse and what the OS and/or games can see, a quick google:
"There is no way to detect if the mouse is a real one or a really well simulated one. The Windows HID/MacOS/Linux driver layer abstracts away the distinction between Mice, TrackPens, TrackBalls, draw-pads, touch screens... and of course script-mice.."
I would go for an autoit version until they break it, then redirect the control to the Due via serial
That will change
The Due just has to sit and listen to the serial port (the programming USB port looks like a serial port on the PC), autoit could send a single byte, 'N' for 'oN' F for 'oFf' and the Due reacts by autofiring as a mouse via the native USB port when it sees 'N', then switches the autofire off when it sees 'F'
Another option is to modify a mouse to autofire directly. Google
I both love and hate this solution. If there was a spare button on the mouse, I'd wire that to do the autofire on the left using a 555.
Thanks for all the information!
Something that I should mention is that the anti-cheat is client side, meaning that they have this insane program that runs as administrator on your PC. It all sounds good except the AutoIt seems to be the only part that sounds kinda sketchy.
You can compile the autoit code, so as long as it doesn't directly interact with the game, it shouldn't be picked up. A lot of mice and keyboards have macro options built-in, are they going after those as well?
The windows OS is pretty insecure which is why autoit works, you can hook into most of the system and do things, like pretend to be a mouse, up to a certain point, the system doesn't know if it's a real mouse, there's a number of layers to jump through between the real mouse and what the OS and/or games can see, a quick google:
"There is no way to detect if the mouse is a real one or a really well simulated one. The Windows HID/MacOS/Linux driver layer abstracts away the distinction between Mice, TrackPens, TrackBalls, draw-pads, touch screens... and of course script-mice.."
I would go for an autoit version until they break it, then redirect the control to the Due via serial
That will change
The Due just has to sit and listen to the serial port (the programming USB port looks like a serial port on the PC), autoit could send a single byte, 'N' for 'oN' F for 'oFf' and the Due reacts by autofiring as a mouse via the native USB port when it sees 'N', then switches the autofire off when it sees 'F'
Another option is to modify a mouse to autofire directly. Google
I both love and hate this solution. If there was a spare button on the mouse, I'd wire that to do the autofire on the left using a 555.
Also it would be easier for me if it was done on AutoHotkey (if it's possible idk) because I have a fair bit of understand on how to use that.
Also would using a powered USB hub or if I buy the USB Host Sheild make it any easier to do it the other way?
Something that I should mention is that the anti-cheat is client side, meaning that they have this insane program that runs as administrator on your PC. It all sounds good except the AutoIt seems to be the only part that sounds kinda sketchy.
I don't really want to mess up my mouse though that is the thing. I use different mouses too sometimes and they are both quite expensive. My aim for this project is:
Have the clicking be coming from External, I don't care how complicated or messy it is on the outside as long as it's external I don't care it's not for looks.
Having the ability to use code so I can code it the way I want and add things like random delays etc.
Be able to use with any of my gaming mice. (not one modded bad mouse)
The external clicks to appear like they are coming from a real HID device (mouse)
A hub isn't going to help, but a host shield might. I took a quick look at one of the host shields and it appears it would need modifying to work, it uses 5v I/O, it's actually level shifted from 3v3, so it's just a case of removing it.
Another option would be a foot operated switch connected to the Due (possibly more convenient than trying to fit one somewhere easy to reach by hand). This has the advantage that you don't need some other button to disable autofire.
Note that with the Due-inline method, any special features of your mice will likely be unavailable. There may also be side-effects such as finding a bug in the code in the middle of a shootout
I am not an expert in any means like this like you are but I did some research and I am wondering if this solution would work.
My thought process with this is I found a slue of these things that have the ability to use one mouse/keyboard or even monitor for two PCs. I was wondering if I could use this instead for the inline method because as I understood what you said is the reason the inline method would be hard to do is because you would have to transfer the movements, mouse clicks etc through the board and you would have to do it like code (kinda like coding like a all new mouse or making a air mouse out of these things). So I was wondering if the mouse was split where one could go into my computer like normal and other other could go into the arduino board reading "getBUttonStatus" and stuff would that work?
Or is there another reason why this won't work?
weird_dave:
A hub isn't going to help, but a host shield might. I took a quick look at one of the host shields and it appears it would need modifying to work, it uses 5v I/O, it's actually level shifted from 3v3, so it's just a case of removing it.
Another option would be a foot operated switch connected to the Due (possibly more convenient than trying to fit one somewhere easy to reach by hand). This has the advantage that you don't need some other button to disable autofire.
Note that with the Due-inline method, any special features of your mice will likely be unavailable. There may also be side-effects such as finding a bug in the code in the middle of a shootout
KVMs switch control between the 2 computers so the mouse control only appears on one of the USB cables at a time. There isn't really an off the shelf solution for that as nobody wants to supply exactly the same mouse controls to 2 pcs (and if you did, you'd use a software solution to do it via the network so that you can account for different screen resolutions and mouse acceleration settings in the OS).
You'd also have the same USB conundrum to solve, you'd need to be a host to the mouse and a client (device) to the PC.
I don't think forwarding the mouse controls using the inline method will be too hard, there's just the issue of what method you use to achieve it. For simplicity with no extra hardware, I'd go for serial mouse emulation via the programming port and attach the real mouse to the native port.
weird_dave:
KVMs switch control between the 2 computers so the mouse control only appears on one of the USB cables at a time. There isn't really an off the shelf solution for that as nobody wants to supply exactly the same mouse controls to 2 pcs (and if you did, you'd use a software solution to do it via the network so that you can account for different screen resolutions and mouse acceleration settings in the OS).
You'd also have the same USB conundrum to solve, you'd need to be a host to the mouse and a client (device) to the PC.
I don't think forwarding the mouse controls using the inline method will be too hard, there's just the issue of what method you use to achieve it. For simplicity with no extra hardware, I'd go for serial mouse emulation via the programming port and attach the real mouse to the native port.
Okay even though I probably wouldn't do the inline method how do I do that?
(the autoit/Due version, not the in-line method, too crazy for me