I’ve hit a bit of a snag in my development of a multiplayer VR experience that I’m hoping someone can shed some light on or maybe point me in a direction I haven’t considered. I have plenty of experience with the UE multiplayer framework and design paradigms so I’m not having trouble in that area. The issue is with any non-server side camera management. Playing single player, or as the host, everything works as you would expect meaning you can look around and move as you would in any other VR experience. When you connect as a client to a hosted session it’s a whole different story. I’ve never felt so nauseas so quickly . It acts as if the world is locked to the HMD rotation (ie roll, pitch, yaw). When you look up, the whole world rotates up with you. Anywhere you move your head, the whole world moves with it. I’m still sweating after that experience .
Now, I’ve managed to replicate the effect in single player mode by turning off the “Lock to HMD” flag on the pawn camera. This leads me to believe that when I’m connecting into the server, for one reason or another, the camera on the spawned pawn (or player controller, or camera manager) is not being setup as if it were an HMD camera.
Has anyone experienced this before? Any thoughts on where to poke around? I’ve begun to poke about in the engine code at the player controller and camera manager. There are certainly places that look to see if head tracking is enabled, it’s just not readily clear to me why it might work just fine in a single player setting, or in a multiplayer setting as the host, but not for a client.
It sounds like your pawns and player controllers are not working together nicely. By default if you spawn in a pawn (or anything), the server will own it, not the client necessarily. You need to make sure that when the client connects, its player controller takes possession of the pawn. This can be done from the game mode.
Thanks for the guidance. I should have updated my original post but this issue resolved itself when moving from 5.0.0 to 5.0.2 (might have also been fixed in 5.0.1) with no change to my player/pawn interactions.
Well that’s interesting. I wonder if they changed the behavior for pawn cameras or it was some other problem to begin with. Glad it worked out in any case.
From the game mode you have an event called onpostlogon or something. It delivers the name of the newly connected player controller. Using this and the name of a pawn (the game mode may just spawn the default one automatically, as this behavior isn’t visible in blueprints I prefer to set the default pawn to none) that you spawn for it, use the posses pawn node from the game mode.
I finally fixed the problem. I created a custom PlayerCameraManager, overrode the BlueprintUpdateCamera function with this code, and assigned a custom camera manager in Player Controller. Not a perfect solution, but it works. I will post here if find a better solution
So, the reason for such behavior is how to Oculus plugin works. IsHeadTrackingAllowedForWorld checks that PID instance is 0 but the simulated server is already using 0 and the first client getting PID 1. So, I just changed the condition as in the screenshot below. Everything works fine now
. It acts as if the world is locked to the HMD rotation (ie roll, pitch, yaw). When you look up, the whole world rotates up with you. Anywhere you move your head, the whole world moves with it. I’m still sweating after that experience 
.
