VR Expansion Plugin

[mordentral]

Hello!!

First of all this is amazing!, been having a look at your plugin for the past couple of days trying to understand everything and it looks like it could fit all my needs!

However, I've been trying to do a bow using the example project and the grippable skeletal mesh and I'm running into an issue! hopefully somebody here can point me in the right direction . For reference, what I'm doing is very similar to this https://github.com/Pinworm45/SyntyBowVR just trying to build it using your grip skeletal mesh class.
My bow can be gripped with both hands, the secondary hand will attach to a secondary socket and then on tick I'm using the relative location of my motion controller to blend between two animations (moving the bone and the secondary socket my controller is attached to). Everything works except for the fact that my hand (both my mesh and the overlap collision althouh my motion controller seem to be where my real hand is) get stuck in the initial location of the grip and never update.

Ideally I just want my hand mesh to stick with my motion controller, I've been messing around with the settings but haven't found a way to do it. Also been debugging the code but can't really find the place where you update the secondary attachments, since as far as I can tell get stored in GripInfo->Secondary ... but the HandleGripArray function that gets called every tick only seem to update the main one?

I've also tried to just override my way through in BP directly, like trying to set the location of those components on tick and stuff like that but not much luck. For reference these are my settings:

Finally, worth mentioning that I'm testing this on a single player environment. Networking will come later

Thank you again!

"Secondary Attachments" are a modifier to a grip, they add a reference point that the grip attempts to also keep oriented towards, they are not a full grip in themselves. You can use tick on the bow or the character, or a timer, to update the hand meshes relative position on the string as I assume that is what that tutorial is doing.

Or you can snap to a bone socket on the string and it will auto follow that.

The only grip mode that specifically has its own tick is "Custom_Grip" as that throws one after the controller moves so that you don't have to play around with trying to sync timing.

[mordentral]

Bada$$ plugin mate!! This really helped out immensely for a beginner. I look forward to diving deeper and seeing what scenes i can create this.

I could use some help on these last two things i have for completing my archviz of my childhood family home. I knew 0 going in and i'm amazed at how powerful this engine and plugins are.

I'm using the Door w/ the Doorkey blueprint - how could i set the blueprint to "Locked" as the default state?
Also I have a clamshell container that i was hoping to be able to open, is there a recommendation on a BP i can reuse to accomplish this?

Thanks!!

You can SetLeverAngle on the deadbolt on begin play based on the doors current locked state so it will auto setup the lock setup, it should handle itself then.

For a container you can either use a lever as the top and hinge it at the back, or use a physics constraint and just handle it physically by having the lid be a grippable component and using a manipulation grip type.

[Jcandelario]

mordentral thank you! I’ll definitely get that done.

This has been an amazing experience learning throughout the process. I’m fairly certain that without your plugin this would’ve taken me another 3-4 months to complete.

This project will end up being a gift to my family, siblings, and something we’ll be able to keep and share with our littles.

[Grendert]

Thanks for the response

I managed to get it working by extending the system slightly. Although this solution isn't ideal as it doesn't use the entire functionality your plugin provides it does fit it's purpose so I thought I'd share it here for everybody that needs it! .

I use the plugin functionality to grab the object normally, but then my actor has a ptr to the gripped object, and when I pulse the trigger key on my secondary hand I check if the secondary socket is in range and if so I manually call Trigger logic or whatever I wanna do with it, without relaying on the plugin to do the work for me. This way I manage to bypass the logic and I successfully trigger the use functionality with my secondary hand.

Ideally, a proper implementation would just rely on the use of gameplay tags to determine if the secondary hand is the one using the object or not but I didn't have the time to dig deep enough to be able to make those changes. This solution was hacky but simple enough to introduce, hopefully it helps somebody!

happy coding everyone

[sleepykid]

Hey,
Thanks for the plugin it's been a great help
I was wondering if there's a way to allow rotation of a hand relative to a grip?
For example:
I have a lever switch and I want the hand rotation to not be locked to the switch rotation but be able to rotate along one axis

If this isn't included functionality whereabouts should I add this?

Also I was thinking about having fingers snap on to buttons, where I would rotate the index finger so that
if you're near a small button it would snap on. It's implemented in The Lab and I thought it was pretty useful. If I wanted to implemented that where should I do that?

[Qianfulong]

Hey,
is anyone else having problems with creating a grippable skeletal mesh actor? If i create a BP using a grippable skeletal mesh actor an try to compile the created BP (no changes made to it whatsoever) i get a compilation error right away, saying that the BP is not valid. This happens with the newest template project taken from https://github.com/mordentral/VRExpPluginExample as well as a version some weeks older. Building the solution after DL the Git project worked fine, also creating e.g. grippable static mesh actors works without problems.
Cheers for any input on that!

[mordentral]

Hey,
Thanks for the plugin it's been a great help
I was wondering if there's a way to allow rotation of a hand relative to a grip?
For example:
I have a lever switch and I want the hand rotation to not be locked to the switch rotation but be able to rotate along one axis

If this isn't included functionality whereabouts should I add this?

Also I was thinking about having fingers snap on to buttons, where I would rotate the index finger so that
if you're near a small button it would snap on. It's implemented in The Lab and I thought it was pretty useful. If I wanted to implemented that where should I do that?

You can implement the hand rotation in the animation blue print or as physical constraints or generalized logic, and yes, you are correct, the grasping hand is an example of core features, its intended to be expanded on or referenced, not used as is without changes.

You would want to add a data layer on top of the hand to handle custom posing and limits. Its not really a plugin related concept, I try to keep the plugin to core features and leave the gameplay elements free form for the end users to not limit them any, the template content is examples of how to use the core plugin features (in the grasping hands case, the welded body driver and decomposing grip transforms to attach correctly).

As for the finger auto targeting a button, CCDIK should work fine for that (or another IK setup though CCDIK is fast and has rotation limits) and already has examples for FPS pawns, you would just want to range limit to to a zone from the fingers base pose forward vector and only ik chain the finger itself instead of an arm.

[mordentral]

Hey,
is anyone else having problems with creating a grippable skeletal mesh actor? If i create a BP using a grippable skeletal mesh actor an try to compile the created BP (no changes made to it whatsoever) i get a compilation error right away, saying that the BP is not valid. This happens with the newest template project taken from https://github.com/mordentral/VRExpPluginExample as well as a version some weeks older. Building the solution after DL the Git project worked fine, also creating e.g. grippable skeletal mesh actors works without problems.
Cheers for any input on that!

It does it for a normal SkeletalMeshActor as well, not just a grippable. It will let you compile it if you assign a physics asset to the skeletal mesh.

I don't remember ever running into this before so I assume it is a 4.25 quirk.

[CokeKuma]

hi. mordentral.

The enemy character mesh is making a grip system.
I am trying to use a grippable skeletal mesh component, but if the setting value is similar to other grippable objects, only a simple ragdoll is executed and handling is not.
Do I need to refactor this part?

[mordentral]

hi. mordentral.

The enemy character mesh is making a grip system.
I am trying to use a grippable skeletal mesh component, but if the setting value is similar to other grippable objects, only a simple ragdoll is executed and handling is not.
Do I need to refactor this part?

You need to use the PerBoneGripping setting, you can also enable the advanced option of not setting physics enabled so that you can choose which bone chains get simulated OnGrip.

Per bone gripping takes in the bones transform instead of the actual components and the name of the bone to target. In the template it is just turning on the gameplay tag, in custom solutions you'll need to pass that in manually.

[CokeKuma]

You need to use the PerBoneGripping setting, you can also enable the advanced option of not setting physics enabled so that you can choose which bone chains get simulated OnGrip.

Per bone gripping takes in the bones transform instead of the actual components and the name of the bone to target. In the template it is just turning on the gameplay tag, in custom solutions you'll need to pass that in manually.

Thanks for answering. That's a cool system. I have one more question. When the bone is gripped, the lerp to hand script does not seem to respond if the default script and lerp to hand script are used together. It seems that the start point of the lerp always finds the location of the root bone, not the bone to be gripped. Is this a bug?

[mordentral]

Thanks for answering. That's a cool system. I have one more question. When the bone is gripped, the lerp to hand script does not seem to respond if the default script and lerp to hand script are used together. It seems that the start point of the lerp always finds the location of the root bone, not the bone to be gripped. Is this a bug?

mmm, yeah that script was sampling the gripped object for its initial transform, i'll make it check by bone too if one is referenced in the grip information.

It will be up in the repo release in a couple of minutes, need to test it.

*Edit* its live, let me know how it performs for you.

Also you don't need the default grip script specifically added to an object unless you want something else to run first (usually not the case since default also overrides the grip transform).

[cpenny20]

Hello,
We've run into a snag on our project. We have upgraded from 4.24 to 4.25. In the patch notes for the latest, it says that the slide component was switched to using absolutes to avoid confusion. Unfortunately, it has more or less destroyed the setup for the slides and bolts on our guns. Many of them are completely reversed now with no obvious way to return them to the way they were. Also our method of locking the bolts has been compromised. The scripting with the weapons is more of my dev partner's wheelhouse so I can refer to him if you need any more details on the issue, but from what he tells me, everything's gone awry. Would love to know if there is a way to revert (can we remove the absolute from the code and recompile?) or if there's a workaround for this? Thanks!

[mordentral]

Hello,
We've run into a snag on our project. We have upgraded from 4.24 to 4.25. In the patch notes for the latest, it says that the slide component was switched to using absolutes to avoid confusion. Unfortunately, it has more or less destroyed the setup for the slides and bolts on our guns. Many of them are completely reversed now with no obvious way to return them to the way they were. Also our method of locking the bolts has been compromised. The scripting with the weapons is more of my dev partner's wheelhouse so I can refer to him if you need any more details on the issue, but from what he tells me, everything's gone awry. Would love to know if there is a way to revert (can we remove the absolute from the code and recompile?) or if there's a workaround for this? Thanks!

You could remove the change sure, but it was done specifically because people were putting in negative values which were bugged, several features just didn't work with negative values. Now it would work correctly with them.

If you were trying to "lock" values just setting the correct values so that it can't move would work, it sounds like you were relying on the bugged logic not working correctly.

*Edit* I spoke with your partner and added a legacy mode to the sliders to not break behavior for people relying on it being bugged for whatever reason.

[cpenny20]

Hey Mord, thank you for your reply. We very much appreciate you helping us out with that legacy mode. Forgive me for not being up to date on this all as I know you were having this same conversation with him and also others in the discord - but as I understand it my dev partner was unknowingly exploiting a bug to lock the slides or bolts back. Is there currently a better way we should be doing this, or if not, are you introducing this capability soon? From what he tells me I think we will attempt to correct all the math and do it all the right way once we have a solid way of doing this.