Lan mode for steam works a treat. Thanks again.
You want me to cut the doors and trunk out with some booleans? I’m not really a rigger, but I’m sure I can get some hingeable doors working. Probably won’t be pretty… just functional. Just let me know if you want it.
If you get the time and feel like it sure, but its not the largest deal. After all its basically just another lever then triggering on angle, now that the levers are in there are all sorts of uses for them 
Added another game using the plugin to the OP page
Hello I’m still a little new to Unreal and am confused as to how I access the plugin once I have downloaded and unziped the file:
4.17.1 - 8/16/2017 - Full Binaries and Source Package I honestly feel like should be a really simple step but for some reason its not clicking for me. Could any one help me out?
Check out the step by step guide linked in the first post that a nice community member made.
Hi! I’m back. I have a question. What is the proper way to spawn an attached Weapon to an slot in the body?
I’m trying to spawn and attach to component (as Body and Potion).I spawned a Weapon (Grippable Skeletal Mesh) in the Event Possessed in the server Side, but not appears in the Clients. If the Weapon has replicated, why i need spawn on every Player?
I tryed in a BLANK project, and works perfect spawn a object in the Server side (if marked as Replicated, Relevant) and all player see the actor attached. But in the Grippable Skeletal Mesh not works.
I solved Replicated manually, spawn on Server and on Every Client. But i don’t Know why happens .
I suposses that is a mechanic on your plugin, but i need understand .
PD: Sorry for my English.
Make sure that it is set to replicates, the plugin doesn’t change anything to do with standard replication and spawning logic and a quick test with a GrippableSkeletalMeshActor works perfectly fine.
I was able to “re-produce” by making a blank blueprint actor and attaching a GrippableSkeletalMesh**Component **to the root, but that is only because Replicates is defaulted off on blueprint actors, you should be able to just switch it on (or use a GrippableSkeletalMeshActor instead…).
Yes, is set to replicate:
is My Weapon Base Class, extend your GrippableSkeletalActor class.
is my method on Character class to Spawn the Weapon on Event Possessed.
The attachment pont is a holster in the ParentRelativeAttachment, the Holster is set to component replicate.
And then i call method in the Event Possessed, in the server side.
And AssignClassWeapon is :
But only server spawns it. If I put the AddWeaponSlot in a Server event, and Multicast without Server, all Clients Spawn correctly the Weapons. But Why? If the Weapon is Replicated, the Server shoulded spawn Weapon and everyone sees the weapon.
I don’t know why it isn’t working for you, there has to be something additional that you haven’t stated.
I tested by literally spawning off of the same node as you, with a default grippableskeletalmeshactor with a generic mesh and attaching it to the waist component and it all worked fine.
You aren’t spawning the hip attachment points client side are you? They are either a default part of the character or spawned server side?
Because the attachment replication wouldn’t work correctly if the clients don’t have the same slots as the server.
You can run some kind of notification code (pint to screen) or breakpoint on tick clientside only to check if the object spawns but doesn’t attach correctly.
The SpawnPoint is a default part of the Character.
In the Server works correctly, but in the Client not, the server sees the Weapon Clients attached and spawned correctly, but the Client don’t see any weapon. I can’t do Pin because i can’t test multiplayer without compiling. (VR Preview don’t works with two player set in Multiplayer Settings)
I’m sure is my fault, but i don’t know where. All the rest mechanics works awesome great, i’m feel stupid, it’s a easy thing and I have not had a problem with all the hardest.
is my Character Spawn point. Is for use a SphereCollision?
Thanks any way .
Don’t set those to replicate, they are just attached to the parent relative attachment, their position can be done locally.
Regardless that shouldn’t effect attachment to them.
You can totally test multiplayer with two 2D pawns though, the logic for isn’t any different than with VR pawns.
Whoa!
Effectively is an attachment problem, it’s fixed now. The 2D trick saved my lives and my time, I can navigate and see the weapons in somewhere in the map. I adjusted the attachment and it’s Works. Thanks one more time, you are so awesome.
So were are using version 4.15 and have added bots to the game. These bots inherit from the Simple VR Character. We have a bug that when the player moves the headset, the bots move aswell. We are stuck for a fix and wondering if you can think of something we are missing? It seems to be caused by capsule/movement component but thats as far as we can get with it.
That isn’t really a bug, bots aren’t supposed to inherit from the SimpleVRCharacter, you are introducing additional overhead to them by using that as a character base.
I “could” add a variable that you could set that would skip the headset positional checking in the simple character, but I feel like that would promote bad behavior?
By using the simple character you are adding in two motion controllers, a camera, and some overridden movement logic, all of which shouldn’t be in a bot if you want to keep best performance.
The “correct” thing to do would be to use a standard character with animations and run it like any normal bot in engine.
That being said, if you really really really want to use the simple character for bots for some reason, I can make the hmd locking able to be toggled on it. I have it toggled on the VRCharacter for testing reasons.
Edit Added in a bSkipHMDChecks variable to the SimpleCharacterMovementComponent, it can be used for debugging with the simplecharacter anyway (It needs some love, the VRCharacter is more feature complete). It has been merged into every version from 4.15 - 4.17.
I would still suggest that you take the time to use a normal character for bots instead.
Thanks for the reply,
We ended up managing to fix it by disabling the movement and controller components on begin play which solved it for us.
We only need to get the bots to ‘just’ work for a demo very soon and when we fully implement them we plan on making a full new bot system as you said.
Ah, good…
The boolean is still there for now for 2D debugging.
Pushed a new commit to the plugin tonight
Early implemented a new method of handling the controller late updates that Epic is
using in the upcoming 4.18 patch.
It utilizes a double buffer for the scene references in the render thread and effectivly
solves the high velocity tracking issues that were very evident before (when moving fast
the controllers late update would send them flying all over).
also started adding some comments for incoming 4.18 changes to remind myself.
There will be a lot of changes incoming due to OpenXR starting to be supported in engine.
I have some custom hands set up similar to how they are in the VR project, where I reuse the right hand mesh with inverted scale for the left hand.
There’s a socket on the mesh of a Grippable Static Mesh Object where X, Y and Z is changed (none are 0). It works good on one hand, but the Y is flipped on the other. I was thinking of multiplying the Y by -1 before the attach but I think the attach/parenting happens in code.
Edit:
I think I found what I should be using.
Set the gameplay tag “HasSeperateSocketsPerHand” (on the grippable static mesh? I assume) and then create 2 different sockets named “VRGripLeft” and “VRGripRight” on the mesh.
Next Edit:
I added the HasSeperateSocketsPerHand game tag to the Grippable Static Mesh Base Class (verified it’s still there for the child Actor I’m testing it with), but it seems VRGripLeft, VRGripRight isn’t recognized. (tried VRTouchGripLeft/Right, too even though I’m on a Vive, but that didn’t work either)
I’m using a VRExP from a week or 2 ago (4.17.1).
I don’t actually attach anything and the gripping isn’t based off of the hand mesh, it is based off of the controller itself. Unless you actually flipped the scaling on the controller instead of the mesh you aren’t running into problems with that.
What you are running in to is that the socket orientation is correct, but only into one palm. You are correct that HasSeperateSocketsPerHand is the way to do it in the template but you used the wrong Socket Names.
VRGripLP
VRGripRP
LeftPrimary / RightPrimary
You can go in to the “GetCorrectPrimarySlotPrefix” function and change those if you wish, it really should be in a variable somewhere instead, but not the largest deal.
Pushed a new update to the repository today
Added a bunch of functions/nodes to the OpenVR library to control overlay skyboxs and loading systems. They are detailed in the wiki entry below.
[https://bitbucket.org//vre...unctionLibrary](https://bitbucket.org//vrexpansionplugin/wiki/VRExpansionFunctionLibrary)
Corrected an issue that the Epic Motion Controllers have that was evident in my overrides of them, now removing the late update scene view if the motion
controller is deactivated. Otherwise late updates would continue to be used and visually it would appear as if the controller was still active.