VR Expansion Plugin

[thelazylion]

Use a timer for that anyway yes, start it on grip and end it on release.


Sounds like you have movement replication enabled on them? Turn that off.

Thanks for the prompt reply. I checked though, and it seems replicate and replicates movement are both already off on the grasping hands..

[mordentral]

Thanks for the prompt reply. I checked though, and it seems replicate and replicates movement are both already off on the grasping hands..

There isn't any specific reason for it to lag behind more on clients than the server if the movement is all controlled locally, the logic is the same at that point and physical hands use constraints to follow.

[thelazylion]

So I started getting this crash on packaged launch for some reason. Seems related to the grippable mesh, is this anything you're famliar with? Not too sure what I adjusted the passed few builds, but I had to do a roll back to a few days ago. Something somewhere seems to have triggered it. Just as a heads up.
Tried porting all the content back to the rolled back version for testing and the crash happens again.. So its probably the physxcharacter class, which is essentially just a grippable character class. Seems to be an issue with the grip script. Also the the build happens successfully, almost instantly. Like it's skipping modules or something.

UATHelper: Packaging (Windows (64-bit)): Copying NonUFSFiles to staging directory: D:\Unreal Projects\ALS_USK\ALS_VR_Base\Saved\StagedBuilds\WindowsNoEditor
UATHelper: Packaging (Windows (64-bit)): ********** STAGE COMMAND COMPLETED **********
UATHelper: Packaging (Windows (64-bit)): ********** PACKAGE COMMAND STARTED **********
UATHelper: Packaging (Windows (64-bit)): ********** PACKAGE COMMAND COMPLETED **********
UATHelper: Packaging (Windows (64-bit)): ********** ARCHIVE COMMAND STARTED **********
UATHelper: Packaging (Windows (64-bit)): Archiving to D:/Unreal Projects/ALS_USK/exports/Base2
UATHelper: Packaging (Windows (64-bit)): ********** ARCHIVE COMMAND COMPLETED **********
UATHelper: Packaging (Windows (64-bit)): BUILD SUCCESSFUL

I'll let you know if I find anything


As for the slow grasping hands, i'm not sure either , what the cause it, but it's been like that out of the box with the plugin example setup.
At least I think thats how I remember it. Had to keep sim off on client side to let them catch up whenever they lag behind.

[mordentral]

So I started getting this crash on packaged launch for some reason. Seems related to the grippable mesh, is this anything you're famliar with? Not too sure what I adjusted the passed few builds, but I had to do a roll back to a few days ago. Something somewhere seems to have triggered it. Just as a heads up.
Tried porting all the content back to the rolled back version for testing and the crash happens again.. So its probably the physxcharacter class, which is essentially just a grippable character class. Seems to be an issue with the grip script. Also the the build happens successfully, almost instantly. Like it's skipping modules or something.

UATHelper: Packaging (Windows (64-bit)): Copying NonUFSFiles to staging directory: D:\Unreal Projects\ALS_USK\ALS_VR_Base\Saved\StagedBuilds\WindowsNoEditor
UATHelper: Packaging (Windows (64-bit)): ********** STAGE COMMAND COMPLETED **********
UATHelper: Packaging (Windows (64-bit)): ********** PACKAGE COMMAND STARTED **********
UATHelper: Packaging (Windows (64-bit)): ********** PACKAGE COMMAND COMPLETED **********
UATHelper: Packaging (Windows (64-bit)): ********** ARCHIVE COMMAND STARTED **********
UATHelper: Packaging (Windows (64-bit)): Archiving to D:/Unreal Projects/ALS_USK/exports/Base2
UATHelper: Packaging (Windows (64-bit)): ********** ARCHIVE COMMAND COMPLETED **********
UATHelper: Packaging (Windows (64-bit)): BUILD SUCCESSFUL

I'll let you know if I find anything


As for the slow grasping hands, i'm not sure either , what the cause it, but it's been like that out of the box with the plugin example setup.
At least I think thats how I remember it. Had to keep sim off on client side to let them catch up whenever they lag behind.

Looks like the blueprint got corrupted and the grip script isn't being handled correctly. You likely don't even need that script regardless though, just turn on multi grip and set some sane defaults. The physics script is specifically when you want to handle per hand weighting.

And yeah, the physical hands weren't specifically tested in multiplayer (assumption is that people wouldn't attempt to use them in multiplayer due to how unsync'd that type of thing will be), they likely need some tweaks, I was pointing towards where to tweak.

[juliusD]

So I'm doing Multiplayer, at first when i add a grippable static mesh actor to the scene it replicates great, but if i create a session and move some things around then a client connects, the objects i moved are not at the correct location for the client, I've fixed this by unchecking the net load on client tick box in the grippable actor. now the client sees the correct location of an object when he connects.

But this only works for an actor with one component in it, for example the flask in the vr expansion demo project, you can open\close it and all replicates (it is made out of 2 static meshes), but when i start a session and client joins, the client sees the flask body (the main component in the actor) in the right place, but the cap is not in the right place.
i cant set individual components to not net load on client, only the entire actor.

is there a way for a component (that is not the main one) to be in the right place for a joining client?

[GRADgr]

Hey Mordentral, can you please assist On how Could i implement the Gripable Static Mesh to account griping mechanic only on a part of a mesh. example like when trying to grip a door only from the edges?

[mordentral]

Hey Mordentral, can you please assist On how Could i implement the Gripable Static Mesh to account griping mechanic only on a part of a mesh. example like when trying to grip a door only from the edges?

Depends on what you are trying to do exactly.

If you want the hand to snap into place on it then you can setup a spline that you snap to like how the melee base class handles handle snapping.

If you only want it grippable along that section, no real snapping, then you could use a proxy mesh / collision shape along that edge that gets gripped and then is either constrained to the door, or promotes the grip to also grip the door itself (see how the door handle promotes a grip to the door when fully engaged).

You can also do both, a proxy mesh along the edge that enforces a hand position by snapping as well.

Or you could make a custom class that is a grip promoter that gets polled for what to grip instead so you don't use the grip system on the proxy.

[mordentral]

So I'm doing Multiplayer, at first when i add a grippable static mesh actor to the scene it replicates great, but if i create a session and move some things around then a client connects, the objects i moved are not at the correct location for the client, I've fixed this by unchecking the net load on client tick box in the grippable actor. now the client sees the correct location of an object when he connects.

But this only works for an actor with one component in it, for example the flask in the vr expansion demo project, you can open\close it and all replicates (it is made out of 2 static meshes), but when i start a session and client joins, the client sees the flask body (the main component in the actor) in the right place, but the cap is not in the right place.
i cant set individual components to not net load on client, only the entire actor.

is there a way for a component (that is not the main one) to be in the right place for a joining client?

I've noted it before, but the engine generally does replication correctly only with the root component of actors, and that stopper should really be a seperate actor entirely.

However ticking on "replicates" on the stopper component should fix that regardless.

[Qianfulong]

Hi,
i've got a question regarding secondary grips. I am trying to implement an object, which while being hold by the main hand, spawns a certain object when the secondary hand grabs it at a certain position. Think a magazine and it's bullets. I am trying to use a custom secondary grip for that. However i do have two questions here:

1. How do i tell a secondary grip of type "SG Custom" to use a slot, so that the secondary grip event is only fired when the secondary hand grabs near that slot? I tried to use a "VRGripS1" socket on the mesh but that does not have any impact.

2. When doing the secondary grip the "OnSecondaryGripAdded" event fires just fine. However only for the very first grip action and it also seems that the "OnSecondaryGripRemoved" event does not fire ever, even when the secondary hand lets the grabbed object go. How do i get the "Added" and "Removed" events fire as they should do, namely everytime the secondary hand grabs or lets go?

3. How do i remove the secondary grip manually in the BP? Imagine this: The secondary hand grabs the object and the object to be spawned gets spawned. Since i want to grip that spawned object inb code i assume, that the secondary grip has to be removed first, in order to then be able to grip the spawned object in code.

Cheers for any help on this!

[mordentral]

Hi,
i've got a question regarding secondary grips. I am trying to implement an object, which while being hold by the main hand, spawns a certain object when the secondary hand grabs it at a certain position. Think a magazine and it's bullets. I am trying to use a custom secondary grip for that. However i do have two questions here:

1. How do i tell a secondary grip of type "SG Custom" to use a slot, so that the secondary grip event is only fired when the secondary hand grabs near that slot? I tried to use a "VRGripS1" socket on the mesh but that does not have any impact.

That is behavior that you would change in your control code likely, have it not call the grip if its not over a spot, the plugin itself doesn't handle that logic to leave it open ended for whatever you may need. The template implements basic secondary grip logic but doesn't handle anything special around the custom secondary type. You could also let it secondary grip and only run the logic if the relative transform is close to the socket or on it.

2. When doing the secondary grip the "OnSecondaryGripAdded" event fires just fine. However only for the very first grip action and it also seems that the "OnSecondaryGripRemoved" event does not fire ever, even when the secondary hand lets the grabbed object go. How do i get the "Added" and "Removed" events fire as they should do, namely everytime the secondary hand grabs or lets go?

They already should be, it sounds like you aren't actually letting go there when trying to re-use the action, generally that would be a OnSecondaryUsed event once already secondary gripping.

3. How do i remove the secondary grip manually in the BP? Imagine this: The secondary hand grabs the object and the object to be spawned gets spawned. Since i want to grip that spawned object inb code i assume, that the secondary grip has to be removed first, in order to then be able to grip the spawned object in code.

No, you don't have to remove a secondary grip to grip something, a secondary grip is a grip modifier, it is on the primary hands grip structure. Also for future note, even if it was a full grip, you can have up to 128/128 (local and server authed) grips at the same time on each hand.

Cheers for any help on this!

Responses edited in above, however I will note that I think you are approaching this wrong likely, it sounds like a better case for using a grippable collision body or hidden mesh component on the object at the point that you want, and running all of your logic off of OnGrip instead, it could be a full subclass dedicated to being a spawner and would make your logic both easier and more modular.

Also, since you aren't "actually" gripping anything here, you can entirely bypass the grip system and just throw interaction events however you would want as another method.

[thegiffman]

Hi Mordentral!

I'm the lead VR programmer for Horizon Productions in Durham NC. We get to work on some crazy fun VR projects, including multiplayer ones like this virtual art gallery with full body avatars:

I had looked at your plugin years back, but had decided against using it since we didn't want to introduce a dependency on such a core part of our tech. A couple years and multiplayer experiences later, I'm wondering what I was smoking. Two of the guys I work with tried out your latest build, and then put together this video showing it off to me and my boss (you might want to turn the volume up for this one - they got a bit dramatic):

I'm particularly impressed with the interactions between physical objects. Getting in a tug of war with the three of us pulling on a cinderblock, where I finally lost my grip after the two of them pulled against me, was something I've never experienced before. It sure seems like a wonderful architecture.

I've been through the tutorials, and done a little digging into the code (but there's an awful lot of it). It's neat that you are handling the replication in the motion controller component. I had done it in the pawn, and your solution is so much more nicely decoupled.

I have a ton of questions. I can see by the thread here that you are super helpful, and that's just awesome. Right now I'm reading through your updates in this thread to get a sense of the overall design, and I'll do my best to not bother you with stuff you've already been through with other folks. For now, congrats on the mega grant, and on the six years of building something that solves a ton of problems I've sweated through in the past couple years.

- Giff

[mordentral]

Hi Mordentral!


I have a ton of questions. I can see by the thread here that you are super helpful, and that's just awesome. Right now I'm reading through your updates in this thread to get a sense of the overall design, and I'll do my best to not bother you with stuff you've already been through with other folks. For now, congrats on the mega grant, and on the six years of building something that solves a ton of problems I've sweated through in the past couple years.

- Giff

Welcome to the plugin, and I have to say, their little play around video there is a better showcase of the plugin / template than any of my gifs or text write ups.

[Qianfulong]

Responses edited in above, however I will note that I think you are approaching this wrong likely, it sounds like a better case for using a grippable collision body or hidden mesh component on the object at the point that you want, and running all of your logic off of OnGrip instead, it could be a full subclass dedicated to being a spawner and would make your logic both easier and more modular.

Also, since you aren't "actually" gripping anything here, you can entirely bypass the grip system and just throw interaction events however you would want as another method.

All right, thanks a lot for the answers on that again! I was thinking of using secondary grips because i wanted to implement a small physical reaction to the interaction. So if we talk about a magazine and it's bullets i imagined some little drag on the magazine whenever a bullet is being removed. To give the imagination of some force that needs to be applied to actually get the bullet out. I thought i woul dbe able to use secondary grip functionality for that.

I will have to think about this again.

However i also noted, that when doing a secondary custom grip in game, the "OnSecondaryGripAdded" event always fires three times, which makes my logic run three times as well. The regarding actor however only has one component with a VRGrip interface on it (a static mesh component). Any idea, why this would fire three times?

[mordentral]

All right, thanks a lot for the answers on that again! I was thinking of using secondary grips because i wanted to implement a small physical reaction to the interaction. So if we talk about a magazine and it's bullets i imagined some little drag on the magazine whenever a bullet is being removed. To give the imagination of some force that needs to be applied to actually get the bullet out. I thought i woul dbe able to use secondary grip functionality for that.

I will have to think about this again.

However i also noted, that when doing a secondary custom grip in game, the "OnSecondaryGripAdded" event always fires three times, which makes my logic run three times as well. The regarding actor however only has one component with a VRGrip interface on it (a static mesh component). Any idea, why this would fire three times?

It shouldn't unless you are calling it three times as well.

[sleepykid]

Hi,
For some reason when I grab a skeletal mesh by a particular bone/collider (using per bone gripping) my hand and skeletal mesh increases in scale. I imagine it'll be to do with attachment and scale snapping. In grasping hand I tried making all the scales not snap and instead keep world but that didn't help.
Thanks in advance and for everything else