VR Expansion Plugin

[Stanzzz1323]

The GrabSphereLeft / Right are the red spheres, and just setting hidden to them to true hides them....

Make sure if you are testing in first person that its also ticked in the FPS subclass, because it does work....

I do have the red spheres in both Vive_Pawn Character and FPS_VivePawn Character turn hidden in game. For some reason they are still showing up.

[mordentral]

I do have the red spheres in both Vive_Pawn Character and FPS_VivePawn Character turn hidden in game. For some reason they are still showing up.

I don't have any other suggestions for you, that is literally the fix. I don't know if you modified something somewhere or if you are using another subclass of them with it unhidden.

[mordentral]

I've only been working with Vive_Pawn Character. I'm working in first person, and didn't realize this. So to confirm, the FPS_VivePawn Character is a subclass of Vive_Pawn Character that can still have an impact on VivePawn Character?

No, the other way around, FPS pawn only effects itself, but changes to the Vive pawn will effect the fps pawn since it is a child of it.

It only changes a couple of things (hand attached to camera, allowing mouse look, ect) so that testing the full vr pawn can be done in 2D.

[Stanzzz1323]

I don't have any other suggestions for you, that is literally the fix. I don't know if you modified something somewhere or if you are using another subclass of them with it unhidden.

Do you think if I were to delete it and then reestablish them, might work?

[EngineerDveloper]

Hello! I'm running into a problem with my secondary hand dominating the weapon rotation when it is grabbed.

When two-handing a weapon and then fully dropping it, the dominant rotation hand flips from the primary hand to the secondary hand (see video below).

https://www.youtube.com/watch?v=5SpT9Mvpg4o

Is there to ensure that two-handed weapon grabs only allow the primary hand to dominate the weapon rotation?

[mordentral]

Hello! I'm running into a problem with my secondary hand dominating the weapon rotation when it is grabbed.

When two-handing a weapon and then fully dropping it, the dominant rotation hand flips from the primary hand to the secondary hand (see video below).

https://www.youtube.com/watch?v=5SpT9Mvpg4o

Is there to ensure that two-handed weapon grabs only allow the primary hand to dominate the weapon rotation?

Looks like you are using the secondary attachment on the back hand there, I'm not entirely sure what your grip setup is but you would just always want the secondary attachment property to be on the rear hand grip and targeting the front hand as the attachment point.

If you are using the template gun, it switches primary hands when you drop the rear if the secondary is attached, it then switches back to the rear as the primary if it is gripped at the socket, it may be that you changed the socket setup of your gun and its not performing that flip.

Since that part is all in the bps you can freely change the logic to correct it for your use case.

[mordentral]

Do you think if I were to delete it and then reestablish them, might work?

reaaallly shouldn't need to.

[EngineerDveloper]

Looks like you are using the secondary attachment on the back hand there, I'm not entirely sure what your grip setup is but you would just always want the secondary attachment property to be on the rear hand grip and targeting the front hand as the attachment point.

If you are using the template gun, it switches primary hands when you drop the rear if the secondary is attached, it then switches back to the rear as the primary if it is gripped at the socket, it may be that you changed the socket setup of your gun and its not performing that flip.

Since that part is all in the bps you can freely change the logic to correct it for your use case.

Thanks for your quick response!

Oops, I actually missed using the secondary grab logic completely! I've been using the "GripObjectbyInterface" function for both primary and secondary hand grabs.

However, I still prefer this method as I personally like how the weapons sockets essentially glue themselves to the GripMotionControllers.

When using "GripObjectByInterface", do you know if there's a way I can tell the logic that "this is my primary hand" so it knows which rotation to follow?

[mordentral]

Thanks for your quick response!

Oops, I actually missed using the secondary grab logic completely! I've been using the "GripObjectbyInterface" function for both primary and secondary hand grabs.

However, I still prefer this method as I personally like how the weapons sockets essentially glue themselves to the GripMotionControllers.

When using "GripObjectByInterface", do you know if there's a way I can tell the logic that "this is my primary hand" so it knows which rotation to follow?

Thats the thing, using multi grip with full grips doesn't, you would need to unlock an axis of constraint in order for it to rotate like that with a physical grip. Also it doesn't "glue" to the motion controllers at all, it would be finding a median between the two controllers, in fact it shouldn't by default be behaving correctly for you at all without tweaking so it may be not even having a rear grip for you currently (multi grip would have to be on).

For it to function somewhat like that, you would just need to figure out which hand you want to be rotation free and call https://vreue4.com/GeneratedDocs/VRE...eSettings.html and set the axis that you don't want to be constrained on that hand to off.

With a gun tools script active the weapon orientation component will dictate what direction the constraint is facing, you can use that to make it easier to know which axis's to turn off. The melee tools grip script does that by figuring out which hand is in the rear and which is in the front and handling constraint limits based on that.


If you wanted a literally accurate version you could also just use a physics prop script on the weapon and you would have to face both hands in the same direction and align them to aim the gun, no free rotation around a hand at all.

[EngineerDveloper]

Thats the thing, using multi grip with full grips doesn't, you would need to unlock an axis of constraint in order for it to rotate like that with a physical grip. Also it doesn't "glue" to the motion controllers at all, it would be finding a median between the two controllers, in fact it shouldn't by default be behaving correctly for you at all without tweaking so it may be not even having a rear grip for you currently (multi grip would have to be on).

For it to function somewhat like that, you would just need to figure out which hand you want to be rotation free and call https://vreue4.com/GeneratedDocs/VRE...eSettings.html and set the axis that you don't want to be constrained on that hand to off.

With a gun tools script active the weapon orientation component will dictate what direction the constraint is facing, you can use that to make it easier to know which axis's to turn off. The melee tools grip script does that by figuring out which hand is in the rear and which is in the front and handling constraint limits based on that.


If you wanted a literally accurate version you could also just use a physics prop script on the weapon and you would have to face both hands in the same direction and align them to aim the gun, no free rotation around a hand at all.

Your right; I wasn't thinking about how these same physical grips would clash with each other and they did clash, haha.

Thanks for the advice on the physics handle setting node and the weapon orientation component. With this, I was able to lock/unlock each hand rotation depending on what was forward and back on the weapon.

I'll keep looking through the grip scripts, but as always, I appreciate your support.

[Soulhuntr86]

Hello,

short question: Why has the GrippableCharacter no OnGrip or OnGripped Events?
Cant find any documentation about that class. Im trying to make enemies grippable, so my goal is to stop animation and movement when the enemy is grapped or at least play some specialized animations. Also maybe activate physics like the grippablemanequin example.

Thanks for you help.

[kaesp]

Getting some weird behavior in the example template, while testing multiplayer.

While using grasping hands (Physics or normal) everything works as intended for the host / listen server. However, remote clients (Play as client) will get a weird offset when they grip an object. The gripped object seems to move / snap a couple of units up. Weirder still, respawning the default controllers in the same session, will cause them to also experience this issues, despite working previously.

Is this a bug or are grasping hands not multiplayer ready out of the box?

[mordentral]

Hello,

short question: Why has the GrippableCharacter no OnGrip or OnGripped Events?
Cant find any documentation about that class. Im trying to make enemies grippable, so my goal is to stop animation and movement when the enemy is grapped or at least play some specialized animations. Also maybe activate physics like the grippablemanequin example.

Thanks for you help.

The mesh is the grippable part, and it does, but due to how the engine handles overridden base components it doesn't display the mesh as the correct type in editor. I have a note to go in and add a GrippableSkeletalMesh reference to it so that its easier, but in the mean time you can cast the skeletal mesh to a GrippableSkeletalMeshComponent and manually bind to the events.

Getting some weird behavior in the example template, while testing multiplayer.

While using grasping hands (Physics or normal) everything works as intended for the host / listen server. However, remote clients (Play as client) will get a weird offset when they grip an object. The gripped object seems to move / snap a couple of units up. Weirder still, respawning the default controllers in the same session, will cause them to also experience this issues, despite working previously.

Is this a bug or are grasping hands not multiplayer ready out of the box?

Grasping hands were not built around multiplayer right away no, for one, their functionality is going to be very expensive for multiplayer (the overlap lerp with multiple players). Generally for multiplayer you would be better off with pre-built poses for grasping things.

An offset like that would be strange in VR, were you testing in FPS where I don't have the controllers using the controller profile directly?

[kaesp]

I see, it's a shame they are not entirely multiplayer ready, but what you say make a lot of sense. Was hoping for a quick way to get hand collision with the environment, but at least it's a good suggestion with pre-built poses.

I did some more testing to confirm the issue and it gets weird, but makes sense if they're not entirely multiplayer compatible. I did the tests with remote client (Play as client).
I did a test with the FPS pawn with grasping hands and things seem to work as expected, funnily enough, although with the expected lag.
For the original test, I was using the VR preview with a HTC Vive headset. I changed hands using the screen in the template map. I don't know if I was using the controller profile directly, but by default it displayed the default device controllers.
I initially reported a strange offset during grip, but it seems to be the physics scene which is weird for the remote client. The physics grasping hands will push objects a meter away and generally seem to be desynced from the server in some way when playing in VR.

In any case, thank you for the suggestion and time.

[mordentral]

I see, it's a shame they are not entirely multiplayer ready, but what you say make a lot of sense. Was hoping for a quick way to get hand collision with the environment, but at least it's a good suggestion with pre-built poses.

I did some more testing to confirm the issue and it gets weird, but makes sense if they're not entirely multiplayer compatible. I did the tests with remote client (Play as client).
I did a test with the FPS pawn with grasping hands and things seem to work as expected, funnily enough, although with the expected lag.
For the original test, I was using the VR preview with a HTC Vive headset. I changed hands using the screen in the template map. I don't know if I was using the controller profile directly, but by default it displayed the default device controllers.
I initially reported a strange offset during grip, but it seems to be the physics scene which is weird for the remote client. The physics grasping hands will push objects a meter away and generally seem to be desynced from the server in some way when playing in VR.

In any case, thank you for the suggestion and time.

Its entirely solvable for multiple in the general sense, but would require some teaking of how the initial spawning and setup is handled is all.