VR Expansion Plugin

Development Platform & Builds XR Development
2398

Did you try it with the engines default template? That is very unlikely to be caused by my code. It is more likely that something is taking the tracker index as a controller.

I know that there is a current crash with multiple trackers enabled (like 4) which would make sense because the the lighthouses take up tracking index’s so you have the same total number of tracked devices (6).

Yurinik made a patch for it that I don’t think has made it in to the engine yet

https://forums.unrealengine.com/deve…ackers-support

The bug report is currently listed as unresolved:

Unreal Engine Issues and Bug Tracker (UE-54387)

2399

I’m currently fixing my project after updating from 4.16 to 4.19.
I had a no vr option to test stuff (flying pawn). was working in multiplayer. Now on 4.19 my Client gets reset by the server all the time to Rotation(0,0,0).
I used AddControllerYawInput/AddControllerPitchInput nodes, but that does not work anymore. For the server everything is fine, but clients gets reset all the time.

Made a normal unreal character for testing. No issue there. Rotation is synced.

AddActorWorldRotationVR does not work either when executed on the client. When executing AddActorWorldRotationVR via ServerRPC on the server, only YAW works, PITCH is not set (bUseYawOnly = false).

Any idea why the server does not get the rotation information for the client?

2400

Hi * Im getting error when packaging my project using the prebuilt plugin
"Creating library C:\Users\Jimmy\Documents\UnrealProjects\Zombie\Binaries\Win64\Zombie.lib and object C:\Users\Jimmy\Documents\UnrealProjects\Zombie\Binaries\Win64\Zombie.exp
UE4-VRExpansionPlugin.lib(Module.VRExpansionPlugin.cpp.obj) : error LNK2019: unresolved external symbol _libm_sse2_sincosf referenced in function "public: virtual void __cdecl FStereoWidget3DSceneProxy::GetDynamicMeshElements(class TArray<class FSceneView const ,class FDefaultAllocator> const &,class FSceneViewFamily const &,unsigned int,class FMeshElementCollector &)const " (?GetDynamicMeshElements@FStereoWidget3DSceneProxy@@UEBAXAEBV?$TArray@PEBVFSceneView@@VFDefaultAllocator@@@@AEBVFSceneViewFamily@@IAEAVFMeshElementCollector@@@Z)
C:\Users\Jimmy\Documents\UnrealProjects\Zombie\Binaries\Win64\Zombie.exe : fatal error LNK1120: 1 unresolved externals
ERROR: UBT ERROR: Failed to produce item: C:\Users\Jimmy\Documents\UnrealProjects\Zombie\Binaries\Win64\Zombie.exe
Total build time: 64.61 seconds (Local executor: 0.00 seconds)"

2401

You should reference the migration guides when upgrading versions, they list things like that

https://bitbucket.org//vrexpansionplugin/wiki/Migration%20Guides%20(between%20engine%20versions)

Specifically though section


**FPS Test pawns**

I converted the VRcharacter over to a server authoritive rotation model early on in 4.19. If you are using FPS pawns for testing or need the legacy "Trust the client" rotation model then you need to set bUseClientControlRotation to true in the VRCharacterMovementComponent.

If you set that boolean to true than it will work as it did before, however the now default and preferred method is to use the SnapTurn / and SetRotation movement actions instead so that rotation is processed inline with the movement system.

Epics default rotation model is client authoritative, I switched the plugin over early in 4.19 to server authoritative with rollback for rotations.

As for pitch, you might want to use the old model or use a custom MoveAction where you send the full rotator, by default I only send Yaw as generally characters aren’t supposed to be pitch/roll modified.

2402

Having just a bit of trouble, and hoping that maybe somebody can help me.

I’m working on a VR weapon system using the VR Expansion plugin. For my bolt action rifle, I’ve got it set so that if the player is holding the rifle with two hands, upon secondary used, the trigger hand will drop the rifle and the secondary hand will grip (with a primary slot grip), allowing the player to work the bolt on the rifle with their primary hand. When the player grips the rifle back, it releases the secondary grip, and I’ve made it so that it instantly regrabs the secondary grip (as a secondary slot grip). All of functions properly.

The issue I’m having is that if the player hits the secondary use, and is now holding the rifle just by his secondary hand, if he drops with the secondary hand, the rifle just floats in the air, but only for the server. On clients, the rifle simulates properly as it should and falls to the ground. I am honestly not too sure how to get to work right. Dropping the rifle like normal works just fine.

Thanks in advance for any help.

2403

What type of grip are you using? client authoritative or clientside_movement?

Client authoritative does everything client side and informs the server, it is the correct mode to use for personal weapons as there is no delay in action, clientside_movement has to wait around for the server to respond.

Also what logic do you have on secondary use? secondary use doesn’t do anything in the plugin itself.

2404

Thanks. I was not expecting a change there as it is unreal default.

It basically works, but only on the client properly.
When set in the class defaults bUseClientControlRotation=true, it works as expected.

When set at runtime, the client can move as expected (no reset), but the server does NOT apply the PITCH/YAW/ROLL to its client character instance when APawn::bUseControllerRotationPitch/Yaw/Roll is checked. (APawn::bUseControllerRotationPitch/Yaw/Roll does not seems to have any effect when bUseClientControlRotation=true is set through defaults)

Cheers

EDIT: I understand your decision for only replicating YAW. In generall we will not need anything else. But for proper and easy testing (especially multiplayer) FPS controlls are badly needed. You realy should add a PerformMovement function that replicates a whole rotator by default.
I also was wondering that you have a AddCustomReplicatedMovement (which does only take a vector for translation) but not a AddCustomReplicatedRotation. I understand that there is the issue of rotation with pivot (pivot is actor or headset). Would be nice to also have a checkbox on that function to decide what pivot to use (or enum).

2405

Engine default is bad for VR, it has no true rotation control so rollbacks or out of sync packets can cause misaligned clients and improper rollbacks. If I ran it more like the simple character it wouldn’t be an issue, but a large part of the VRCharacter is my attempting to keep the relative space concept in place in multiplayer. Whether that is worth the effort or up is up in the air, but I enjoy some of the benifits of it (de-coupled capsule and full room to location mapping retention).

Also I think you mis-understood me, if you have bUseClientControlRotation = true, then you can keep using axis input yaw/roll/pitch to rotate, I tested it, it works fine.

You only need MoveAction to rotate if bUseClientControlRotation=false, that way it inputs the rotation as it happens into the movement array.

IE: bUseClientControlRotation=true = everything is default engine behavior.

2406

“it has no true rotation control” I gues you mean the relative rotation of the camera component? If that is the case for the actor rotation, how can it be of any use in multiplayer?

I actually do not understand much of that stuff. Multiplayer is its own world of wonders and VR only adds on top of that.
I’m very thankful to you to so much effort and support into plugin.

Yah, it does work when set in Blueprint Defaults. But it works different when set at runtime (PIE).

2407

When set at runtime you have to set it both on the server AND on the client, if the value differs then they are out of sync, it won’t know to assign the value. is actually true for 90% of the character options.

2408

That fixed it, thanks.

Something else:
GrippableStaticMeshActor does not seem to replicate its StaticMesh to the client. Just placing GrippableStaticMeshActor in the world, giving it a mesh and going for PIE, the GrippeableStaticMeshActor does exist on the client, is visible and hiddenInGame=false, so it should be there. But quering the StaticMesh of the StaticMeshComponent on the client returns MatineeCam_SM from the engine content (it should be a Cube mesh), which does not render nor does it return a name. I tried adding another StaticMeshComponent, but that also does not render.
All replication settings I found on the GrippableStaticMeshActor are set to true.
The StaticMeshComponent is actually a UOptionalRepStaticMeshComponent, maybe something missing there?

2409

Static meshes are “static”, they don’t replicate their meshes like skeletal meshs do. is why you can’t dynamically drop normal static mesh actors into the level.

You can load them by setting them to bNetLoadOnClient in replication settings though, I have that off by default. I’ll reset that to true by default.

Think defaulting that to false was a fallover from some of the test objects.

Edit

Patch is up on the repository


Removing bNetLoadOnClient = false from defaults of grippable actor classes.

Leaving it as engine default instead.

My bad,  shouldn't have been reset, people may want to check their settings after .

I’ll note that the primary reason for having off is to force the client to receive the current position of an object on net load. If an object is held with client side movement (movement replication is off during to lower network load), then its initial position will be its level placement on load, not its current location.

Setting bNetLoadOnClient=false forces the initial replication to send current position, while it generally should be the default setting for grippables, it does prevent place and set grippable static meshes.

2410

speaking of guns. im confused as to how it finds and attaches the hands to the gun. ive tried editing the gun and swaping out the mesh but i cant seem to get it to connect to my sockets.

im trying to make a flash light, and then a hand gun. but i want it to snap like the rifle does.
im also completely baffled by how the sliding mesh above the rifle works. i cant find any reference or code for it.
can you point me to a write up or give me a basic explanation as to how these work

2411

The sockets have a prefix ID on them that the plugin searches for VRGripP for primary and VRGripS for secondary, but you can use any override prefix if you set it, or override the GetClosestSocketInRange function and return whatever you want.

As for the sliding cube, in the latest template it is a VRSlider component. In older ones it uses the interactible settings, but I am removing those in 4.20 so I wouldn’t suggest it.

2412

I’m using client authoritative, but I’ve tried other modes as well just for the hell of it, but same result.

The relevant code for ‘on secondary used,’ is below. It properly drops the primary grip, regrips at the secondary grip point. However, if you drop the weapon from that secondary (now a primary) grip, on the server instance, the weapon floats in mid air. You can still re-grip it and everything like normal, it just doesn’t simulate (while it does appear to properly simulate on connected clients).

If need be I can take a video of the issue, as my description might not be good enough.

2413

You don’t have to set held, the plugin does that for you.

Not sure what your drop logic is for the end of the secondary so I can’t really tell just from that.

Is it when the server itself is the one doing it or are you saying its when the server is told by the client about it. Other modes should have problem, it would be client authoritative that would if any of them do.

Edit I built it out for testing and it worked fine.

Really quick and dirty mockup using the templates gun, works for client and server

2414

Yeah, I dunno why I had set held in there. I think in the process of trouble shooting my code I put it in.

Thanks, I figured out where the issue was happening. Somewhere in another bit of logic I was editing the actor’s grip interface settings and accidentally set it to ‘force client side movement,’ and it was overriding the start settings.

Works like a charm now, and I really appreciate you taking the time to help me troubleshoot it. The blueprint for my weapon system is getting pretty complex and so sometimes I lose the little details.

With that though, I now have a fully functioning template for all the basic firearm types (shotguns, pistols, sniper rifles etc etc)! I couldn’t have done it without your plugin.

Thanks again.

2415

Finally, I have a little something to contribute…

Chaperone bounds BP bug (and fix!)
(Tested with latest example: -vrexppluginexample-c64a3b80b871.zip)

When using room scale on Vive, the chaperone bounds used by the teleport preview are wrongly oriented.
The head aiming arrow is correct.

Simple demonstration:
Set Vive_PawnCharacter.bTeleportUsesThumbRotation = false (to avoid inadvertent rotation)
Point HMD towards a corner of your play area.
Start the game.
Note that view is aligned with world axis (as defined by PlayerStart), and that the SteamVR chaperone is correctly at ~45 degrees to .
Start a teleport preview, note that although chaperone shows that you are looking towards a corner, the teleport preview says you aren’t.
Aim directly down, and you can easily see that the preview doesn’t match

The head aiming arrow is correct, but the chaperone preview is wrong.

The fix is to correct the offset. Insert the selected elements:

fix2.png
fix2.png1920×1080 377 KB

fixes the orientation of the teleport preview.

However, if (like me) you prefer Vive_PawnCharacter.bTeleportUsesThumbRotation = false, then you will now notice that, in general, you have a permanent rotational offset between your playspace and the game world.
is because on startup the game world is rotated so that the HMD view direction is as indicated by PlayerStart. So, if you are facing towards a corner of your playspace when you start to play, then the world will be rotated by ~45 degrees relative to your playspace.

It’s much nicer to not have offset, so I added a new variable ‘Align World With Chaperone Axes’, which when set to true quantises the output of GetHMDPureYaw to the nearest multiple of 90 degrees. The effect of is that your playspace (and hence chaperone region) will always be aligned with the XY gameworld axes.
The (minor) cost is that your starting view direction will only be within +/- 45 degrees of that defined by PlayerStart.

To add functionality add the selected elements:

fix2.png
fix2.png1920×1080 377 KB

works whether you set Vive_PawnCharacter.bTeleportUsesThumbRotation to true or false, but isn’t really needed when it is true. When it is false though, I find it essential!

2416

ok. so im fighting with the door code and ive had fairly good results so fair, but im a bit stumped.

im trying to make a door that i can only grip by the handle and open. but i would really like a door where i can turn the handle and then open the door.

i tried with the frame as root with the handle as the grippable mesh and the door attached the handle. worked great but i couldn’t figure out how to get onGrip events to activate, so i couldn’t set the physics.

and then i tried it more like your method. but then the door stopped following the handle and i really dont know why.

note: networking is not important to game.

can you help me out

2417

nevermind. i found it. “on child grip” thankyou.

i thought it only did child actor class but i was wrong