Sorry, I’m not sure what you were referring to with “the few”. Checking out the reference viewer for the Vive_Pawn_Character BP you made, seems the only blueprints I need to muck with is the very VRCharacter one my character is based off of, and the Anim BPs for each hand, no?
Got it. So climbing movement is ultimately controlled by feeding in vectors (“direct movement”?) to the Add Custom Replicated Movement node on Tick after having enabled climbing via the Set Climbing Mode node, yeah?
Since it takes in the VR Movement Component, is it correct to assume turning Set Climbing Mode ON overrides the Engine-based movement mode (the one with walking, flying, falling)?
I’m confused about the “turns on/off at times that would prevent hitching.” part. Maybe something to do with momentum preservation? The ladder and zip line part is awesome. Is there already an example of in the template? I didn’t notice one in the 4.15.1 version. I’m curious to see how you’d do it.
Thanks a lot for explaining exactly how it works. You make it sound easy. Btw, should I avoid climbing on huge landscapes?
Pushed a new commit to the plugin, (rather important if you are doing multiplayer).
Removed custom NetSerialize functions on all structs except for the ReplicatedPos
struct (as that changes every send anyway and needs to full rep).
I was unaware that setting a custom NetSerialize prevented the delta serialization of
structs from working. After network profiling however appears to be the case, I had assumed
that NetSerialize covered initial and full serialization only.
Re-worked how the OnRep of the gripped array's detects significant changes to
a grip that require re-initilization. Now that delta is working again the
previous array value that gets passed in is of the previous delta, not the previous array.
Because of I had to move to caching important values and cross checking them with the new
replicated values instead.
Set all grippable components back to the default of bReplicates = false. On these
the VRGripInterfaceSettings will not replicate unless you set the component to replicate.
makes more sense, and the grippable actors themselves which default to bReplicates = true
auto replicate their VRGripInterfaceSettings.
Set position and rotation to not replicate on the VRCamera and GripMotionControllers unless
either has changed. doesn't do much when in VR as they pretty much always change. However
when testing with FPS pawns is a bandwidth savings.
Hey , I’m trying to get your template working and there is an issue. I can’t compile files in template for… well, I don’t know for what reason, it gives an error
Okay, after that I tried to use compiled version, but no luck. I suppose it’s because it’s compiled for 4.15.2 while template is for 4.16… It gives errors:
So I’m sitting here like
Can you please help, what can I do to run template and look at your awesome work?
Morderntral, I wanted to ask one more thing. There is some things in template that is not rendered correctly for both eyes looking like something wired.
And one is maybe harder to notice but near table with examples there is small cube-like wired thing which is rendered just for one eye and seems to be pretty random at it’s position.
Hi Dazvolt, it seems you are using the 4.16 preview. That is a glitch we had in a preview a few versions back as well. I trust it will be fixed again before 4.16 is released.
Pushed new commit to the plugin (Account was locked from login for 3 days >.<)
Moved more of the FSavedMove logic into the base FSavedMove of BaseVRCharacterMovementComponent
Corrected an issue where step up functions were not correctly re-winding failed stepup attempts
causing stuttering and jitter on step up attempts in multiplayer and solo at times.
Now using a more correct movement rewind for when the server sends location corrections to the clients
in VR.
Now rounding climbing movement to 2 decimal precision in multiplayer so that it matches
the resolution that is sent to the server.
Now using a custom quantized FTransform for the grip transforms over network.
transform is only 2 decimal precision so in the blueprint when checking for
the slot grip location I am now only checking up to 2 decimals of precision for a match
I would like to start doing the interaction settings as a quantized value as well but it was clearing
stored values in the editor and I didn't want to ruin peoples currently working setups.
I can’t build a project. Using 4.15 and have everything set up but it building always ends up hanging when creating the library for OpenVR? Anyone come across or have any ideas of what is going on
Hanging? Or throwing errors? If it is just hanging and you are building in Development Editor mode then you’ll have to wait. The UBT system takes a long time when doing the linking for the first build.
Hi again, sorry for the delay, but up buisiness I haven’t much time like I want to deal with the Unreal…
That has sense, attach the desired hand mesh to the hitted component point and in release time reattach to the motion controller…
Yep, rotate a “interactive” actor, like any kind of wheel, I’ve tried but the first gripped controller deattach it at second grip time, although *Can Have Double Grip *be activated. I tryed also to add both sockets like the Gun example. I suppose I’m leaving any parameter, really you have a complex system, looks like for many cases… but is not so easy to control deeply at the beginning
I am an Art teacher in Ct and we are doing a large class project designing a game in VR. I would LOVE to incorporate your plugin and it looks amazing. However, I am having a pretty difficult time figuring out how to get the plugin to work? I am new to game design as of year and would greatly appreciate any more detailed explanation of how to get plug in up and running?
I have downloaded the plugin.
I have created a plugins folder in my project
I have installed visual studio
I have opened a c++ class in a new project and selected “build”
At point I am unsure of how it all begins to come together?
I cant seem to get the example working and was hoping that would answer a lot of issues for me?
How do I set up the program inputs for the vive controller to work with these plugins?
I looked through your videos but they are all demo’s. Maybe i missed something?
Anyway Im sure you are busy but if you have time to clarify some of I would be forever in your debt! Thanks.
Earl
After build (of development with editor) you can run the editor from the .uproject file like normal. Or just press F5 with visual studio up and run it from there.
You can copy the compiled plugin folder to new installations as well.
Once in editor, the VRCharacter actor handles most of the logic.
I am not very good at tutorials, there is one guy making a visual image guide to getting started though and I intend to post that on the wiki when completed (much appreciated work from him).
I would like to mention though that I do large plugin changes between versions so that a version is mostly stable across its engine number, right now with 4.16 I am cleaning up the blueprints significantly and making some core changes to the plugin. The upcoming 4.16 version would be the easiest and quickest way to learn your way around it and how it works from the template.
Ok, was able to spend some more time thanks to students having a half day. The plugin seems to be set up right. I can find it set to enabled under the plugins section of the menu. I tried creating a VRCharacter actor and seemed to be successful up to point! I will keep working on . So I guess you can disregard my last post for the time being but im sure i will have some more questions if thats ok? Thanks again for all of your work.
Ok, so I started doing a bunch of over hauls of the blueprints now that the Gameplay Tags are officially supported / stable as of 4.15, It makes a lot of the use of the plugin cleaner on the “game” side of things.
I also wanted to cut out some of the spaghetti and condense some things down into more functions as well as open up more features on the template side of things. Most of the template blueprints were made
before I officially supported the grip interface and needed some re-working.
4.16 is going to be a major patch for the plugin both for stability and usage.
Gameplay tags being part of the grippable components by default allows end users to do a lot more without my direct support of it.
As a preview these are some of the Gameplay Tags that I am using in the unstable branch of the plugin as use case examples:
Then when checking for drop off of a button for instance I check for the tag
Also for the gun itself on grip it now sets a gameplay tag if the grip is not at the handle slot, so that dropping the grip is done off of trigger release instead of grip.
Secondary grips are also set up in the template to be release configurable by gameplay tags.
Also I am in the process of a pretty major overhaul of the local grips, renaming them to Client_Authoritive and having them send to the server and replicate back to all OTHER clients, not the owning client.
way you can keep the instant non server authoritative grips and secondary grips of the Local grip, but not have to manually replicate them like before.
It still needs a little work but the basics are functional.
