That is a good point, these problems have started after the Home Beta update. I’m gonna do some further research, thanks.
Pushed new commit to the plugin (4.16 master branch)
Skeletal mesh fixed when it has a rotated root bone and is gripped with physics
Still not as optimal as I would have liked, but having to deal with center of mass
and the root bone rotational difference between physics body and main is aggravating.
Also fixed the center of mass setting to an offset location when the object is scaled.
Added ClientSideAuthoritive_NoRep grip replication mode, acts just like ClientSide_Authoritive
except it doesn't tell the server about it. Basically it behaves like the old LocalGrip identifier.
Added IsALocalGrip function to the blueprint characters to clean up checking BOTH of the modes
instead of just the one in some spots now (IE: where it chooses to call grip on client or server
side).
Set all grippable components to auto replicate by default.
Otherwise a lot of funky things can happen, I think I removed setting a few patches ago but it
has proved to be important in most cases in multiplayer so i'm forcing it to default true
again. Can still be disabled if you want.
*Note* Stereo layer widget components appear to be updating incorrectly all of the sudden, I think has to do with
the new steamVR patch. I haven't found a fix yet, I can't test on Rift to see if it is working as intended there at the moment.
Hey !
Judging from the demo vids, and wiki pages I must admit that it sure seems like you’ve done some amazing work on that plugin.
Also it seems you’re very active in updating and developing it which really makes using it in long-term projects a valid option.
Our studio has recently released an indie VR title on steam (Save 80% on Galactic Core: The Lost Fleet (VR) on Steam).
The last week few weeks have all about learning and designing what’s necessary to evolve it into a VR multiplayer game (we’re thinking dedicated servers).
In any case, I’ve been struggling to find an efficient way of play-testing VR multiplayer in the editor.
I mean even the most basic things, like checking if a replicated actors behaves as expected, if all client’s received some RPC call, if game is consistent between clients.
So a few questions in terms of general multiplayer VR development workflow:
- How do you test multiplayer functionality each time you make a change?
- Is it possible to some how perform testing for 2 clients and a server using just a single PC and headset (even if the other client is just running a keyboard/mouse version of the game)?
- Any debugging tools /tips you could share from your experience?
Commented in bold above
“In 2D, I have a function setup so that if I am not specifically launching in VRPreview then it uses a copy of my character with the head and hands locked (ie acts like a normal character).”
Yeah I get what you are saying, we have a similar “KMS mode” setup that runs if HMD is not connected. Is yours available in the template/example project that’s currently available?
“See above but set client or server to non vr mode, can launch from uproject without packaging for local testing”
You mean running the editor from the cmd like “…UE4Editor.exe” “C:\Users\vr\Documents\Unreal Projects\NextStep\myproject.uproject” 10.100.102.2 -game -fullscreen -log -nosteam"?
And do you actually run your multiplayer testing way as well, having clients/server all run on a single workstation?
“You appear to have some more complicated movement systems in your game”
Even though it comes off as being complicated, I’m hoping it should be not too complicated to pull off in multiplayer, since it’s mostly navigation which by itself is predictable and should be able to run almost completely on the client side (once a path has been calculated on the server).
However since I’ve completely ignored the character movement component in my implementation (I mainly use the “set location along spline” + “Set actor location”, more or less) and so completely ignores not only physics (which we handle artificially), it will also not be able to take advantage of the built in network features such as correction etc.
Needless to say, I manually handle the whole syncing of the “character location relative to camera/HMD offset location etc.” logic myself.
That’s why I was looking in to your implementation as it seems to almost magically combine the best of both worlds.
Correct me if I’m wrong but using the “navigation” locomotion option you displayed I could achieve a similar result, at least for walking around.
For the jumping I would have to choose between the physics approach which you use and a “spline movement” approach which we currently make use of
In any case I’ve downloaded the example project along with the plugin and will be trying it out and playing around with it asap.
Yeah you can connect to local machine servers with -nosteam and Open command or lan sessions.
The navigation setup I have is a bit different, you likely use an AI controller, I don’t, I just moved some of the AI controller functions into the player character so that I could navigate in there. However something you would want to consider is that with the default navigation in engine the navigation is server sided only. In my plugin I specifically send an additional variable to the server from the movement component so that client sided navigation is also possible in engine.
Hi ,
Quick question: I have a bow in my game and until recently I was able to modify the rotation of the bow (while gripped in “Physics Only”) just by setting the world and local rotation in the bow blueprint every tick, but since 4.16.2 won’t work anymore. It’s like the grip is resetting the rotation every tick. The blueprint object is just a static mesh actor.
Do you have any idea what might be happening? In grip mode “Hybrid” it applies the rotation correctly.
Thanks! 
The only reason that worked is because the tick order of the controllers was before the tick event you were using in blueprint, so your tick ordering is off. There is nothing specific to the grip that changed on my end that would effect that and even if epic changed something I am not aware on in 4.16.2 you should still be able to overwrite rotation when the tick happens after the initial movement.
You have a few options
-
Switch the primary tick of the blueprint to post physics (controllers are pre-physics so they tick prior to that)…not the best option as any physics collisions would be 1 tick behind.
-
Add a TickPrerequisite of the controller to the object after it is gripped (forces it to tick after the controller), you would then get reliable tick ordering, is easy and you could keep your current logic.
-
Use the AdditionTransform to handle the rotation directly in the gripping system and without having to overwrite anything.
Edit I just remembered that the tick preres is already automatically being set on grip so that actor tick has the correct locations, so that should already be working.
I will also note that there is little to no reason to even be using a managed grip if you are already setting the location and rotation on each tick, you would be better off using the “Custom” grip type and moving the bow in the TickGrip event. would bypass all of the logic that you are already throwing out making it less intensive and also giving you complete control over the movements.
Actually I just use the navmesh to calculate the waypoints then I handle the navigation myself instead of using the engine’s NavMeshWalking - I do it by generating a spline from the waypoints and walking it as my path.
I ended up adding the Tick-prerequisite, it was cleaner in my setup and worked perfectly. Thank you so much! 
BTW, where is the TickGrip event? I looked for it in the grip motion controller component but I could not find it.
Tickgrip event is in the object itself that has the interface implemented. That way people can do the exact same logic they used with epics grip but using plugin.
Also were you doing something weird like attching the bow manually or something?the grip function should be adding that tick preres automatically.
Edit Actually are you gripping the bow as a component and moving it in the actors tick? That would explain it actually as I only set the tick pre-res for the gripped object.
Oh Ok, I just found it thanks! I will try to change the current approach and change it to a custom grip, it’s a much cleaner solution.
The bow is a static mesh actor, and I grip it with the grip motion controller component in my pawn using the “Grip Actor” Function. Then in the tick event of the bow actor, I change the world location of the static mesh root component. The reason is that I want to align the bow with both hands while maintaining an upright position. I’m pretty sure there’s a better way to do it though
- Is there something I can do (a function or setting) to keep the grip settings “stiff” after I scale down, then up, a gripped actor? Right now the grip becomes loose on the physics constraint after scaling down then back up.
How are you scaling it? Though the addition transform or something else? It sounds like you are some how moving the center of mass. I need to know the steps you are taking so I can see whats going on.
*Edit* also what version / date are you on? I had to fix a bug with the new COM on grip setting and scaled objects.
Version is the 4.17, whatever was latest as of yesterday.
I was just scaling it using the regular scaling node (Set Actor Scale 3D on the gripped actor) - should I use the additional transform thing instead?
Edit: Weirdly I changed it to re-enable collision after a 0.2s delay instead of immediately after leaving the trigger and it seems to keep the grip settings.
If you were using the template version that would make sense, I forgot to sync 4.17 to master on friday.
Hey, so there is definitely something off in 4.17 regarding physics bodies. The scaling grip is also running into some weird behaviors that feel like thread sync issues when its a physics grip.
It may be that their changes to the Async collision setup in UBodySetup is causing these problems, as the exact same code in 4.16 has no such problem. Having to delay to re-grip correctly would actually make some sense if the new physics task batching was getting in the way (hasn’t been processed yet).
I’ll check out the new console command they added and see what it changes.
Edit Yeah…so confirmed, the new console command p.BatchPhysXTasks is interfering. Since it is delaying physics tasks until later its not actually resizing the mesh until after you are re-gripping, thats why if you delay the grip it works as expected. Even setting the console command to 1 or 0 (defaults to 1 then) it still behaves worse than in 4.16 as well…
Good to know I’m not crazy. For now the delay is working fine at handling the problem, and the grip stays stiff as expected.
I’ve been having a different problem which is when I have any reference to my backpack blueprint (a grippablestaticmesh) in other blueprints like the player, or vice versa, it causes a crash before the scene loads.
Whats the crash log? You sure you aren’t referencing it before it has been set?
It crashes before a crash log can be made, and it happens if there’s any reference to the backpack BP (so even if it’s just a get all actors of class, or even a child component).