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. 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. 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).
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?
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.
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.
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).
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.
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.
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. 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. 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).
I am almost afraid to ask question because it might be super complex… I am curious how hard it would be to have whatever object I grab/pickup replace the motion controllers or hands?
For example… If i pick up a screwdriver, my hand/motioncontroller becomes that screwdriver until I drop it and then it changes back to the motioncontroller. I think would be easier than making everything fit right to a socket.
? Hide the motion controller / hand visually, it is dead simple.
The point of sockets is to get the offset correctly, because otherwise you have to have the zero point of the object offset for the correct location or you have to provide an offset transform. They aren’t really there for the hand mesh to object to be correct as that is implied if the hand mesh is correctly setup to the controller in the first place.
Sockets are the fastest method of iterating over getting correct grip locations, you can do it without them as well, its just generally more work unless you keep in mind some distances like controller zero point to tip of palm, ect.
I think the hiding controller visually and just showing the held object instead might be the way I want to go so then I do not have to worry about hand grip animations/different holding positions, etc. Sockets make sense, but in many ways I feel I am over my head as I have not gotten a socket to work yet.
So to make the hand disappear and the object take its place while holding it would I just do something like “On pickup -> Cast to Motion Controller (L or R) -> Toggle Visibility of Handmesh” ??
Yeah…but the sockets aren’t just for with visible hands though, even without visible hands you are going to need a way to define where the held object is in relation to your controller or it will feel weird if you aren’t free picking it up…
IE: if you snap a baseball bat with a zero point at its center to your hand then you will end up holding it halfway up it and it won’t feel right.
Sockets are just the easy way of doing that can be done with no guess work and in the editor. Otherwise you will have to add offsets, modify the transform of the gripped object, or model it / set the zero point to where you want to grip it at, which also makes it harder for multiple grip snap locations.
Basically unless what you are doing is literally just inflexible gripping of base objects, you will regret direct attachment without alterations down the line somewhere.
You also have to keep in mind that the VR grip sockets use prefix’s for their names to define what ones are grippable, you can check out the gun model to see what I mean, otherwise there wouldn’t be a way of knowing what the socket is for.
