VR Expansion Plugin

[jawatr]

Hi mordentral, I updated the plugin from 4.17 to 4.19 and I suddently don´t see the meshes in my hand when I grab them. Do you have any idea why? I haven´t changed the code (the plugin works fine with 4.17). I call grip actor and pass the same parameters as before, and the grip actor is a static mesh actor (a sword)

Thanks!

[FrancescoDeso]

I've got a question. I have an object which is being moved with "Interactive Collision with Physics", and I want all clients to have it synchronized, so I'm using "Force server side movement" and I set "replicate movement" to true on the component involved.

It works but it looks very laggy on the client. How can I improve it? Should I send the position from the server with a Multicast and do some kind of interpolation on each client?

[mordentral]

Hi mordentral, I updated the plugin from 4.17 to 4.19 and I suddently don´t see the meshes in my hand when I grab them. Do you have any idea why? I haven´t changed the code (the plugin works fine with 4.17). I call grip actor and pass the same parameters as before, and the grip actor is a static mesh actor (a sword)

Thanks!

Likely have an unlinked node, you need to check in on the migration guides and make sure you make the adjustments and/or step through the blueprints and find out what unlinked.

Migration guides

[mordentral]

I've got a question. I have an object which is being moved with "Interactive Collision with Physics", and I want all clients to have it synchronized, so I'm using "Force server side movement" and I set "replicate movement" to true on the component involved.

It works but it looks very laggy on the client. How can I improve it? Should I send the position from the server with a Multicast and do some kind of interpolation on each client?

Yeaaaaaaa....... Non physics movement replication is not smoothed or predicted in engine at all. However that grip type is simulating so it falls under physics but the constraint is server sided only so the predictive part doesn't work anymore since the constraint effects it (its a velocity prediction, nothing fancy). Perfectly sync'ed physics prediction and replication is a hefty topic and not something the engine supports natively.

This is why the default movement mode is client side and creates the constraint on all clients so the movement is "sync'd" as well as possible without latency.

You can run interpolation and manually send the location yourself but when the object is colliding its not going to look good, if you ran a non physics grip than interpolation between most current known state and the one before it would be the best choice likely.

[TheDKSP]

(I would delete my previous post, but it's awaiting approval...)

I realized I got the wrong template, so I got the right one this time, but I can't build the project files. It gives me the error

"2>LogFileManager : error : MoveFile was unable to move 'C:/Users/Destroyer/Downloads/mordentral-vrexppluginexample-f62d5b04063c/mordentral-vrexppluginexample-f62d5b04063c/Plugins/VRExpansionPlugin/VRExpansionPlugin/Intermediate/Build/Win64/UE4Editor/Inc/VRExpansionPlugin/VRBaseCharacterMovementComponent.gen.cpp.tmp' to 'C:/Users/Destroyer/Downloads/mordentral-vrexppluginexample-f62d5b04063c/mordentral-vrexppluginexample-f62d5b04063c/Plugins/VRExpansionPlugin/VRExpansionPlugin/Intermediate/Build/Win64/UE4Editor/Inc/VRExpansionPlugin/VRBaseCharacterMovementComponent.gen.cpp', retrying in .5s..."

And it always fails. I tried giving it admin permissions, still failed.

[jawatr]

Likely have an unlinked node, you need to check in on the migration guides and make sure you make the adjustments and/or step through the blueprints and find out what unlinked.

Migration guides

I have checked out the info reaching that node and everything is coming correctly; the target (GripMotionController component) the actor to grip (Static mesh) and the world offset. I noticed that this only happens with "Interactive Hybrid Collisions with Sweep", is there anything special about this mode that might make actors disappear?

[mordentral]

I have checked out the info reaching that node and everything is coming correctly; the target (GripMotionController component) the actor to grip (Static mesh) and the world offset. I noticed that this only happens with "Interactive Hybrid Collisions with Sweep", is there anything special about this mode that might make actors disappear?

If an actor collides with something with that grip then it will stop on it, but otherwise, no.

[sphinix257]

ok so i figured out that the character code in the template is overflowing with technical codes. if i where trying to did out the example codes for arm-swinger and climbing locamotion. mainly armswingger that i cant find. what parts should i be looking in. i think i can figure it out from there but i just cant find it in all this code.

[FrancescoDeso]

Yeaaaaaaa....... Non physics movement replication is not smoothed or predicted in engine at all. However that grip type is simulating so it falls under physics but the constraint is server sided only so the predictive part doesn't work anymore since the constraint effects it (its a velocity prediction, nothing fancy). Perfectly sync'ed physics prediction and replication is a hefty topic and not something the engine supports natively.

This is why the default movement mode is client side and creates the constraint on all clients so the movement is "sync'd" as well as possible without latency.

You can run interpolation and manually send the location yourself but when the object is colliding its not going to look good, if you ran a non physics grip than interpolation between most current known state and the one before it would be the best choice likely.

Thanks a lot for the help (and sorry for the late reply!). For now I think I'll try to make it completely server authorative and just interpolate the position in the client, and see what happens from there.

[mordentral]

ok so i figured out that the character code in the template is overflowing with technical codes. if i where trying to did out the example codes for arm-swinger and climbing locamotion. mainly armswingger that i cant find. what parts should i be looking in. i think i can figure it out from there but i just cant find it in all this code.

The warnings will say what is wrong, there aren't that many nodes that changed since 4.17 so it should be a fairly simple fix if you look at the migration guide.

Epic deprecated a few nodes too but those warnings are going to tell you what is missing.

You can post the log to me privately if you want and I should be able to glance through it quickly.

[sphinix257]

The warnings will say what is wrong, there aren't that many nodes that changed since 4.17 so it should be a fairly simple fix if you look at the migration guide.

Epic deprecated a few nodes too but those warnings are going to tell you what is missing.

You can post the log to me privately if you want and I should be able to glance through it quickly.

No no. The code works great. Im using 4.19 that updated from the snapshot releases. Everything is working.

Im just trying to find the code that i need to pick through and learn. I cant figure out what section of codes pretains to arm swinger. Or is there a post somewhere that explains some of the example codes for the template scene

[mordentral]

No no. The code works great. Im using 4.19 that updated from the snapshot releases. Everything is working.

Im just trying to find the code that i need to pick through and learn. I cant figure out what section of codes pretains to arm swinger. Or is there a post somewhere that explains some of the example codes for the template scene

Armswing is literally just handled in the main event graph, its a movement input off of GetRelativeVelocityForLocomotion. Uses the results of CalculateRelativeVelocities for the input velocity.

L/R Hand D Pad Press Based Movement Comment grouping contains it.

The running in place locomotion has a function dedicated to it because it merges multiple velocities and has a low/high ramp.

[sphinix257]

Armswing is literally just handled in the main event graph, its a movement input off of GetRelativeVelocityForLocomotion. Uses the results of CalculateRelativeVelocities for the input velocity.

L/R Hand D Pad Press Based Movement Comment grouping contains it.

The running in place locomotion has a function dedicated to it because it merges multiple velocities and has a low/high ramp.

Cool So thats why i couldnt find it I was looking all through the running in place and i though it was mixxed with that, and nothing elsehad the label. Thats super helpful.

Im thinking a free running style control set where armswing is sprint. And the offhand dpad is a slow walk. mostly because its really hard to armswing and aim a gun, but realistically you only swing your arms when you run.

[pixelvspixel]

Hey Mordentral, I've been working on integrating hand models into the template. I realized that the bulk of animation control takes place in the "Check and Handle Grip Actions" function in the Pawn, what I'm trying to figure out, is where the best place to hook into having an animation play anytime the user pulls the trigger. Currently the template only plays an animation (or attempt) when it's near an intractable object, I'm just not sure where I should hook this in at.


Secondly, I've been looking at the recently released "Hand Presence" demo that popped up on the forums. All of it's grab-able object derive themselves from an actor component, which has a reference slot for calling a specific hand Animation Sequence. It doesn't look like your plugin has a similar setup. What would be the best place to implement such a feature. I assume it should be added to the VRGrip Interface, but I haven't figured out how to make such an edit yet.

Thanks again!

[mordentral]

Hey Mordentral, I've been working on integrating hand models into the template. I realized that the bulk of animation control takes place in the "Check and Handle Grip Actions" function in the Pawn, what I'm trying to figure out, is where the best place to hook into having an animation play anytime the user pulls the trigger. Currently the template only plays an animation (or attempt) when it's near an intractable object, I'm just not sure where I should hook this in at.


Secondly, I've been looking at the recently released "Hand Presence" demo that popped up on the forums. All of it's grab-able object derive themselves from an actor component, which has a reference slot for calling a specific hand Animation Sequence. It doesn't look like your plugin has a similar setup. What would be the best place to implement such a feature. I assume it should be added to the VRGrip Interface, but I haven't figured out how to make such an edit yet.

Thanks again!

No, the grip interface is not a correct place to put it (not that you can edit it in BP anyway). It can be significantly more complex than just a single animation return (supporting per finger placements and the like), also the grip interface is attached to the held object, the data input is in the wrong direction for controlling the holding animation directly as things happen (it would be a single static animation or you would have to keep checking on it).

I would rather leave animation decisions up to the end user since there is a lot of creative freedom there and options. The only reason I copied over epics hand animations is because I was already transferring over their teleport system, I normally wouldn't have added anything as I prefer for such things to be gameplay driven and the addition of extra data to control it is very simple.

Also obviously since I do not have freely available animations and hands for the template to use and it is originally intended as implementation examples for the plugin, not an all in one template.

You'll have to consider how you want to mix controller driven animations and held object driven animations, can be as simple as calling a function on the owning controller to notify that you want a new animation (IE: OnGrip.HoldingController.SetHandAnimation(MyAnimation), to binding a dynamic event to throw new states back to the holding hand to mix into the animation graph.

Basically any generic system I incorporated for it into the plugin wouldn't cover enough cases for me to feel it worth the addition.

*Edit* I'll mention, if enough people pooled thoughts on just what would end up in a comprehensive animation feedback loop I would be willing to implement one.