For the future of this tool

[SplitPixl]

Mostly taken from this comment.

While we have working fixes such as my comment, and @sharkyh20's fork, I am a bit concerned for this repository.

It doesn't seem like there's been anything done on this repo since January 2018. With the current release on this repo broken, it's harder for new people to get this up and running. There doesn't seem to be any alternative to this program. I want to know if @matzman666 would continue maintaining this repo, or if there should be a new maintainer?

There is the option of making forks of the repository, but it still leaves this as the main repo you find from looking up OpenVR Input Emulator, and lots of online tutorials would still point to this repo. I would try maintaining a fork of this repo if I had a better understanding of C++ and the internals of OpenVR, and had more time and energy to dedicate to it.

This is a very useful tool, and I would hate to see it lost due to not having a maintainer, or being splintered into a dozen different forks.

[pottedmeat7]

Although it may end up with multiple results via searching etc. With this deprecated repo still available. There are features of this repo that probably should be separated. The projects input emulation functionality can now be fully supported by openvr. The other features such as pose manipulation are not directly supported by openvr, and will take ongoing support and aren't guaranteed to work with steamvr updates. They should be in a separate project.

[trueA1M2]

I believe steamvr attempted an openvr motion compensation temp beta back in January I don't know any more detail it isn't avaible now

[linkoid]

@pottedmeat7

The projects input emulation functionality can now be fully supported by openvr.

Are you saying that this project is now obsolete because you can now directly feed input into openvr?

[SplitPixl]

This project is still useful for things like VRPlayspaceMover and OpenVR Input Recorder, which don't seem to have alternatives. If those projects can be updated to not use Input Emulator, then maybe this repo could be deprecated. But for the moment, Input Emulator still seems to be the go-to API for this stuff.

[pottedmeat7]

@linkoid Yes all of the input emulation features can be achieved with the fully supported functions of the current openvr. Not to say that there aren't other projects utilizing this projects command line API. For example OpenVR Input Recorder could work with full support from openvr. Yes that project would need to be updated, but it would make that project self sustainable, more then relying on another unsupported project.

[jdawgzim]

I just want a way to push-to-talk in Discord while using my Vive. Discord won't recognize Vive buttons. Does OpenVR-InputEmulator work for this or is there a better solution?

[trueA1M2]

This is still positive have a quick read through https://github.com/matzman666/OpenVR-InputEmulator/issues/143

[TheLastRar]

@pottedmeat7

I've had a brief look though the OpenVR SDK and I'm not seeing an obvious API for simulating a controllers input (As in OpenVR Input Recorder) or creating fake/virtual controllers (VRPlayspaceMover's --fakeTracker option)

Could you point me in the direction of the API that could achieve the above tasks?

[pottedmeat7]

Here's the docs https://github.com/ValveSoftware/openvr/wiki/SteamVR-Input Here's a good example https://github.com/terminal29/Simple-OpenVR-Driver-Tutorial

[TheLastRar]

IVRInput seems focused on retrieving inputs, rather than sending emulated inputs. It does state that it allows input remapping, although it doesn't seem to provide an API to do that programmatically (two exists to show the binding UI)

On that subject, how does SteamVR's input mapping panel compare to that of Input Emulator (when it worked) I never really used either system.

Input Emulator's Virtual devices API already uses the code in your example, although the interface it is currently using is obsolete (as does your example), it still works. It is worth pointing out that the cmdline tool seems to use hooked functions in addition to the intended driver interface, possibly for user friendliness.

[pottedmeat7]

There is now support for creating a third virtual controller, and binding input into physical controllers, without hooking memory at all. You are able to re-bind then input from that controller using the SteamVR Input Bindings. SteamVR's input binding UI can remap each button to other physical controllers. You can monitor the physical controllers for thier input as well, using other openVR APIs.

[TheLastRar]

I had asked about SteamVR's input mapping because I recall someone complaining that SteamVR's input mapping was not upto par with what Input Emulator used to offer. I've had a poke around SteamVR's settings and it seems reasonable versatile.

The virtual device API already makes use if IVRControllerComponent see https://github.com/matzman666/OpenVR-InputEmulator/blob/master/driver_vrinputemulator/src/driver/VirtualDeviceDriver.h#L25, It seemed that you suggested that it was possible to perform this without writing a OpenVR driver (Although this does seem simpler to do than I first thought).

hooks are, however, used for all other features.

I was unable to find an API or setting for offsetting an individual device's tracked position (Used by VRPlayspace mover (on all devices) and OpenVR-SpaceCalibrator (for mixing Rift HMD & HTC trackers))

My main concern is about VRPlayspace mover (As it's more feature rich and stable than Advanced settings' virtual move) and OpenVR-SpaceCalibrator.

VRPlayspace can be ported to the OpenVR SDK by using the same API that Advanced settings is currently abusing (At the cost of excessive disk writes). It seems that VRPlayspace's had intended to add roll/pitch control as well, which would not be possible with the same API Advanced settings uses.

OpenVR-SpaceCalibrator seems to no longer depend on Input Emulator, instead adding it's own hooks. Persumably they failed to find any API for offsetting an individual controllers pose.

[pottedmeat7]

Yes anything that requires offsetting poses or altering actual poses of physical devices would require hooks. I don't know if there is any other more stable support for those features, that may be nice... It does seem if you do use the virtual device feature of input emulator that it uses the supported methods, I guess you would just have to make sure that is what you did versus sending input into a hooked device. I'm just pointing out that sending input and rebinding into physical controllers now actually works, whereas before it didn't.

[SplitPixl]

Since the SteamVR developers seem to be paying attention to this tool, at least when they first implemented the new binding UI See this post, I am curious if we would ever get a built in API in OpenVR for manipulating pose or adding pseudo-controllers that isn't using drivers.

[suncryptjustice]

Looks intresting, But as i understand for Input emulaor it's kinda useless right now?