VR Expansion Plugin

[mordentral]

Hi Mordentral,

Hoping you might be able to point me in the right direction in tracking down a bug.

So I set up the 4 way base station with my vive pro's via this page:
http://holocafe.de/en/blog/posts/how...-base-stations

Everything works with my setup in 4 way until I launch the game with the trackers turned on, which causes the crash.
The crash seems to be a null pointer issue.

The issue seems to be specifically with using the 4 way lighthouse tracking setup and the 2.0 htc trackers and the template. Maybe openVR, grip motion controller component, or something else.

To narrow down the issue:
-I tried your latest template, and it has the same crash so it isn't isolated to my setup.
-I checked the default steamVR space which does show the trackers moving around so they do seem to work in 4 way lighthouse setup within steam itself.
-The 2.0 trackers have been working in a 2 way lighthouse setup so no issues there.

I realize I'm probably out on a limb here with the 4 way tracking setup, but I'd like to try and isolate the issue and continue to push forward with my tracking setup with the much needed robust tracking. I'm trying to move into using C++ more often,and hoping since you know the code, you might be able to point me in the right direction in terms of where to put breakpoints or what else to try to isolate further on the issue.

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:

https://issues.unrealengine.com/issue/UE-54387

[Rumbleball]

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). This 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?

[olin3d]

Hi mordentral Im getting this 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)"

[mordentral]

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). This 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?

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

https://bitbucket.org/mordentral/vre...ine%20versions)

Specifically though this 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.

[Lone_Rebel15515]

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 this 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 this to work right. Dropping the rifle like normal works just fine.

Thanks in advance for any help.

[mordentral]

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 this 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 this to work right. Dropping the rifle like normal works just fine.

Thanks in advance for any help.

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.

[Rumbleball]

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

https://bitbucket.org/mordentral/vre...ine%20versions)

Specifically though this 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.

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).

[mordentral]

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).

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.

[Rumbleball]

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).
...

"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 this plugin.

...
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.
...

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

[mordentral]

"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 this plugin.



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

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. This is actually true for 90% of the character options.

[Rumbleball]

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. This is actually true for 90% of the character options.

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?

[mordentral]

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?

Static meshes are "static", they don't replicate their meshes like skeletal meshs do. This 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, this shouldn't have been reset, people may want to check their settings after this.

I'll note that the primary reason for having this 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 this 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.

[sphinix257]

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

[mordentral]

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

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.

[Lone_Rebel15515]

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.

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.