Hi! I have been a little busy, and was testing this code and it works nice, it sleeps the mouse click, in a individual way to mantain the raw input sepparation.
This is used for crt lightguns connected to windows, as they work as absolute coord mice, but need a flashing just a moment before the click (15, 30 or 45ms depending on the game/ emulator), because they dont track on dark colors:

The next I wanted to do, is converting this to direct input. I mean, I have some games which work with direct input and the mice/guns aiming don't get sepparated.
I can set triggers to any key instead of mouse1button1, mouse2button1, and so each trigger shoots the correct player bullets, but the coordenates are shared, and when both guns are aiming to the screen, the shoots gets crossed.
So I thought this:

And, and it separate the shoots correctly, but as you said, when using MOUSE_MOVE, it may lag, although it isn't noticeable, the flashing and the click don't mach and don't work propperly on dark colors.
In this same code if I change

No I don't think it's lag causing incorrect coordinates, I think it's the coordinates not being reported at the correct position. In fact I see in your second script you're not reporting movements at all when blocking mouse movements, so that's why it's shooting at the wrong spot even with only one gun, at least from what you have included from your script anyway. The script you posted is incomplete, so I was going to edit it but since it isn't complete I'll try to explain. You need to use an else if checking for mouse movement after the LButton check for the case when the devices are one of the guns, and report the movement . I would kind of expect the two guns at the same time issue however.

The major issue with two guns at the same time, is there are two devices using mouse coordinates, and windows doesn't really know how to do this, if you have two mice attached to your computer the cursor responds regardless of which mouse is moved. It's easy to block one devices mouse movements, and do something else entirely with it but what you need to do is basically track each devices movement independently, and then report where each device is pointing based on the tracked values when the triggers are pressed. Not something that is easy to do. I'm assuming here that the guns are always updating the position when pointed at the screen, and I'm not sure that is the case, since you also mentioned they use ABSOLUTE mouse positioning, which potentially changes everything regarding how to do the movement. You'll need to code so you can see some data (i.e tooltip) regarding the mouse movements being captured/reported to understand exactly whats happening. Best case scenario is that the movement is in fact reported in an Absolute fashion and perhaps in a burst only when the trigger is pressed, that would make it quite easy to do, but this is all just guess work without any data showing how the movement is actually being captured/reported.

FYI, I have made advances with processing input from multiple mice - I now have a solution which can block all input (Using hooks) but still receive rawinput messages (So it can get independent updates for each mouse).
At the moment it only responds to relative input, but I could easily update it to support absolute I think.
It uses a C# DLL to do the RawInput, as this is easier and faster in C#https://autohotkey.com/boards/viewtopic ... 78#p153378

I think all I would need to do is add another method for subscribing to absolute data, eg add an extra condition like this one:

No I don't think it's lag causing incorrect coordinates, I think it's the coordinates not being reported at the correct position. In fact I see in your second script you're not reporting movements at all when blocking mouse movements, so that's why it's shooting at the wrong spot even with only one gun, at least from what you have included from your script anyway.

Hi Noesis, yes, the guns are ever tracking when aiming onscreen.
When using the second script, I block mouse movement for the guns, but it is refreshed when shoot. I can see it, so on shoot, the cursor moves to the correct aiming position, even aiming with the two guns, the bullets go to his correct player owner as I'm blocking mouse movement, and refreshing with

Ok,
Issue 1, is due to the sleep statements. Essentially what is happening is, when you press the trigger, the entire script is unable to do anything while it sleeps, nothing new can be reported and no new info can be captured, but all new info is still blocked. It can only be overcome by using another thread and the easiest way is to use a different script as that other script will run in a different thread. Choices for doing this is to use postmessage to send a message to the other script which is listening for the message, i.e. when a button is pressed (see ahk's help for "OnMessage" for help with this) or you could do something like send a key that isn't used (F13-F24 are good candidates, as they usually don't exist on keyboards anymore) from this script and have hotkeys set up in the other script waiting for one of those keys and then send the proper keys with the delays, that way the interception script can intercept and report the mouse position data while the button(s) are down.

Issue 2, you're trying to do too much in a single capture. You should be sending a key/button down OR up in a single loop iteration. At the moment the Up interceptions are completely ignored from the device and when the down event occurs, you're causing the first Issue but also completely guessing the length of time the trigger is held down for. Triggerlength is rarely going to be constant and it's completely based on your finger, it doesn't help that this variable isn't assigned a value anywhere in any of the scripts you've posted, which means it's either irrelevant and not necessary or I still haven't seen a complete script.

Issue 3 is, I'm still unclear on how the mouse positioning with the guns work. If the guns are using absolute coordinates I need to know what is being reported, use a tooltip to display what the mouse.x and mouse.y values are for the guns when they are moved. Or alternatively tell me how far off the flashes are, where are they appearing, i.e. are they always in the top left corner of the screen or are they close to where the gun is aimed but off only a little bit due to the trigger presses. There is a flag in the interception script for absolute mouse move too, so perhaps setting the filter to something like MOUSE_BUTTON_1_DOWN|MOUSE_BUTTON_1_UP|MOUSE_MOVE_ABSOLUTE instead of using MOUSE_MOVE or MOUSE_ALL. And to be honest at the moment you probably don't even need MOUSE_BUTTON_1_UP either, that way you could eliminate all the guess work with the up events.

Issue2: I tested with only MOUSE_BUTTON_1_UP|MOUSE_MOVE, the script worked but same results.
I think "Issue3" is not the problem, as when the flash is launched at its timing, the shoot gets correctly positioned. I tried MOUSE_MOVE_ABSOLUTE but the script didnt work with this.

Si I will go for solution for Issue1, but I'm a bit lost, can you give some example or reference, please? and many thanks for your help!

Ok when I say I need to see all the code, I mean the code you've changed i.e, the entire while loop and any variables being used within it, that you've defined outside it. (the original library I don't really need, unless you change part of it, in which case I'll need to see the bit you changed). It's purely so we're on the same page as to what you're doing, when you leave stuff out, I've got no option but to guess, like for example I had no Idea you were doing stuff with the mbutton or rbutton, I also wasn't aware the guns even had those buttons.

Another thing to be wary of is using send vs send(). send() is part of the interception library it sends keys differently to ahk and ahk will never think they are fake key presses, i.e. they are generated from the device driver. send is the ahk command, it could be interpreted as fake and is generated by ahk. Other ahk scripts may or may not ignore them depending on various settings. My personal thoughts are when using interception keep things generated by the driver. I also mention this as I noticed in the code you were using sleep(triggerdelay) - there is no sleep function in ahk or in the interception library, so I have no idea what these statements were doing if anything, they should be sleep, 100 or sleep, %variable%. (I didn't fix these btw, as that code will should be moved out of this script anyway)

Code below should give you an idea of what I mean using hotkeys in a separate script. I've only changed the lbutton part, with respect to this, and left your original code commented out. Should you post this script again please delete the commented sections before doing so. Finally, there were other parts I changed like making most the if statements, else if statements, as it is more efficient that way, and adding code to actually do stuff if it isn't one of the guns, so other things will still with the script running.

this way the cursor only refresshed the coordinates when firing, but I dont get the key pressed.
Actually, see another problem, in theorically, I should refresh the mouse movement after %triggerdelay%.
So I would have to add interception to the second script and have the 1rst capturing mouse_move without delays, and the 2nd, capturing mousebuttons and delaying. May this work?

What values do you get with mouse move ? remember I asked you to put a tooltip in for mouse movement and to display mouse.x and mouse.y, the act of putting in the tooltip is purely to see what kind of values you get, as it will make movement lag but it's just for diagnostics and not meant to stay there. You could be you're getting low value values (likely less than 10) with a - (minus sign) when up or left and positive when right or down, or you may be getting larger values like screen coordinates. What you get determines what needs doing.

Ok looking at the code you changed most recently, there is a very good reason the key isn't pressed and that's because You changed the code and now you're not telling it to press. Also with the new code you are are now sending mouse button 1 down and where in the code is it released ?.

I'm not entirely sure the values you gave me are correct for the mouse.x and mouse.y can you show me the code you used to get the values ? 66000 seems excessive for a monitor with 640 pixels at most and even if it is the case being that you aren't running a square resolution I'd expect the max x value to be different to the max y value. So I'm thinking you put the tooltip in the incorrect place.

Hey guys,
Further to my last post, I now have POC implementations for most input / output methods (DirectInput, XInput, RawInput, vJoy/vXbox and the Titan API for outputting to consoles) written as a C# DLL that wraps the various APIs.
Just about the only hurdle left that is stopping me from implementing something like UCR (But with a C# back-end) is support for keyboard / mouse (With blocking support).

So Interception is looking more and more like the most viable candidate for that...

However, rather than implementing the Interception wrapper in AHK, I would be wanting to implement it in C#, and allowing AHK to call it via CLR.
I see a c# wrapper for interception here, however it does not seem to have been updated in 4 years.

Does anyone have anything more recent? Would anyone be interested in contributing or at least helping me get started?
I would certainly be willing to write something that was not specific to my implementation, so people who just wanted to use interception from AHK could just load my DLL and call the methods.
eg I would be looking to remove the need for while (receive()) loops in your AHK code - ideally everything would be event-based callbacks, like if you were using normal AHK hotkeys.

Edit: Ah, I just noticed Noesis' spoiler in the old post. I will try to have a play with that this weekend.

Hi Evil, I posted a wrapper class for CS on the first page of this thread (not sure how to link to the specific post, but it was dated 5th Apr 17). It's in the Spoiler at the bottom of the post. It's fairly similar to the one you already found (I know this because the one I did was based of that one, there is however an extra function added to mine, which implements the call to get the device string. The fact of it being 4 years old isn't huge as none of the functions in the dll used have actually changed and interception itself hasn't been updated a great deal in that time either, only a couple of bug fixes I think from memory).

I'm happy to try and help with what I can but I'm not sure how much assistance I can actually be. The main thing to consider is probably the setup prior to the while (receive()) part, i.e. the setup of the filters to use and the device handling (assuming you plan on allowing filtering for specific devices). Then there is the sending of stuff, as sending via interception dll is also lower level than ahk's send command. One last thing to consider is that the while(receive()) is essentially event based itself, in that it doesn't constantly iterate, it only does so when filtered input is received but you've probably already realized that.

If (fakekey)
{
key.code := fakekey
If (state=1){
send(context,device,mouse,1) ; this isn't a key, it's the mouse (actually it's the current input which is the Mouse LButton for the gun) it should be faked as a key being pressed (key is an object, key.code := scancode of the key to send, key.state := 0 is key down 1 is up, key.device := device sending the key, this must be a device number for a valid keyboard), device (on it's own is mouse.device) as it's referring the mouse device that created the input, as you are in the "if is_mouse(device)" section. key.device is a keyboard device, and the mouse object is different to the key object (i.e. last parameter), what this line is actually doing is sending the received input through as output.
key.state:=0 ;this is setting key down again this is different to state on it's own, state on it's own is a product of the getKeyName function and is different to the actual key.state or mouse.state you need to use to send a key or mouse button - to find those codes look at the code in getKeyName().
}
Else{
key.state:=1
send(context, key.device, key,1) ; this is sending a key, it's sending the device number, and a key object. remember a key object is different to a mouse object. Key object contains code,device and state, which is why I was set key.code and key.state so it would be put into the key object as what was needed.
}
}

Thanks for the tooltype code, the tooltip wasn't in the correct position, it was in the section for button LButton presses which will give garbage values for mouse.x & mouse.y try the following code instead

Ok I've changed the code slightly, now movement is completely separated so you should get tooltip for any mouse movement regardless of device. Want you to check with gun, make sure the device number reported is actually a gun device, if not ignore the value as it's irrelevant (you hopefully were doing that anyway), also do a check using a regular mouse, as with a mouse you should definitely be getting relative values and if you don't then something else is going on. Just a hunch but if you don't get relative values for the mouse let me know what version of windows you using 64 bit or 32 bit ? also make sure you're using same version of ahk and the interception.dll you're using is also the same version as the system, and re-check.