Creating a wrapper for interception.dll (fixed and working!) Topic is solved

Get help with using AutoHotkey and its commands and hotkeys
phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

23 Apr 2017, 10:33

many thanks it works, now I'm only having problem in shorten the simulated LButton, I realized I need it shorter, how I can set it custom duration?
Noesis
Posts: 134
Joined: 26 Apr 2014, 07:57

Re: Creating a wrapper for interception.dll (fixed and working!)

23 Apr 2017, 10:41

do you mean the sleep (i.e delay) ? and what parts of the code did you uncomment if any, as if you didn't uncomment any you'll be getting the sleep on both press and release. You'll need to at least uncomment the if state = 1 line assuming you didn't uncomment any and it will help but essentially the button is down for as long as you hold the trigger (plus the sleep time).
phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

23 Apr 2017, 11:05

I was uncommenting it generated the key but not the LButton, I'm getting better this way:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


but even writing sleep, 0 for trigger length it seems has a minimal duration about 500ms I can't ride of
phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

23 Apr 2017, 11:42

I got i, many thanks!

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


may be not the better way, but works...
phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

23 Apr 2017, 17:29

Not really...
I was testing on the pc with a huge triggerdelay, so I was not fisically pressing the trigger when the simulated LButton is fired, and I can set a custom length this way.
But testing with the guns with the real trigger delay(about 1miliseconds) I'm pressing fisically the trigger when the simulated Lbutton is fired and the it isn't released until I fisically release the trigger. I need it with a custom lenght no worries when I release it.
Also I don't understand

Code: [Select all] [Download] GeSHi © Codebox Plus

send(context,device,mouse,1)

The "1" parameter wasn't for DOWN and 0 for UP?

Finally I realized that the "hardware_id:" I get a number that is the same for both guns. Emulators supporting multiplemice seems to identificate them with that number, but longer, and is in that final part where the guns ids are different.
At the moment I'm using "device:" and it works and looks persistent when rebooting.
Noesis
Posts: 134
Joined: 26 Apr 2014, 07:57

Re: Creating a wrapper for interception.dll (fixed and working!)

24 Apr 2017, 06:34

Not sure what you mean in your first paragraph, If you're talking about making it rapid fire instead of simply inserting/delaying an event like you originally asked, interception is low level, the loop is for detecting input, it executes when something that is filtered changes state, that's all it does.

It isn't meant to do anything more than that. If you want rapid fire in a single script you're out of luck it won't do that. Can it fake the output, it probably could, but only if you give it the correct information, in the correct format, and for it to repeatedly do this while a button is down, it can't be done in a script which is also actively receiving input.

Truth is, it's not an aspect of Interception I'm particularly interested about, so naturally, putting the time in to figure out the precise details needed to achieved it also isn't something I'm interested in doing, but I do think it's possible. I've kind of outlined the basic process and some of the restrictions both here and in one of my previous posts, that it would need to follow in order for it to work, but it's up to you figure out the exact details needed to make that part of it happen, assuming that's what you actually are after. Also remember that the mouse and key variables are ahk objects containing the data returned from the interception.dll, look at the code to determine what keys they actually contain, and the Get_KeyName() function shows you how that data can be read and what it does to translate that info into something which is a bit easier to understand.

The "1" parameter in the send() function isn't anything to do with down or up, it seems to be designed along the lines of how many strokes to capture->send, It's used to allocate the size of some of the structures within the compiled interception.dll and so you should just use 1 as that's how many strokes you're also capturing in the receive() function (i.e also receive's last parameter).

Yeah the hardware id can be the same if you have two devices that are the same make/model. The rest of the info you mention the emulator uses and other things like AHKHID often return/use is the same info with the port number (usb port) that the device is attached to appended to the end. In other words, it's only the "Vendor|Model" sections of a "Vendor|Model|Port" string. You can interrogate the devices by setting a context & filter, then looping through the devices to get the numbers (the interception.dll source code indicates devices is an array containing up 20 values), so something like this would display all the device numbers and there associated id's:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

25 Apr 2017, 14:18

sorry but i get the error "function library not found"
The other scripts included <_Struct> but this one <interception> why?
I have interception.dll in the same folder, and interception.h in library folder.
Noesis
Posts: 134
Joined: 26 Apr 2014, 07:57

Re: Creating a wrapper for interception.dll (fixed and working!)

26 Apr 2017, 04:12

Oops, that would be because you don't have that file, sorry about that.

On my machine, I've separated the functions from the sample into a file named interception.ahk (i.e. I created a library from them) and since I'd forgotten that I'd done that, and the sample actually had the script & functions in the same file, I put that at the top thinking it was separate. Just remove the #include line and copy the functions into a file with the above code or do similar to what i did and create a library. The library I actually use follows:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


Note: You'll possibly notice there are a couple of changes from the sample. There is an Interception_ prefixed to most the functions, if you use this as a library file, you will need to either add Interception_ to the beginning of the calling functions that use the relevant functions, or remove them from the library file. For info on Library files see AHK's help. And remember to update the variable "interception_dll_path" to point to the correct place on your hard drive if it isn't in the same folder as this file.
phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

26 Apr 2017, 12:03

thanks, I got it working, but it shows only HID#VID_0B9A&PID_016A&Col01 and:
P1Device = \\?\HID#VID_0B9A&PID_016A&Col01#7&28d4c0d1&3&0000#{378de44c-56ef-11d1-bc8c-00a0c91405dd}
P2Device = \\?\HID#VID_0B9A&PID_016A&Col01#7&3b8e7176&8&0000#{378de44c-56ef-11d1-bc8c-00a0c91405dd}

There is no way to get the second part of the number? it is where the guns differenciate.

What I really need is no autofiring. It's only limitate the duration of the LButton, to be all inside the flash duration.
Something like this

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

Noesis
Posts: 134
Joined: 26 Apr 2014, 07:57

Re: Creating a wrapper for interception.dll (fixed and working!)

27 Apr 2017, 09:18

No you can't get the second part of the string, but there should be two identical strings appearing which have different device numbers, the two different device numbers are specific to each gun, so one will be the P1 gun the other P2, you'll have to assume something like lowest number is for P1 and the other for P2. Can't do much about that, but I was under the impression it wouldn't really matter as you were doing the same thing regardless of which gun fired, I thought the guns were both using LButton, is that incorrect ? is one using LButton and the other something else ?, also is there two flash programs one for each gun ? (again I was thinking there wasn't).

Also how does the flash program work, if you push and hold the key for the flash program does it do a single flash, does it continuously flash, or does it kind of flash "on" and stay on while the key is held down then go off when the key is released ?.
phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

27 Apr 2017, 17:42

Yes, you have reason, both lightguns use Lbutton for shooting, but a key mapped button to flashing, but actually it doesn't mahter which one is the first and the second, only to flahing sepparately. I'll do this way, many thanks.
The flasher program has a customizable do a single flash, it have a custom lenght value. It is dessigned this way to be as short as posible.
Noesis
Posts: 134
Joined: 26 Apr 2014, 07:57

Re: Creating a wrapper for interception.dll (fixed and working!)

28 Apr 2017, 02:04

Ok I think I understand now but just to make sure, so the flasher program (I'll assume it's mapped to the "f" key for flasher). It flashes once no matter how long you hold down the f key, and when you release the f key nothing actually happens, but the LButton has to go both down and up while the flash actual flash happens, is that correct ?

PS: I see you're actually online ATM, but I can't hang around, got to go somewhere in RL, so I'll come back later.
phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

28 Apr 2017, 04:41

Yes, thats it!
Only the flash is launched with a and k, one for each gun
Noesis
Posts: 134
Joined: 26 Apr 2014, 07:57

Re: Creating a wrapper for interception.dll (fixed and working!)

28 Apr 2017, 07:56

Ok here's what I think you need to do, it's based on the code you most recently posted, read the comments I put in the code to understand what & why:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

28 Apr 2017, 10:52

Bingo,, many thanks this is exactly what I needed:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



the problem was "mouse.state := 2" I didn't realise this. And you got reason, state=0 isnt needed.

I'm gonna test it with real guns and when cleaner and more simple, I'll share for people still usin crt lightguns with windows. Many thanks!
phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

28 Apr 2017, 18:10

The triggerlenght worked perfect, I tested, and I have to play a little more with the delays, but I'm getting near perfect results. But the guns identification don't work, both fires gun2flasher. Any advice?

Also,do you think this timings are reliable? It seem as I'm not getting the same timings as the guy that did this with electronics
Noesis
Posts: 134
Joined: 26 Apr 2014, 07:57

Re: Creating a wrapper for interception.dll (fixed and working!)

29 Apr 2017, 06:11

With regard to timings, I can't help a great deal, I don't have the guns or the flasher program. Having said that the two sleeps which would be triggerdelay and triggerlength, you could actually try without the triggerdelay one as the order of events ensure that the key is before the button (hopefully that makes sense). It's just a matter of if the flasher program is quick enough to do it in time. With regard to the second sleep triggerlength, it will most likely be needed but may not, it depends on how long the key needs to be down for, in order for the end program to register the key was pressed. Since you're using this with mame I have no idea what platform you're emulating and no idea which program you're running in that platform, and it probably wouldn't help even if I knew. Take for example something like windows directx, it polls for inputs about every 30ms so if a key is down less than that amount of time it could be missed. That's just an example as the delay you need will be different, but I'd suggest something like 15 to 100. Remember 100 is 1/10 of a second and usually if you manually hit a key, it's usually down a bit longer than 100ms but considering there are two guns and this script will stop other inputs while it's sleeping you want it as short as possible but so it's still detected.

To be honest, sleeping in an interception script's while loop is not really the Ideal solution for this, but the only other option is use two scripts one to react to these events, and report it (i.e. postmessage or send different unused keys) and the other to notice the reports (i.e. onmessage or hotkeys) and do the sending of the keys with the delays etc, that way inputs can still be handled if not from the device, while the devices routines are still bein processed.

Anyway, the main issue with your script at the moment is the device detection. You need to use the device numbers not the strings. You also don't want to be calling get_hardware_id(context,device) every time a button is pressed (that returns a string btw, not a number). Also Remember that script from a few posts ago, which interrogated the devices. Use something similar before the while loop even starts which checks for the string you're interested in. Change it to still loop 20 times, and if the get_hardware_id() is the same as the string you want, store that device number in your variable for the first gun and the next one it finds in your 2nd gun variable, then you have the two device numbers you will be using. These numbers won't change once your computer has booted up, and often the only thing that will make them change even with reboots of the computer is if you unplug/plug something in or perhaps if you're OS updates, and even then the actual numbers might change they might not too. The strings will never change even on a different machine, but they should only be used to get the device numbers, and it's the numbers that you should use. Especially since you already know the strings are the same for these devices (you mentioned that earlier).
phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

29 Apr 2017, 13:18

I have realised that they change when I run virtualbox and then exits. As when you run seems the usb devices gets unplugged from the host os to be recognized by the guest so. When returning from vm it seems i'm getting the next ids. Normally the guns are 13 and 12. after each reboot are 14 and 15, 16 and 17 and so on..
I will run for your suggestion. It's a shame seems the only problem is virtualbox
phasermaniac
Posts: 47
Joined: 09 Apr 2017, 14:05

Re: Creating a wrapper for interception.dll (fixed and working!)

30 Apr 2017, 09:24

I had another idea, and as I was such close, I have tried, ans suceed.
Its a rawinput to directinput gun converter, because lightguns working in rawinput only works sepparately in rawinput emus.
So with this, you can get the guns sepparated even in desktop. The cursor goes where each player shot. Without the script, the shots gets crossed between p1 and p2.
But I wanted to do anithing more: send the cursor to a corner, what's the best way to do this?
To update coordinates when I wanted I used

Code: [Select all] [Download] GeSHi © Codebox Plus

send(context,device,mouse,0)
there's anything similar to send no coords or 0,0 to hide the cursor after the shot
Noesis
Posts: 134
Joined: 26 Apr 2014, 07:57

Re: Creating a wrapper for interception.dll (fixed and working!)

01 May 2017, 03:22

I'm sorry, but I don't understand your Idea.

With regard to sending the cursor to a corner, i.e. Mouse position, you'll be dealing with mouse movements, so you'll be dealing with movements, not positions. i.e. if you capture mouse movements, you'll get relative position changes, not absolute cursor coordinates, and so to send those movements you have to do the same thing and send relative position changes.

I'm also not sure you can send movements without capturing them but I suspect you can, however what you have to remember is if you don't capture them they wont be blocked, and if you do capture them, you'll definitely have to start using a secondary script as sleeping in the loop will cause all input mouse movements to be ignored or buffered while sleeping and will cause lag.

If you don't understand what I'm talking about, I suggest you do a test first to see what I mean, simply capture mouse movement, pass that movement through (so the mouse does move) and also reporting that movement via a tooltip without any sleeps, causes some pretty significant lag on rapid movements, removing the tooltip will fix that, but that tooltip will be quicker than a sleep meaning the lag will be worse with sleeps here's an example which uses that library I posted earlier.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


Return to “Ask For Help”

Who is online

Users browsing this forum: Bing [Bot], iceivanov and 40 guests