[Feature Request] Wiimote IR sensor mappings to analog joystick with calibration

[aguxone]

Hi, first of all thanks for coming with this app from nowhere and replacing absolutely all input apps into one, it is life saving and practical for the whole games, frontend retro setup, emulators and all kind of games i use on PC.

Request:
It would be useful to properly map IR X and Y sensor to an analog stick properly with some kind of calibration, preferably a XINPUT one for keeping joystick order checked on many different apps.

State right now:
It is pretty buggy, one can assign IR sensor it but it is pretty janky it has some kind of deadzone and many dead spots and does not behaves as fluid as one would expect. No configuration i tried of the sticks themselve made this situation better.

Motivation:
This would be the killer replacement for "Lichktnarre" which assigns IR to joysticks or mouse. Right now assigning IR properly to left analog joystick is the most compatible way (much more than mouse as i could debate with others, also supporting many players) to use wiimote as a Lightgun on all type of lightgun games. Right now for me Lichktnarre in the only app working which works properly, but its pairing is temporary and slow that makes it unpractical, also it will conflict with PadForge as it replaces the registering of PadForge and has to be assigned once again to PadForge in order to quickpair on seconds wiht one button.

This is an idea, maybe it is solved by another means that someone else might know. Thanks for the inmense effort.

[hifihedgehog]

PadForge does this now. A Wii Remote can aim a stick like a light gun, with calibration. It's on the development branch and ships with the next release. The full write-up is in #485.

We found three things in PadForge that fit what you describe, and changed all three:

• The crosshair holds its spot. The aim exists only while the remote sees both lights of the sensor bar. Near the screen's edges one of them leaves the camera's view, and the IR Pointer sources used to drop the stick back to center when that happened, which is the likeliest source of the dead spots. They now hold the last aim until the bar comes back, the way the mouse cursor already did.
• Twisting the remote no longer moves the aim. The aim now corrects for roll, so tilting the remote in your hand keeps the crosshair where you point.
• Calibration. On the Devices page, select the remote and click Calibrate in its Light Gun section. Four targets appear in turn. From where you play, point at each one and press B. After that the crosshair lands where the remote points, at your distance and with your sensor bar where it is. Home or Esc cancels, and the reset button beside it returns the remote to its default range.

Setting up a light-gun game:

• Map IR Pointer X and IR Pointer Y onto a stick of whichever virtual controller your games read. An Xbox 360 slot gives you XInput. Nothing ties the pointer to one slot type, so use the one that keeps your controller order the way you like it.
• Leave that stick's Deadzone X and Deadzone Y at 0 on the Sticks tab. Above 0, the default Scaled Radial shape keeps the stick inside a circle, and the corners of the screen go out of reach.
• Set the emulator's own deadzone to 0 and its saturation to full. MAME starts at a 0.15 deadzone and 0.85 saturation, which adds a dead band in the middle and clips the edges.
• Map IR Offscreen to reload.

Unlike Lichtknarre, PadForge pairs the remote once with the SYNC button, and after that it reconnects on any button press. There's no re-pairing and no second app taking the remote over.

One thing it doesn't do: setups with four IR lights around the screen. PadForge reads the usual two-light sensor bar.

No one has run this with a real remote yet. The tests cover the hold, the twist correction and the calibration math.

Details: https://padforge.org/docs/devices/wii-controllers/#light-gun

[eVenent]

@aguxone please open HidHide app and check if PadForge exe file is added to whitelist. I had similar issue - when virtual controller was turned on, main controller was disapearing and PadForge was not seeing it. Adding it to whitelist, fixed everything.

[hifihedgehog]

@aguxone We could not reproduce this ourselves. Here, a Wii Remote dragged onto a slot stays hidden from games and keeps working in PadForge. Your replies are what will get this resolved, so please reply here as quickly as you can.

Your log shows PadForge hiding the remote from games at 22:13:30.242, when you dragged it onto the slot, and SDL dropping it 0.74 seconds later, while the slot's virtual controller was being created. SDL never saw it again, which is the gray row you described.

PadForge has to read every controller it hides. If HidHide refuses PadForge itself, the next device scan cannot open the controller and drops it, which looks like this. Your log cannot show whether that happened here, so the next build checks for it. After hiding a controller, PadForge opens it once itself. If HidHide refuses, PadForge takes the hide back so the controller keeps working, says so in the status bar, and hides again on its own once HidHide's whitelist changes. The diagnostics log records what HidHide answered.

@eVenent PadForge puts itself on HidHide's whitelist by itself, so there is no need to open HidHide's app. One case slips through in 5.0.0: PadForge lists itself by the path it was started from, and when that path runs through a folder junction, HidHide never matches it. The next build also lists the name Windows records for the running program, which covers that case.

This is not confirmed as the cause of your report, and it does not explain why 4.4.0 worked for you.

[aguxone]

Ok i just tested it a bit better with all the concepts exposed here.
I did not remembered i was using hidhide myself and had it installed, and often used with my scripts on the "Inverse Cloak" mode. Last time was left configured this way.

I noticed PadForge clearly tried to add itself to the list, no matter if it is on normal mode or inverse cloak.

So i think that was the problem, as PadForge was auto-adding itself, it was being "blacklisted" instead of "white-listed".
Right now it works fine, if inverse cloak is off.
But it noticed anyways it takes a few attemps to restore full functionality and making it work again.

When it works, calibration works great and can be used to play all sort of lightgun games succesfully which is totally awesome! Dream come true.

Now i also noticed some additional bugs also. When having PadForge open, if turn off the wiimote (by holding its power button), the wiimote might or might NOT re-pair again automatically. If it succesfully pairs, then it will LOOSE the IR mappings to the left analog stick, the rest of the buttons work though. If it does not re-pairs, a restart of PadForge is needed, and the re-pairing by the touch of works.
Also noticed that connecting and the disconecting the motion plus accessory might mess up the button detection as a whole (no buttons detected), but most times i did that it gets to work just fine, does not seems to be everytime.
Maybe this should be open another issue?

So to summarize:
Request:
Maybe there could be an option for automatic detection of PadForge to look if inverse cloak is already on make sure to be not blacklisted? In my case would be useful because i have a ton of apps to be used this way (though using everything managed with padforge would be nicer i admit, i might rethink some workflow for myself).
Bug:

• If wiimote turns off, it won't necesarily repair by the touch of a button, restart needed.
• If re-pairs succesfully, IR mapping to analog stick is lost in the process.

[hifihedgehog]

@aguxone You found it. With HidHide's Inverse application cloak on, the apps on HidHide's list are the ones it hides devices from, and PadForge 5.0.0 adds itself to that list in either mode, so it hid your remote from PadForge itself.

What you asked for is in the development builds, the latest-v5-dev pre-release. With the cloak on, PadForge takes itself off HidHide's list, hides nothing, and says so in the status bar. When the cloak goes off, it hides again. It ships with the next release.

The three problems you hit after that have fixes in development build r3903 and later:

• After a reconnect the IR aim was gone. The Wii driver PadForge uses tried once to start the remote's camera, and a start that failed stayed failed. It now tries again after 1, 2 and 4 seconds and then every 8, checks the camera's own status, and sends the camera's enable commands before its settings, the order Dolphin and the other Wii Remote libraries use. PadForge also restarts the camera if no IR data comes after a connect.
• The remote sometimes would not reconnect until PadForge restarted. Windows keeps a Wii Remote listed after it turns off, and the driver dropped a silent remote without ever asking whether it came back. It now asks every three seconds, so a remote you turn back on is picked up again.
• Attaching or detaching the Motion Plus sometimes left no buttons working. When the Motion Plus refused to switch on, the driver read the Nunchuk's data as Motion Plus data and threw away the whole report, the remote's buttons with it. It now drops only the extension's part and switches the Motion Plus on again.

None of this has run on a Wii Remote yet, so it is not confirmed as the cause of what you saw. If any of it happens again on r3903 or later, a diagnostics log that covers it, with the times you turned the remote off and on or changed the Motion Plus, would show where it stops.

The calibration screen draws only the four targets, so it cannot show the two dots yet. A view of both dots fits there, since it would show at a glance whether the remote sees the whole bar.

[aguxone]

Wow excelent news! I'll be trying the new improvements on the new release!

[Trihy]

About single button reconnect, not every BT adapter can handle that. Please share brand of your BT adapter.

[aguxone]

Hi, my device does support it, if not on the first time it will connect on the second one probably. It starts to get slower as more wiimotes connect, the 4th one might take a few tries for example it does connect anyways by the press of any button.
It's a Microsoft Surface pro 8 device with Intel Wireless Bluetooth driver version 23.160.0.9 , there are not much specific details.

[Trihy]

Yes, Intel ones should be able to properly reconnect. I'm having some troubles about that and I think they could be windows related. Sometimes the adapter needs a reset to accept controllers again.