VR Expansion Plugin

[mordentral]

Pushed a new commit to the plugin today

Merged the VRCharacter refactor into Master branch.

The great VRCharacter refactoring

Added OnBeginWallPushback and OnEndWallPushback events to the characters so people can
darken vision and set up things when pushback is happening.

Added vr.ForceNoStereoWithVRWidgets so that users can globally force stereo widgets
to use only normal widget rendering at will (Fantisfall).

Major overhaul of how the VRcharacter handles movement, cleans up many many interactions
and fixes the few broken features from the old system (bCanWalkOffLedges works now).
Also wall sliding is far cleaner and nicer now.

Basically instead of the old hacky method of adding a bit of movement input
in the normal direction of HMD movement (that I hated and proved more stable than
I had expected). Now during movement the movement mode rewinds the last delta of the
HMD and plays it back as part of the current movement mode. This allows it to act
as a true first party in the movement logic and keeps all of the normal character
interactions largly as they would be in a 2D pawn.

It is more accurate, smoother, and far more reliable in multiplayer (though will still go through some cleanup in the future).

Changed VRRootComponent so that it manually attempts to verify overlaps now if it ends a
scoped movement with detected overlaps but none on final position. This corrects the capsule
1 frame on and off overlap events.

Renamed camera transform replicated variable and RPC so that they show up
more clearly in NetProfile (.nprof) readings (Just read as ReplicatedTransform before, now reads
as ReplicatedCameraTransform).

I am compiling pre-packaged binaries now.

[Warner V]

Pushed a new commit to the plugin today

Merged the VRCharacter refactor into Master branch.

The great VRCharacter refactoring
..many super useful changes

I am compiling pre-packaged binaries now.

Wow, that was quick! You are a hero, Morden!

Also: agree that blanking/darkening vision during wall-slide sounds much better than the teleport (away from collision) I was working on.

Only thing I'm worried about is the fade-out: how to detect an impeding slide a few frames ahead so that I can start the fade? What do you guys think? Create a slightly bigger capsule and take collisions from that?

[Rumbleball]

Base character is just a proxy between the two different characters so that I can reduce code duplication (climbing and special flags that both need), it isn't a fully functional VR character in itself.....

Also TickGrip only does things when there are gripped objects, having no gripped objects it early's out of the loops and only does two transform Gets. If you are making a child of the original controllers you will also want to be totally sure that you aren't calling Super::TickComponent or you will start getting weird issues.


*Edit* I'll note that while looking into the world scale thing today I didn't find any issue with that hitch on 4.18, however I did find that Epics new late update system screws over the motion controllers location if the world scale is not 100.0f.

Thanks, I switched to VRCharacter.

Flying:
Managed to make server and client fly by Setting CharacterMovementComponent:: DefaultLandMode and CharacterMovementComponent::SetMovementMode both to flying.
Can move them around with Pawn::AddMovementInput. However adding movement in flying keeps the character moving after calling Pawn::AddMovementInput. Tried to stop moving using MovementComponent::StopMovementImmediately but that only worked on the server, could use a fix. I finally managed to stop directly after movement input by setting the friction to something high (CharacterMovementComponent::BrakingFriction only works when CharacterMovementComponent::UseSeparatBreakingFriction is true) on Server and Client.

[mordentral]

Thanks, I switched to VRCharacter.

Flying:
Managed to make server and client fly by Setting CharacterMovementComponent:efaultLandMode and CharacterMovementComponent::SetMovementMode both to flying.
Can move them around with Pawn::AddMovementInput. However adding movement in flying keeps the character moving after calling Pawn::AddMovementInput. Tried to stop moving using MovementComponent::StopMovementImmediately but that only worked on the server, could use a fix. I finally managed to stop directly after movement input by setting the friction values to something high (CharacterMovementComponent::BrakingFriction and CharacterMovementComponent::BrakingFrictionFactor) on Server and Client.

Yeah you need friction in the air, and the StopMovement setup is normal for characters, Epic doesn't replicate the current velocity, only current acceleration, and there is no flag for "StopMovementWasCalled".

Flying should behave the same as it would with a normal in engine character. You might be thinking of some of the improvements I have been adding to get around limitations of the engines character like the replicated movement mode change.

You could use the new MovementAction system I added in 4.18 if you ever upgrade to handle that, it is inline with the movement tick and you can make custom ones that do whatever you want. Its main limitation is that it only supports one movement action a frame currently and that it replicates control variables by default that a custom action may not need. I need to figure out a way to define what a custom action uses so that I can lower that cost when one is used.

*Edit* If you want direct flying (no velocity retention) you can use the climbing mode to fly around in and turn off stepping up.

[Sleeper.]

Pushed a new commit to the plugin today

Merged the VRCharacter refactor into Master branch.

The great VRCharacter refactoring

Added OnBeginWallPushback and OnEndWallPushback events to the characters so people can
darken vision and set up things when pushback is happening.

Added vr.ForceNoStereoWithVRWidgets so that users can globally force stereo widgets
to use only normal widget rendering at will (Fantisfall).

Major overhaul of how the VRcharacter handles movement, cleans up many many interactions
and fixes the few broken features from the old system (bCanWalkOffLedges works now).
Also wall sliding is far cleaner and nicer now.

Basically instead of the old hacky method of adding a bit of movement input
in the normal direction of HMD movement (that I hated and proved more stable than
I had expected). Now during movement the movement mode rewinds the last delta of the
HMD and plays it back as part of the current movement mode. This allows it to act
as a true first party in the movement logic and keeps all of the normal character
interactions largly as they would be in a 2D pawn.

It is more accurate, smoother, and far more reliable in multiplayer (though will still go through some cleanup in the future).

Changed VRRootComponent so that it manually attempts to verify overlaps now if it ends a
scoped movement with detected overlaps but none on final position. This corrects the capsule
1 frame on and off overlap events.

Renamed camera transform replicated variable and RPC so that they show up
more clearly in NetProfile (.nprof) readings (Just read as ReplicatedTransform before, now reads
as ReplicatedCameraTransform).

I am compiling pre-packaged binaries now.

Great work man, will update my project tomorrow!

[AtmaStudios]

How can I slow the speed of movement for the ArmSwing locomotion?

[Warner V]

How can I slow the speed of movement for the ArmSwing locomotion?

I think you can play with the 'swing and run magnitude' value in the Vive_Pawncharacter BP (default is 2.0, by making it larger movement should become less if I read it right).

[Silpher]

Hi Mordentral,

I've been trying to register the axis of the triggers, see pic attached.
Somehow nothing shows up when I try to print string it. Would you know why?

Thanks again!

[mordentral]

Hi Mordentral,

I've been trying to register the axis of the triggers, see pic attached.
Somehow nothing shows up when I try to print string it. Would you know why?

Thanks again!

Not really sure where that print screen is going? To tick?

It should be printing 0.0 if nothing else

[mordentral]

I think you can play with the 'swing and run magnitude' value in the Vive_Pawncharacter BP (default is 2.0, by making it larger movement should become less if I read it right).

Or set walk speed on the character differently.

[Curs0]

drop object interface seems to be broken on multiplayer:
when dropping a skeletal mesh actor, it starts to jump *slightly* client side (seems like all its physics bodies have collisions enabled and collide with each other)
no issue in single player session or server-side in multiplayer sessions

if i comment "drop by interface" bp node call and use "detach from component" + "set simulate physics" bp nodes, it works correctly

edit: as I can see there's also a problem with object scale: if root component as a different scale from 1, when dropping objects, client side there some sort of bones shifting

[mordentral]

drop object interface seems to be broken on multiplayer:
when dropping a skeletal mesh actor, it starts to jump *slightly* client side (seems like all its physics bodies have collisions enabled and collide with each other)
no issue in single player session or server-side in multiplayer sessions

if i comment "drop by interface" bp node call and use "detach from component" + "set simulate physics" bp nodes, it works correctly

edit: as I can see there's also a problem with object scale: if root component as a different scale from 1, when dropping objects, client side there some sort of bones shifting

My gripping system doesn't ever attach anything, when you call Detach From Component you don't actually do anything that effects the grip, its only the set simulate physics that is doing anything there. You likely are retaining the grip and not using a physics one so it just doesn't move the now simulating mesh. Setting simulating will detach a component from its parent anyway.

I would have to check on scale with skeletal meshes, the issue with skeletal meshes that that the rootbone transform isn't correctly updated to the physics body so I have to adjust for it on grip, on release I don't actually do anything special though so if you are getting weird scaling results its likely unrelated to the grip itself, and more related to improperly replicating meshes.

Also the "jumping" would be normal if you have multiple components colliding with each other and you simulate the parent which will now collide with its attached children.......

Also want to make sure that you are calling the drop on the server side only unless it is a local grip.

[kusokuso1]

This is likely a stupid question...

Which way would you guys recommend upgrading an older, somewhat heavily modified, template character (from early 4.18), to the latest and greatest character?

[mordentral]

This is likely a stupid question...

Which way would you guys recommend upgrading an older, somewhat heavily modified, template character (from early 4.18), to the latest and greatest character?

The template character itself isn't edited all that often, most of the changes from version to version are in the c++ side of things.

You can pick a choose a few things from the blueprint character to port over, the only recent changes I can think of are using the new MovementAction system for teleports instead of an RPC, and changing / cleaning up the overlap / tracing function for grips.

Everything else is in the automatic update (source changes) where you don't have to do anything except compile the new version.

[mordentral]

Pushed a new commit to the plugin today (fairly minor but important changes, need to do some documentation updates now).

Changed the MoveAction system so that custom move actions can choose whether they use  
the rotator or location or both or none. This can save massivly on replicating them.  

Changed moveaction system so that it is a self contained struct now for ease of use and expansion.  

Added MoveAction_StopAllMovement - calls StopAllMovementImmediately from the movement component  
in line with the move action system (movement system).  

Changed the interactibles so that they re-construct their initial location values on grip  
from the Relative to controller grip transform. This corrects for the client to server delay  
creating an offset on where the grip is on interactibles in high ping scenarios.  

Also corrected the drop distance for slider components so that they run off of the correct  
transforms (relative instead of parent).