VR Expansion Plugin

Thank you , I will do that.

I don’t know if it’s just me, but it seems like when I adjust the size of the “body” in the Vive_PawnCharacter to reduce the area of pushback, it does not seem to change in game. Is there a setting someplace that re-initializes it on BeginPlay?

The “Body” is just the waist indicator…You want to resize the player capsule. Also the capsule has an offset variable that lets you push it back farther (like a neck offset). its default is only 8, 15 - 20 feels more natural but will clip slightly into walls unless you set the cameras clip plane closer.

You can set the root capsule to Hidden=false in its variables if you want to get a feel for where it is when tweaking.

Thank you. That makes sense.

I recently tried the steam voice setup by enabling free talk with…:

[/Script/Engine.GameSession]
bRequiresPushToTalk=false

in DefaultGame.ini

…which works great, but I just wanted to check if a couple things are normal or not. I’m noticing about a second delay from client to client. It seems if I speak into the mic too quickly… for less than about a second, the audio gets lost sometimes. If I speak longer than a second, it always comes across but with about a second delay. Just wanted to check if these are expected with steam voice, before i try to debug my setup. I’m using a steam connection without LAN, which is about a 12 ms ping.

One other thing I’ve been wondering for a while is if it’s possible to send a command to the vive headset to wake it up? Sometimes even though I have sleep disabled in steamVR settings, the headset isn’t registering if it’s been sitting in a steady position for a while. Happens even when it’s within the playspace and visible to the trackers. Not a major issue as it wakes up after i move it, but it causes a few annoyances, and just wondering if you knew of a command somewhere that would just always wake it up.

Thanks a lot for the reply. The issue, where my character seemed like it was half as tall as it should be, was happening on retail Steam games too, afaict. After removing all Vive devices in the SteamVR app and uninstalling/reinstalling Steam/SteamVR without the Vive connected the crashes still occur on my 4.18.1 project but the character height seems like its fixed on Steam games.

I’m not sure what I need to do get back proper calibration. You’re the VR master. If you have time I’d greatly appreciate it if you could give me some pointers on like what might cause that InverseFast-related NaNs error (or what causes lost calibration) and what you might do to fix it. After working with VR for half a year, is the first time I’ve run into something like .

I’ll post my prob on answer hub now just in case though. Regardless, thanks a lot!

I am curious why Overlap does not work?

I have a GrippableMeshActor Blueprint (overlaps enabled) with a CollisionBoxComponent inside of it that I would like to trigger a sound when it Overlaps with the HeadMesh (which lives inside the VivePawnCharacter) which didn’t work so I added another Actor called Bong Sphere (which still doesn’t work). Both the HeadMesh and Bong Sphere have been set to Generate Overlaps.

I was thinking with BluePrint that if I took the GrippableMeshActor (Bong_Test_Blueprint) and Cast it to the VivePawnCharacter -> Checked to see if GrippableMeshActor (Bong_Test_Blueprint) was overlapping it, that I should be able to use a branch to send a true node to trigger a sound.

The trigger completes and the sound plays if I set the Branch to False, but obviously, that is not my goal… I would like it to positively trigger the sound to play. I also think that it triggers, but not because of the Headmesh / Bong Sphere, but only because the capsule??? Maybe…

I tried two different things… but now I have become lost, which I think my second attempt alludes to. With the Unreal VR Character I was able to take one blueprint and cast it to a hidden cube on the camera and produce a True branch result.

To explain a little bit more… The Grippable Mesh Actor Blueprint has a Collision Box Component inside of it which I hoped would detect the collision. Essentially so the player has to put that part of the Actor towards their head.

Any ideas?

I’m about to use template and integrate VR Gloves, so that I can get all the different fucntions you developed, and I can’t wait!

Looking at the videos you did a great job!

Also congrats from father to father :slight_smile:

Yeah steam voice takes a second to recognize that you are talking, you should be able to tweak that yourself in your steam settings (in steam itself) though. Also while 4.18 brought VOIP improvements, if you are on an older engine version you will need to up the client bandwidth cap in order to utilize VOIP in network correctly.

It may also be required in 4.18, I haven’t had a chance to test the changes they made yet.

Edit Oops forgot the second part.

Your headset should wake up when an application boots up, the problem is that the editor takes API control when it launches so the headset goes to sleep when sitting with it active and playing in a VRPreview doesn’t wake it back up. Its actually a good thing in my mind since it saves battery during dev sessions with controllers, however you can turn off sleeping in the SteamVR settings last I remember.

Well for one…when you are looking for overlap you are checking against nothing in those images. You need to provide the other component that you are checking for overlap against. I’ll also note that questions outside of the plugin specifically you might want to start making threads for, I don’t really want thread spammed with general un-related questions, it makes it too hard for people to see important updates. I tend to help people with generic problems over discord and not the forums, singular threads are a terrible platform for it.

Thanks! And good to hear, hopefully since those gloves utilize the tracker for positional and I assume any bend / joint orientation as a seperate API you can do it very easily. The gripping system is agnostic to VR if you end up using it, in fact if you turn off the tracked device following on the GripMotionControllers they basically become a utilitarian grasping component.

Yep, the gloves are using the Vive Trackers for position/orientation and IMU sensors for the fingers and wrist orientation.
Instead of using API, inside the BP I simply used the fingers joint orientation values on Tick, then use those values to do events ( hands open = activate teleport, hand neutral = do teleport, and so on ).

As soon as I do the integration I’ll link a video in thread :wink:

Hi

I’ve just come across plugin yesterday, WOW is amazing!

I’m currently looking at the way you’ve built your interaction into the SimpleVive_PawnCharacter in the VRExpPluginExample. If I try to Migrate SimpleVive_PawnCharacter over to another project there’s mainly a few standard errors for missing Input Actions and such but there’s one that I’m having a difficulty in solving. I see you’ve mentioned a few things about Voice further up but not specifically .

I’m having trouble with the Start/Stop Network Voice functions used in the MicrophoneCheck function of SimpleVive_PawnCharacter in 4.18 as seen in image

I understand that I can just disconnect these function calls to allow the BP to compile cleanly but I’d like to give them a go, and I can’t find any reference to these functions in the latest master branch of the repo. I had a look in 4.17 and 4.16 branches and couldn’t find it there either.

Was the example project just compiled from a personal build or am I missing something here?

Thanks for all your hard work on !

Was testing with 4.18 actually, and latest version of the template plus my stuff.

I see in the release notes for 4.18:

“Voip streaming improvements - use the underflow feature of sound streaming to feed the audio buffer rather than enqueue the data directly - wait a small period of time to buffer period actually playing new voip streams”

I’m guessing the improvements are meant to be automatically included in 4.18 but don’t know how to check.

I tried doubling the default network data limit to 20000 bytes via DefaultEngine.ini
[/Script/OnlineSubsystemUtils.IpNetDriver]
MaxClientRate=30000
MaxInternetClientRate=20000

I found the instrutions for how to update client bandwidth via thread:

Also, checked around in steam settings via the steam gui, and in the steam install directory, tried googling around etc, but can’t find any settings to help reduce the delay. I guess unless you can think of any other things to try, i’ll just accept it and move on.

I am wondering what I should do with something like a minigun behaviour with the VRExpansionPlugin, where the player should be able to double grip for less recoil but the gun still stays attached.

Do you have any suggestion on how to go on with ?

I played around with the gunbase setting its center of mass to the middle bottom, then restricting all translation axis and the roll axis to 0. Also I used “dont use grip location for COM” in the advanced tab.

Before that I looked at the lever component but it felt like the GunBase was the better way to go for .

The delay isn’t related to that, the bandwidth cap would cause connection saturation and VOIP to cut in and out.

If I understood your original post correctly you were getting a 1 second delay or so before it registered you as talking without PTT, I believe that is configurable directly in steam itself on the users end under settings.

Programmatic configuration of that I do not have implemented anywhere.

Basically an empty double grip that doesn’t do anything? If you are on 4.18 you can set the new distance based influence to 0 and turn it on, will force the second hand to never have any influence over the aiming of the gun but will still trigger and act on secondary grip events.

Then you can just scale however you handle recoil (animation or additiontransform) depending on if there is a secondary grip or not.

That being said, miniguns typically SHOULD have second hand influence.

On that topic I should probably add a way to set a constant secondary hand influence…that could be useful to have it always scaled down to like say half influence for a large weapon.

Edit You can manually do the secondary grip logic btw…But I think that a “custom” secondary grip that is empty and that scaler is likely something that the plugin could use.

Sorry maybe I wasnt precise enough with my question or maybe I didnt yet understand your answer.

By …“where the player should be able to double grip for less recoil but the gun still stays attached” I meant a minigun which is attached to a tripod or anything and can rotate on two axis. Maybe isnt called a minigun then… :slight_smile:

Edit: So far I just the Center of Mass for GunBase where I would like the Minigun to be attached to the turret. First I thought its better to make a seperate physics handle connecting the minigun to the tripod, but already having system inside the gunbase interaction options looked more promising.

Ohhhhh, add a secondary grip to it then, but don’t have it be a hand, pass in the bipod as the secondary grip component instead of another hand.

Then lock the roll.

Anything super custom would likely need a custom grip, but that should be 99% of the way there.

You know…I totally forgot the most obvious, quick, and simple method.

Use another GripMotionController and set its bUseWithoutTracking variable to true. With that set it basically just becomes a gripping component, then use it at the end of the bipod to “grip” the gun when the bipod is set up, and AddSecondaryAttachment the players motion controller or hand mesh so that it follows it in reverse. When the bipod is done being used you can drop it from that extra grip controller and re-grip it with the players one.

I just patched in a fix for bUseWithoutTracking so that they don’t try to poll the tracking data on secondary grips anymore.

when that boolean is set the controller skips all motion tracking and extra logic and only runs the gripping logic, so its basically a stand alone gripping component.

Nice idea. Guess when I want to continue with that and go super custom to allow also double gripping the minigun while it is in “attached” state to tripod I would need a custom grip for sure…