Hmm… I am having problem with plugin. If I ever set GameModeto be something, the controller stops tracking and I cannot do anything. Even if I spawn into worls through playerStart. Controllers ain’t tracking. If I put my character in game and use default GameMode, all works. Any idea what the problem is?
You are likely spawning in the FPS pawn then, its set to not track with the controllers.
The template has a player controller that spawns one or the other pawns depending on what you are doing, you can just override .
Added new game to the WIP list
Hi! thanks a lot for plugin is awesome!
Just wondering (maybe I havent checked all the info) but when the second player in a multiplayer game appears he see the vive controls instead of the hands like the first player, it is possible to make the two players appears with the hands mesh?
Remove the nodes in the big red comment box labeled “OPENVR ONLY” in the character. It only loads the controllers to give an example of how to do it with the model loading nodes.
Hey! Thanks for amazing plugin!
I have a major problem with my project. When I run the project, my motion controllers go inside of the collision of HMD(or camera) and it doesnt seem to possess the pawn correctly. Does any one had error before? I attached some images of the problem
Thanks in advance
Hi,
I m have been trying to get the example template to work for the past 2 days with no lucks, I followed the instruction to switch the engine version (success with no error) but no project file was generated, then I click on the generate project, still success with no error but no project file gets generated.
Is there a pre-build version of example template for 4.18 I can find?
Thanks.
Realized the issue is that i have both VS 2015 and 2017 in my pc, and C++ only lives in 2017, fixed my issue after uninstall VS 2015
Anybody else experience crashing with 4.19 version template here https://bitbucket.org//vre…/?tab=branches ? When playing template it suddenly might crash or when you quickly tap the trigger, the crash might occur. It known problem?
Its 4.19, in editor in VR there is a crash that results in an infinite garbage collection loop.
It happens in the default template as well.
Aah thanks man. So nothing can do but to wait. Or is there any known “hack” to bypass the crash besides somehow disabling the garbage collection temporally?
Alternatively, is there a way to convert the newest progress of the plugin to Unreal Engine v4.16, that seems to be the best working version of the Unreal so far? I tried to change the Unreal Engine version to 4.16, but it cannot compile the Plugins anymore. I saw, that v4.16 branch is many months behind the current branches so it might missing some stuff.
Thanks a lot for the plugin.
Hi Fellow VR Devs! Just wanted to share a bit of gameplay from what I’ve been building with the plugin. BearHammer Virtual Reality Games Development--Playtest Party of Arcade Mode - YouTube. Thanks so much again is an amazing experience to be able to put together VR games!
Check the GameMode in World Settings, i have some similar problem creating a 2d menu lobby for a multiplayer game and when the game launch one hand was missing so in my case was the game mode it works super good if you use the SteamVR_GM in the map level
Needs to be bug fixed on the engines end afaik, others have been running into it without the plugin as well, since 4.19 is a preview build its not the largest deal unless it releases with it still broken.
There is far too much incompatible across 4.18 and 4.16, Epic changed a lot of the back end. You could start with the 4.16 build and cherry pick features from the commits to add to it, but I don’t specifically support all features backwards. A lot of the additions require/d deep character modifications to do and so they would have to be re-written for older engine versions.
If it is something like the interactibles or the gesture component, those should just slot right in without a problem.
Although, while 4.16 was the most stable, I still consider 4.18 the “best VR patch” so far.
“sucked into” sounds like tracking loss more than anything else, more so if they don’t track at first anyway.
Regardless as Kaiser said I have the gamemode set to use the player controller that spawns the correct character, make sure you have either that, or use your own gamemode and spawn the correct character.
Hey, man! Absolutely love your work here, plugin is a godsend, it solves so many of our issues.
I was wondering though, because there’s one issue we still have. Our game is multiplayer, and we have a mechanic where the players can throw items at each other. Using the Client Authritative movement replication setting, we are able to replicate the gripped movement very smoothly and have the clients be able to pick up items as well. With most other replication settings, it seems the client either doesn’t replicate its gripping or isn’t allowed to grip the actor. The issue however, is that only the host player preserves the momentum of their throw, whereas clients lose all momentum and the item just falls straight down out of their hands regardless of how hard they try throwing it.
Do you have any idea how we can fix ? With most other replication settings, it seems the client either doesn’t replicate or isn’t allowed to grip the actor.
You were missing the log messages from the other attempts, Client authoritative is the only grip type that can be called on the client (it auto replicates the grip upwards so the client has no noticable delay). All of the other types have to be called on the server. I don’t auto RPC those for people because they may want to pass verification data along with the grip request.
You can see the template structure if that is confusing for you, it checks if it is an authoritative grip or not and RPCs it or not.
Generally for things like throwing objects back and forth I would suggest that you use the ClientSideMovement replication mode, while you will have a slight delay while the server inits the grip, it will sync better overall, client authoritive is generally to be used for things like guns and objects specifically for the owning character.
Edit Loss of momentum on the client authoritative isn’t intended though, that may be an actual bug, i’ll look into it.
Edit2 While it shouldn’t have been causing no momentum, the client authoritive wasn’t passing the momentum from the client up, which is needed for a throw to feel correct. A fix for that will be in a patch today later.
Thanks a lot for the great, in-depth reply!
I hope I’m not being too pushy, but I’ve done some more testing and I still can’t quite manage to fix the issue. I tried replicating the Grip Actor / Drop Actor calls and have them use the Force Client Side Movement option. does indeed seem to make clients able to pickup and drop actors just like the host, albeit with a slight delay and much better syncing afterwards as you mentioned. However, when the client tries to throw the actor it still just drops straight down, whereas the hosts attempts all end up soaring away as you’d expect.
I’m thinking maybe the “Simulate” option for the drop function call might not work as intended for clients in a listen server. Back when we were trying to make our own networked VR gripping system we manually set the items physics to not simulate on grip, and then simulate again on drop. worked just fine for the host, but just like now it made the clients items simply drop straight down from their hands. It seems to me that maybe the momentum or velocity calculated by the physics engine are simply lost on the client side. I used to suspect was some weird property we’d accidentally set somewhere, but in my tests now I made a blank VRGrippableStaticMeshActor in which I only set its mesh, had it simulate physics and generate overlap events, so I’m no longer so sure if it’s caused by something we’re doing wrong on our end.
If it’s the case that momentum/velocity is simply lost or never calculated properly on client side, I’m thinking maybe our only option would be to start calculating each hands velocity on tick and passing these values along to the option velocity paramters instead of using the simulate option. Having it be properly simulated by the physics engine would of course be preferable, but as it stands now it seems that just won’t happen properly on our client side for some reason. Which is odd, as I’ve seen it working fine in other projects.
I also tried updating to the newest version of the plugin (We are using the latest 4.19 preview), but in case the plugin wouldn’t compile. It claimed the “FScopedMeshBoneUpdateOverride” at line 1330 in the VRSimpleCharacterMovementComponent.cpp file was an undeclared identifier.
Finally, wasn’t able to find the part in the exampletemplate where it’s checking for authoritative grips, so my solution was to just RPC all grips and drops as server functions as calling these on the host should have the same effect as calling them on a client. And I’m not quite sure what you meant by :
Its all working correctly for me (aside from needing to change some brackets in the latest patch to cover when not sending the velocities for client auth).
Are you using the optional angular / linear velocity inputs to the drop node? If you have the inputs reversed it would cause it to appear to drop straight down. But other than that it should be working fine, the plugin already sets simulating automatically and no, clients get velocity applied.
The velocity of attached objects aren’t calculated, but i’m not attaching these objects to the hands and even if I was I am reading their physics body velocity not their component one when I pass in the optional velocities and those update anyway.
The point of the optional inputs is so that clients get the velocity of their release applied to the throw instead of relying on the server to be “close enough”.
Also thanks for the heads up on the scoped call, I hadn’t built a non unity build in a bit so it was skipping over that, I updated 4.19 to fix it and ran a full non unity build to confirm (I generally run those near the end of a version update as I am usually the only one on the previews).
I’m currently messing around with expansion to use as part of a hobby game i’m designing for VR. I’m very new to all but so far have found the plugin to be great.
My current issue is that i’m trying to implement a holster system and i can’t quite get my head around why it isn’t working. The just of what i’ve done is on the event of a griprelease of the gunbase it checks to see if the gripped object component is overlapping the holster collision, if it is then attach the gripped object (the gunbase) to the LeftHolster socket attached to the LeftHoster mesh.
I apologise if i’m coming at from the completely wrong way but, like i said, i’m very new to .
If anyone can point out where i’m going wrong i would great appreciate it (or even share some tips on a better way of doing it)
Hi all, someone can tell me where download the 4.18 version? i can’t find it on the branches tab (https://bitbucket.org//vrexpansionplugin/branches/)
thank you