Hey,
thank you for making great plugin, I am using it for my master thesis where i have to implement a multiplayer vr scenario.
Now I have the situation that 2 grippable actors need to be sticked together (into each other), but as you explain in your Youtube video, these are physics objects by intent.
Is there a possibility to disable it? Unchecking “simulate physics” on both actors does not help.
I would like to have the “default” behaviour of overlapping actors with your grippable static mesh actor class.
EDIT:
ok, i found it out. By setting the primary grip type to “attachment” i get the desired effect.
However, there is another problem now.
I have a Grippable Static Mesh Actor, which spawns other Blueprint Actors of type Grippable Static Mesh Actor and attaches them, works fine.
I can now grip every part independently as desired. With a physics grip works fine, except for the collision described above.
With an attachment grip however, the Components start to “fly around” after dropping. The do not fall to the ground as I thought.
Any Ideas?
Hi, firstly thanks for awesome plugun - it’s been invaluable.
I am deploying to an Oculus Go and am having issues with the camera height being incorrect. On Vive, the eye level respects the play area and base station configuration, so no problem. On Go, the camera falls to the floor. I’ve tried changing tracking origin to Eye Level in the character blueprint but makes no difference. In the end I’ve had to hack the actor +150cm higher in the viewport for a Go build, but would like to know what I’m missing in order to get the Oculus platform setting height correctly.
Hey, thanks for your answer. Phsyics only works just as fine. But the “floating” persists. It is not that they dont fall at all, but the parts rather fall to the ground, and then start to swing around at the ground. Do you have any idea, or is something wrong on my side?
Should be something wrong on your side, its kind of hard to know without visualizing what you mean by “swing around”. Could be them attached to their parent with an offset, a physics collision jitter, a late update retention, or something else.
Go doesn’t have roomscale so you’ll always want to use Eye level, you need to offset the VRRoot so that it brings the camera up on the actor to where you want your head to be.
Essentially it is working correctly with go, there isn’t a height for that platform at all, you have to choose what you want.
That being said, there is less reason to use a VRCharacter for a head locked pawn like that, its not being influenced by roomscale movement so you don’t need the offset support really.
I’m posting here because of a bug that has been bothering me for many many hours… It seems to have been introduced with my update from 4.18 to 4.19 (and the subsequent update of the VR Expansion Plugin).
I’m using the VRPluginExample level without adjustments.
When attempting to grip the door, the first grip fails. first grip seems to ‘set’ something, because at the second (and subsequent) attempt(s), the grip succeeds. After moving to another item, things seems to be reset and we are back at where we started.
Somehow the issue occurs only with the doors, drawer and closet - other elements (like the pickup cube) work as expected.
Does anyone else have the same issue? Any solutions?
I’ve been trying to make my vr pawn be able to swim in water but can’t make it work.
It seems like the pawn doesn’t recognise that it’s in water (physics volume with water volume checked) the same way that a thridpersonCharacter would. Both seem to have isSwimming in characterMovement/vrMovementReference but it’s always false in the vrPawn. Is swimming not supported or am I just missing something to make it work?
I’ll look into it, swimming was the one movement mode I didn’t overhaul because no-one used it and the one that wanted swimming went with flight and custom movement because it was more controllable. It “should” still trigger so I need to find out why its not now.
Edit Its because the capsule has dynamic object overlap off by default, just turn it on, otherwise it never overlaps the volume.
I’ll still do some quality passes over the movement mode anyway to finalize the last movement mode.
re-edit Cleaned up swimming for VR, let me know if it has any issues in functionality. I also ported it back to 4.19 from 4.20 since 4.20 isn’t released yet.
It seems to me that it can’t be related to the migration: The issue occurs with fresh projects in v4.19.2.
I tried with a fresh download of the VrExpPluginExample (https://bitbucket.org//vrexppluginexample). Choose v4.19->Generate Visual Studio project files-> Open project -> Door/Drawer only works at second grip attempt
I tried with the ‘pre-compiled’ version from the ‘Plugin Pre-built Downloads’ section of the forums -> Door/Drawer only works at second grip attempt
… I’m really scratching my head here… Are you sure that in your version you don’t have issue?
By the way: The BP proceeds correctly to “Grip Object by Interface” (and has the correct “Object to Try to Grab” - door - ). The BP also proceeds into the Event On Child Grip (in the Door BP)… but for some reason the Grip doesn’t actually happen…
If it is going all the way to initializing the grip then it DID grip, the only thing that prevents it from there moving the object is if the grip is paused, or the object goes null. I also cannot re-produce and neither can anyone else I have asked.
What hardware are you on? Desktop Rift/Vive? Standalone?
Its a default character movement mode, you can either SetMovementMode (the node) or go into the CharacterMovementComponent’s settings and change the default land movement mode to flying.
Oh, I see, that’s what needed to be changed. Now I know my problem. I was just using the Pawn that comes with the base UE4 VR template, which doesn’t seem to support that mode. Works fine with a character. Thanks a lot!
I’m testing with the Vive (always testing live with the headset and controllers), on Windows.
The problem is exactly the same with the VrExpPluginExample and my own project - however with my own project I’ve seen that the BP continues past changes that should be visible (door handle moving down) without the changes becoming visible.
Again, at from second Grip onwards everything is fine - unless you teleport, then it’s re-set and the first Grip fails again.
I’ve also made all the settings in “VRGrip Interface” (of the Door BP) equal to other objects that do work correctly. No change.
Thankyou. is a little over a month of weekends. There’s alot of features that weren’t active in the demo. The code base conforms to just about any kind of gun real or scifi, but is heavily work in progress. I still have much to add to project.
