intiface / intiface-game-haptics-router Goto Github PK

User installed to Z: instead of C:, program crashed on startup. AppData directory was empty.

https://github.com/intiface/intiface-game-haptics-router/blob/master/IntifaceGameHapticsRouter/MainWindow.xaml.cs#L142

When sending commands to the VR system, we slam the value to "on as high as possible". If the user has the vibration scalar set to < 1.0, we should trim that.

We're currently only hooking Steam APIs. This means anyone trying to start games from the Oculus store won't get vibration.

Apparently the DualShock registers as DInput, not XInput. Might be worth trying to hook DInput also to see if we could support DualShock controllers (as well as steering wheels, etc.)

Code is already there, just needs to be hooked up again.

AV bitdefender labels one of the files during installation as malware, more specifially
Trojan.GenericKD.38640302
and its file IntifaceGameHapticsRouter\unins000.dat
its weird, but probably a problem, that should be looked into.

Right now we just hijack from XInput controller 1. We should allow for XInput 1-4 or Vive/Oculus controllers.

If we implement more than just vibrating toys, it'd be nice to be able to set baseline/multipler/etc configurations per toy. This would require better UI than we have now. Look at moving to a Tree Sidebar UI so we could give each toy its own settings widget.

Epic for adding features required for supporting the Fleshlight Launch and other toys via the GHR.

XInput will be fixed in #15, but we'll need separate code for VR right/left visualization.

Return to graphing XInput info. VR Info will happen in another issue.

For some reason the CI built installer for v6 made a version of the GHR that won't connect to Unity VR games correctly. v5 works fine, building v6 locally works fine.

Harmony v2 is incompatible with v1, so the Unity hooking libraries will need to be updated.

Would be nice to support the Fleshlight Launch, Kiiroo Onyx series, Vorze, etc.

Process name,User,PID,ProBalance time,Rules,Priority class,CPU groups,CPU affinity,CPU sets,CPU (%),CPU avg,Threads,Status,CPU time,I/O delta,I/O priority,Memory priority,Memory (commit size),Memory (private working set),Memory (private bytes),Memory (working set),Handles,Page faults per interval,Page Faults (PF),Creation time,Parent,Application name [claimed],Publisher [claimed],Description [claimed],Filename,Command line
"Beat Saber.exe","blusc","18040","","g","Below normal*","0","0-11","","1.83","2.27","77","Running","0:01:03.046","","Normal","Normal","1,783,316 KB","924,096 KB","1,783,316 KB","1,013,824 KB","1357","","849","11-05-2022 21:39:59","15228:steam.exe","Beat Saber.exe","","Beat Saber","G:\Steam\steamapps\common\Beat Saber\Beat Saber.exe","""G:\Steam\steamapps\common\Beat Saber\Beat Saber.exe"""

ghr.log

https://wiki.libsdl.org/

SDL support will assist in compatibility with PCSX2 and Dualshock 4/5 controllers.

Report from discord, hollow knight will attach to the process, hooks xinput1_3, but doesn't receive vibrations. Could be an issue hooking the wrong DLL?

The autoupdater doesn't seem to check for updates anymore. Seems like this may have come in w/ v10, which is an issue because that means we're going to have a lot of dead installs out there now. :(

Games attach, visualizer updates, but nothing gets sent to Intiface.

• Start up Final Approach
• Try attaching to process

Process is found, attaches ok, but we don't get any IPC traffic.

Hi, I have tested v10 and v11. v10 is fully functional but v11 has a device connection issue. Gaming controllers (XBox one, Logitech F710) are not correctly listed. Logs report there is a problem with the bluetooth stack. Xinput vizualizer is working but rumble does not pass trough gamepad. Known issue?

(Reported from Discord server)

When trying to play Beat Saber (booted through steam) with the GHR, the GHR will attach, but no vibration signals are captured or send to the connected hardware. VR controls still rumble though.

Beat Saber updated to using .Net Framework, which means it no longer has an Assembly-CSharp file. Since that's how we detect our .Net Framework version, that's not gonna work now. Add detections for netstandard.dll.

Currently GHR reroutes the haptics from the primary controller, which works great for 99% of games.

However, this doesn't work for Rez Infinite, which has two vibration control settings:

• Vibration (which vibrates for things like weapon firing and level transitions, aka super boring stuff)
• Trance Vibration (which vibrates to the music, aka the Good Shit™)

Vibration is sent to the primary controller (aka controller 0) and Trance Vibration is sent to all the other controllers (aka controller 1-5 or whatever). As a result, it's impossible to get the fun Trance Vibration from Rez Infinite with GHR.

It would be great if GHR could get an update to support rerouting the haptics from the secondary controller(s).

In theory you could do a bunch of really complicated stuff and support arbitrary mappings of any number of XInput devices to output devices, but even a simple checkmark that changes GHR from routing controller 0 (primary) to routing controller 1 (secondary) would make Trance Vibration work and probably handle any other game that wanted to do something like this.

Thanks, and happy to beta test this for you.

Add a way to blacklist process names, and also to auto connect to names when found.

Add option to always select newly connected devices for control

We currently don't track which hand a haptic command is going to, everything just registers as "left".

We had those in the GVR. They should be easy enough to hook up in GHR.

Had someone in the discord server who was having issues with Rez not causing their toy to vibrate, even though the toy showed up in the list, and baseline vibration made it vibrate. It turned out that the GHR XInput injector found xinput9_1_0 before xinput_1_3, even though Rez uses xinput_1_3 exclusively. This meant we weren't actually getting any vibration signals in.

Ideally, we should just attach to everything we find and route as needed to their respective calls, versus only attaching to one library. We can expect that only one library will ever make calls and the other two links will sit idle.

For things like scanning on startup, blacklisted process names, etc.

If the GHR exits before the process its attached to, it can cause the attached process to also crash.

GHR can attach to process, but no vibration is routed.

Transferring from buttplugio/buttplug-windows-suite#18:

User report via chat group:

Huh, so something SUPER weird happened just now
Run the buttplug server, run the vibration router, I try to link the buttplug server process to the vibration router (I don't know why)
Vibration router app crashes, Vivaldi browser crashes, Launchy crashes
Vibration router deleted itself, Vivaldi doesn't remember if it's installed or not
Launchy works fine
Theory: Either it really doesn't like my computer, or Bitdefender deleted it for some reason
That is in fact the case, Bitdefender is showing up saying GVR is malware, and it blocked the other stuff I had running.

Still using old name in CI releases

Adding an option to not use the embedded intiface software but to instead connect to an intiface server running on another computer. So, for example, a computer on address 10.0.0.2 would run the GHR and pipe the commands through to a computer on 10.0.0.3 that is just be running the intiface server and has whatever toy connected.

I tried a handful of games through Xbox Game Pass with little success. Some would not show up in the process list at all (may just be specific to those games) but the ones that I was able to attach to didn't route any vibrations.

I used Enter the Gungeon as a test case since I have it on Steam as well - the Steam version will attach and route vibrations without issue, while the Game Pass version will not route vibrations after attaching.

Report from user on discord, unchecking the box doesn't actually stop rumble from being sent to the gamepad.