I’m going absolutely nutty here. I cannot grip anything. I’m using the motioncontrollermap from the template and all of the template items with a copied Vive_PawnCharacter - labelled VR_PawnCharacter.
I walk over and try to grip anything, it always denies grip…I’m using the potion on the table as the tester with a bunch of print strings around now and it makes Absolutely zero sense:
For the PotionActor on Event BeginPlay I’ve Set Deny Gripping to false for the potion mesh and stopped, then printstring for IsDenyGrips for the actor, potionmesh and stopper, as well as used the interface and the message for actor, potionmesh and stopper — the printstring reports IsDenyingGrips is false for every one of these:
LogBlueprintUserMessages: [PotionActor_620] Potion is denying grips: falsefalsefalsefalsefalsefalsefalse
I also added printstrings in ShouldGripComponent functions and SelectObjectfromHitArray printing out the Object Hit: and the Should Grip: from after Should Grip Component function runs.
in ShouldGripComponent I added printstring statements after relevant parts… see log:
LogBlueprintUserMessages: [VR_PawnCharacter_2] Trigger Grip
LogBlueprintUserMessages: [VR_PawnCharacter_2] Implements interface
LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
LogBlueprintUserMessages: [VR_PawnCharacter_2] Object Hit: PotionActor_620.PotionMesh Potion Should Grip: false
LogBlueprintUserMessages: [VR_PawnCharacter_2] Implements interface
LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
LogBlueprintUserMessages: [VR_PawnCharacter_2] Object Hit: PotionActor_620.PotionMesh Potion Should Grip: false
LogBlueprintUserMessages: [VR_PawnCharacter_2] Does not implement interface
LogBlueprintUserMessages: [VR_PawnCharacter_2] Component Owning Actor Implements Interface
LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
LogBlueprintUserMessages: [VR_PawnCharacter_2] Object Hit: PotionActor_620.PotionMesh Potion Should Grip: false
LogBlueprintUserMessages: [VR_PawnCharacter_2] Trigger Grip
LogBlueprintUserMessages: [VR_PawnCharacter_2] Implements interface
LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
LogBlueprintUserMessages: [VR_PawnCharacter_2] Object Hit: PotionActor_620.PotionMesh Potion Should Grip: false
LogBlueprintUserMessages: [VR_PawnCharacter_2] Trigger Grip
LogBlueprintUserMessages: [VR_PawnCharacter_2] Implements interface
LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
LogBlueprintUserMessages: [VR_PawnCharacter_2] Object Hit: PotionActor_620.PotionMesh Potion Should Grip: false
LogBlueprintUserMessages: [VR_PawnCharacter_2] Does not implement interface
LogBlueprintUserMessages: [VR_PawnCharacter_2] Component Owning Actor Implements Interface
LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
How the heck is it possible that after checking isdenyinggrips in the potion actor when triggered by the hand it’s returning a true from the interface!? (I’ve checked class defaults for VRGrip Interface and the interface function in the actor too.)
Sounds like you migrated parts of the example template to a different project? The example template is overly featured in order to make a good test bed (its my primary test ground) and to show a bunch of different interactions, its not exactly the best thing to migrate. What you likely ran into is that you didn’t port the gameplaytags that it uses to run the templates gripping off of, both are defined in the config files.
I generally don’t suggest that a game from the ground up use the gameplay tags, you generally don’t need to switch what button does what on a per object bases. However if you want them you can import the datatable that defines them, set it as your gameplay tag table in editor (or also transfer the config file that sets it) and make sure that the GripDropOrUse_Clean functions have the tags that they are likely now missing (or re-import that part after importing the tags).
Indeed, I migrated the examples over to try to better compare to how i could integrate it into some test systems – I actually have all the gameplaytags and they are set in editor, but I don’t see how that’s relevant to the function and interface interactions? It’s failing in the function before checking for relevant gameplay tags. The printstrings indicates it is returning when it fails calling the interface message IsDenyingGrips on the actor (branch is true w/ SG None and returns)
Check to make sure that what you are trying to grip is actually the potion, the interface isn’t going to be failing out unless you are trying to grip an uninterfaced object. It may be that during your migration you didn’t port the trace channel so it reverted to a default one and is trying to grip your hand mesh or something.
Yeah, I see your point with the output of the slicing function… Perhaps it’s conceivable to make a separate node for such a copy (or to set the pointer)? Similar to the existing “Copy Procedural Mesh from Static Mesh Component”. That way you wouldn’t have to touch the slicing and the code remains clean (would still be inefficient… but so are all the other solutions it seems).
I found that:
Copying the Mesh from the ProcMesh after slicing will make you lose the collision (as you highlighted in the example project). The only way around I can see is to mirror the actor, do the slicing twice, and delete one half from either actor. It’s really collision that is creating issues…
Parenting to a Grippable Sphere (with Welding), messes up completely the collision of the ProcMesh (also made a bug report to Epic for …), so that’s not a solution either
Ideally, we would remain with one actor – also because after slicing we need some logic to determine which sliced part was held by a hand and so on…
After copying you just need to generate convex collision, the slicing does that part automatically so you likely just weren’t aware that it was part of making a proc mesh and has its own node.
The example template doesn’t “lose collision” it loses the body instance of a physics grip which wouldn’t matter anyway with a sweep grip type. Also as of 4.22 I added a way to detect a physics body being ripped out from underneath the physics constraint and re-init it with the new body context so that doesn’t happen anymore anyway.
As for a node for the slicing with a different base class? The problem wasn’t the copy, the problem was the slicing function automatically spawning and filling a new procedural mesh component, and then having to spawn yet another procedural mesh component and copy the results over before destroying the one that slicing had made. You can limp along by making a manually interfaced subclass of the procedural mesh component and copy after slices, I just would rather not make that an official part of my plugin or keep a re-write of the slicer around that is a seperate function.
Would be better off reporting it as an issue with the suggestion that the class type of slicing be either copied from its parent class during creation or allowed to be passed in. would get it fixed in engine, after which a grippable form of the procedural mesh component would “just work”.
If you make a grippable actor and set its root component to a procedural mesh, then do your sliced copies duplication off of its children on a subclass with a manual interface integration (see pickup cubes) then you should be fine. You’ll want the original to be the root of a grippable actor anyway for most uses if you intend to work with replication.
So I guess I’m stuck with the “duplication” that I’m doing wrong… so far I’m doing the “Get Section from Proc Mesh” of the sliced copy, and “Create Mesh Section” in the spawned actor, where I have to re-create collision. I did not find a way to copy a ProcMesh over to a new component (in the same actor or in a new one… or even copying a static mesh the same way). How do you duplicate/copy? In c++ I guess that’s possible, but in BP?
(thanks for your patience on , by the way…)
Some additional info: After slicing, the MultiSphereTraceForObjects does not detect the resulting objects. The default Vive_PawnCharacter has to fall back on overlap detection for the grip (which messes with the grip prios a bit)
Copying mesh sections is the correct way of doing it, there is no direct “copy” no, but copying the sections IS copying the mesh.
As for tracing not working, you need to enable collision with the VRTracechannel likely, you still have to manage collision settings on spawned objects, if you are copying to a new subclass then that subclass can have the collision settings already defaulted.
What you are doing for copying is literally what I would have to do “officially” unless I re-made the slice function, its a result of the procedural mesh component not being very flexible is all. Rather the engine improve here than patch on a hacky fix that you can do yourself anyway.
Ok good. I’ll make sure to send you my solution when I’m done, in case you want put it in the example project.
That was the first thing I tried… Perhaps I made a mistake somewhere, but it might also have to do with the collision bug that is present in ProcMeshes.
I’m using a VRCharacter, but for some reason, the VRRootReference is not following the HMD. It remains at 0,0,0. I’m wondering if I switched something off by accident.
When I spawn as a fresh VR character (e.g. empty blueprint), the capsule follows as expected.
When I duplicate my VRCharacter, then delete everything so that it’s got only the inherited components and no code, the capsule still remains at 0,0,0.
I’m hoping is an easy fix before I start migrating my character code to a new blueprint.
It looks like I somehow did. When I check if “Is Component Tick Enabled” on my character, it returns false. when I check it on the fresh character, it returns true.
I’m uncertain how I disabled tick on component.
When I “Set Component Tick Enabled” on VRRootReference to True, “Is Component Tick Enabled” still returns false.
Might be a bug with the engine… I’ve just read that sometimes components don’t tick, need to remove them and readd the component.
Since component is inherited, I’ll probably end up having to migrate all the code over to a new bp
Yes, manage your collision settings to not do it, the character obeys the collision settings of the engine, you can turn off anything to not block them that you want.
You can also setup bWalkingCollisionOverride to have collision channels that only are active during locomotion and are off during “walking” around.
Could you provide some advice on how to use the Gameplay Tags, specifically the “DenyFreeGripping” tag? Just from the title, it appears to be what I am looking for to prevent accidentally “free gripping” another part of the root component that has collision when I’m actually trying to grab a child component. However, in my testing, I’m unable to actually get it to trigger - so far I can’t see a difference between it being enabled or disabled.
4.23 going over video, not much to “show” most of the start of 4.23 is all going to be backend and stability work. There is a lot going on in the back end of the engine itself that I need to keep an eye on at the moment and stress test against.
Was looking to put game up on Oculus Store but game cannot reference steam or steam openvr. Do you have an OpenVRExpansionPlugin based on Oculus instead of Steam? Or should I just be trying to remove all use of OpenVRExpansionPlugin.
