PSMoves unresponsive/not recognized in some apps while others work as intended

[bifurk8]

I'm thinking this is something particular to my setup or something that I've done wrong - but some apps won't recognize the move controllers as Vive wands, while others work as expected.

For example, Audioshield, Space Pirate Trainer, SoundStage, Job Simulator, and Tabletop Simulator all work well, but Fruit Ninja and DEXED don't seem to recognize that the PSMoves are Vive wands. The bulbs light up and are seen by SteamVR, but once in Fruit Ninja the sword doesn't move at all so I can't slice the menu options to start the game. In DEXED, the opening screen asks you to pull the trigger to start the game, but it doesn't recognize trigger pulls from the PSMoves.

Has anyone else had issues in some apps but not others? Any tips for working around apps that don't seem to recognize the controllers at all?

[s7ran9er]

Can confirm this behavior too.

I have no move tracking in The Brookhaven Experiment and VRMultigames. Both of these uses unreal engine (maybe that is why?). In these two games i could not even open steam overlay with ps button on the move controller as if it's totally turned off, but leds are lightened. Audioshield and Space Pirate works well.

[bifurk8]

DEXED is Unreal Engine but Fruit Ninja VR is Unity-based, and neither works for me, so I don't know whether the engine is the culprit or not. I haven't had the chance to try Brookhaven or VRMultigames though.

[HipsterSloth]

@bifurk8 Are you using an Oculus headset? We have seen issues in other games. There was a really long issue thread about this for "The Thrill of the Fight". For unity games, this can be an issue with the order the game specifies the order to check for VR APIs and if you are using an Oculus headset. From issue #94:

Here's what I did: 1) Installed Unity 5.4.0b21 2) Created a test project 3) Went to the player settings 4) Checked the virtual reality support option 5) Added the "OpenVR" to the list of Virtual Reality SDKs (which was empty) 6) Went to the asset store and installed the SteamVR plugin 7) Opened the Extras\SteamVR_TestIK and Extras\SteamVR_TestThrow 8) Recorded the following two poorly captured videos for your viewing pleasure

TestThrow: https://www.youtube.com/watch?v=oUWP-MxEnXI TestIK: https://www.youtube.com/watch?v=Y-3sQG1lAco&feature=youtu.be

As you can see from the videos the controller data is coming through.

Then it occurred to me if we also added the "Oculus" virtual reality SDK to the list of available and make it first in the list Unity may attempt to open the SDK in the order listed. If this was true, and Oculus is listed first then it would never attempt to open the HMD/controllers through SteamVR. The controller poses would be coming from the Oculus API. And since I don't have touch controllers there would be no controller pose data coming through

I have Fruit Ninja at home. I can give that a try tonight. Perhaps something similar is happening from Unreal games.

[bifurk8]

Yes, this is with an Oculus Rift CV1 and so far only affects Fruit Ninja and DEXED from those games that I've tried. I've seen other users with non-Rift HMDs successfully using the PSMoveService with Fruit Ninja, so I wouldn't be surprised if it's related to the Oculus API taking priority and preventing the controller data from coming through to these apps.

*Edit: I imagine it's something like these devs have already implemented Touch controls or are in the process of doing so, they detect that the HMD is a Rift, and they only look for Touch controls. That's just a guess, though. I've had the same issue with AltSpaceVR now that I think about it and I highly suspect that's what's going on in AltSpace since they do seem to do some extra device detection that most apps don't (Vive, Rift, Leapmotion, etc).

[HipsterSloth]

Fortunately on the Unity side it's a pretty simple fix (for the developer)

They need to switch this:

To this:

As for unreal games it looks like you might be able to edit an ini to get steamvr to initialize:

https://steamcommunity.com/app/468700/discussions/0/359543542240148654/ Just goto \Engine\Config\BaseEngine.ini and edit the priorities so SteamVR is higher:

[HMDPluginPriority] OculusRift=10 SteamVR=20

I'd be curious of the ini file approach work for DEXED. For Fruit Ninja we might have to reach out to Half Brick.

[bifurk8]

I'm afraid DEXED lacks that ini file. The only other Unreal Engine based app I've got is SculptrVR and it's missing the ini too.

In fact, now that I've tried it, SculptrVR has the same behavior of not recognizing the PS Moves and it's even more obvious in SculptrVR that it's detected a Rift specifically and looking for Touch controllers, because I can see Touch controller models laying on the ground, unresponsive.

So yeah, I think you've nailed the cause of the issue, but there's probably nothing to be done about it within the PSMoveService.

[s7ran9er]

There are "\Engine\Config\BaseEngine.ini" in the Brookhaven Experiment and after modifying HMDPluginPriority key with suggested by HipsterSloth way PS moves appears in the game and it becomes playable (although it needs 360 degree of tracking, which i'm lacking atm).

In VRMultigames there are no Config folder and i suppose configs are in the "Content\Paks\VRMultigames-WindowsNoEditor.pak" file, but i did not tried to unpack it to be sure.

Anyway HipsterSloth thanks for the tips.

[YossiMH]

If I put

[HMDPluginPriority] OculusRift=10 SteamVR=20

into C:\Users\[UserName]\AppData\Local\[AppName]\Saved\Config\WindowsNoEditor.Engine.ini for VRFunhouse or Raw Data, the game appears in the SteamVR display mirror and I see it tracking the PSMove controllers... but it won't display on the HMD. The HMD just shows the Oculus "App is taking a long time to load" screen.

[YossiMH]

Actually, the Windows 7 compat mode suggestion made here https://github.com/cboulay/PSMoveService/issues/94#issuecomment-233099839 seems to address the issue.

[bifurk8]

Hey s7ran9er,

When trying Brookhaven Experiment, are your trigger pulls on the PSMove controllers recognized?

[s7ran9er]

Hi bifurk8.

When i first tried Brookhaven Experiment after modifying hmd priority it worked like intended (ps moves were recognized, it displayed on the hmd, trigger pulls were working and all that). But i tried it right now and i was getting the same problem as YossiMH: everything was working (ps moves, head tracking) but no display on the HMD. Tried to turn on the windows 7 compatibility mode and it solved this issue. Weird thing is it was working before and i'm already on win7...

So yeah, it is working for me right now.