Firstly, you’ve made realy great work! I’ve downloaded the plugin for physical grip, but found many interesting things in it.
Unfortunately, I occured a bug that crashes the editor (2017-10-10 commit). I’m not sure about what causes the crash, but it always crashes when I use OnChildGripRelease on specific blueprint. Also I’ve detached my bp code from release event to be on the safe side, but it didn’t help.
Output: [SPOILER]
Since you are adding them to your own project you may need to enable the Advanced sessions plugin in the plugins list.
Also if you aren’t planning on using advanced sessions you can delete the server info and 3D Menu blueprints and just not have the plugin at all, it is only used to handle that server browser widget in the template level.
I verified the HMD is getting tracked with a template project, but fsr it isn’t getting tracked in a non-template one. The VRchar is immobile. I can see my hands right out in front of me, but I’m stuck at the position of the Player Start.
I tried to debug it, and it looks like the HMD isn’t getting recognized as being on in the Player controller.
Shouldn’t need to do anything, the camera locks to HMD by default. Unless you turned off the VR plugin or are trying to run two editor instances at once it should work when stereo is enabled/turned on (you may have forgotten step?).
I wasn’t adding the Advanced Session plugin to my own project. That project I got working well with only the VRExpansion. It was just the template project that was problematic. Good to know about the server info and 3D Menu, thanks!
New, unrelated question:
I now have LAN multiplayer working in my own blueprint project and I’m using the VR Simple Character as the basis for my pawn. The head and hands replicate smoothly on both server and client. However, when the client side tries to move his head, the world starts moving very glitchily/ weirdly for him. happens on only moving and NOT when rotating the head (rotating the head and motion controllers are smooth). It kind of feels like the server is feeding back and setting the HMD’s location to the client. Why could be?
I’m trying to make small mini game where you throw a ball between players, I made a grippable static mesh with the default grip interface settings, but when I throw the ball, there’s a frame where the ball continues to be attached to my hand before it receives the update from the server that sets it to the correct position. I’m using the template character.
What is the best way to have remove “jitter”/desynced frame before the server updates?
Regular vr character is more involved and custom, the simple one is an easier / safer fallback in case something terribly breaks about how I do the main character at some point.
I tend to promote the main character now that it has been fine tuned, and most of my testing is through it so sometimes SimpleCharacter bugs last a little longer than on the main character.
I’ll need to test again, the simple character isn’t really intended for multiplayer like the main character is and it may have fallen back on somewhere during my networking performance overhauls.
I probably missed a variable when changing everything recently, i’ll look into it.
You can run the grip on the ball with a full client side authority grip (doesn’t wait on server verification) will grip and release immediately. If the ball replicates its position though you can still get a correction from the server side when it starts replicting position after it gets the drop notice…
IE: Client releases, sees it fly away, server gets notified PINGTIME later, server drops with velocity and starts replicating position, client gets updated to the location PINGTIME x 2 ago.
The solution to that is full physics prediction and replication…which is not an easy task.
You could also fake it and have a non position replicating ball which can get out of sync depending on the physics sim, you can trend it over time to the servers position to account for that or just completely ignore the fact that it might not be at the same location.
Or server side movement which requires some custom logic to get working correctly since the default engine replication only functions when given a physics velocity for prediction.
Edit Easiest method might be to hide it until the server updates so you don’t get the warp after it is thrown.
Don’t miss that it is fixed already though :p. The simple character just lacks a few features that the advanced one provides, but is easier to understand for the user and upkeep for me ( is the second bug reported on it since it was made even though I have overhauled the main character multiple times and changed the base character backend a ton).
I probably mis-stated there, it is multiplayer capable, but I run most of my iteration on the main character, since the simple char is so stable it gets less testing.
Also as you saw, walking around when the server is correcting your position can roll back your actual location, which is why I feel the advanced character is better suited to multiplayer.
With the advanced character you won’t get positional rollbacks from walking, only locomotion or collision with things, so in high packet loss situations it won’t induce as much nausea.
That was the step. Never knew such a setting (Instanced Stereo, in Project Settings) existed. Thanks a lot!
Edit: Scratch that. Didn’t work. After enabling Instanced Stereo and restarting, seems SteamVR’s saying UE4Editor isn’t responding. Restarted again, making sure no other instances were running. That previous error went away, but the Camera/HMD is still stuck at the bottom of the capsule.
The ss shows what it looks like when the controllers are off. Turning 'em on, they disappear - probably are moving to their proper position relative to the capsule. (I’m working in a really confined space where the ground is out of sight of the sensors, so I can’t verify if they’re getting tracked).
I’ve verified the proper character is spawning at least.
Thanks a lot for the reply. I don’t recall seeing a step-by-step for the bare minimum requirements of getting a VRcharacter class up and running (I mean, just have it take control of the HMD and MCs).
Downloaded the default template 34f41b9built it and tried to run it, but even then I’m getting the 2d character by default (can move around WASD style and jump, but that’s it). I’m running 4.17.2 and I haven’t updated SteamVR in a little over a month. Could that be a problem?
Btw, I tried sticking that “EnableHMD” console command on begin play in the level blueprint of the template, but the HMD still isn’t getting recognized.
I’ll see if I there’s a SteamVR update.
Posting excerpts from a conversation I was having in the patreon discord for general public knowledge. Goes over some of the 4.18 secondary grip additions that I added. I will go over things in more detail in a video and patch notes later, but figured since I already wrote , might as well copy and paste it here.
Edit and to be clear, yes the distance based influence is based on the original concept that Node talked about, it is a good idea and was easy enough to support so I added it in.
Maybe the newest version of the plugin example template doesn’t have it enabled by default? I’m not saying it should, but I’m pretty sure older versions of the template (up to a month ago) had VR Preview set as default, because I’ve never had to enable it.
Thanks for the additional info about VR preview and HMD detection.
That is an editor feature that is automatically enabled when it detects an HMD, but it normally shows your last used mode, so it likely showed VR preview for you before because that is all you ever launched it with.
Upd: Ok, I solved the problem. Collision complexity was set to “Use complex as simple” in my mesh. Everything works fine after setting “Project default”. But still it looks like a bug.
[/SPOILER]