VR Expansion Plugin

[mordentral]

@;625572

Based on your experience with the character movement code, how would you go about having acceleration free movement for the character (basically how I understand Onward works)?

Character movement components have a “bForceMaxAccel” boolean that does but it isn’t exposed to blueprint by default and would have to be set in code (or exposed). You could also just set braking friction and acceleration to a value high enough to force instantly the/min speed you have set (IE: 2000048.0 just add two zeros to the default). The thumbpad is also using the capacitive location for speed and if you aren’t right at the edge it will start off slower so you need to watch for that, there is a scaler variable I placed on the character that controls how finely grained the control of that speed is that could be increased to make it get to speed closer to the center.

What I am sending through the network over what is normally sent by the way is the request velocity from the Path Finding, not the general movement, enables the client side navigation to work in servers (which I have actually seen a ton of requests for on answerhub for general games). If you wanted to utilize that to directly request velocities with RequestDirectMove you could but it probably wouldn’t play well if you try to run any navigation commands at the same time.

Edit
I did notice that instant accel is easier for a lot of people to handle, I can’t tell the difference myself anymore (sickness wise), if enough people think it should be the default for the template I can just increase braking and accel to get the instant movement effect by default. If its agreed upon that it is less nausea inducing than I would rather have the defaults already represent that.

@jayNose;625576

I’ve trying to get the plugin to work for awhile on 4.14

Don’t copy the first file in the zip over, that is automatically generated by bitbucket, copy over everything inside of that file into the Plugins/VRExpansionPlugin folder. I also recently removed the binaries from the repository, the file history for them was bloating it too much, so now you have to manually build the plugin. is a required step anyway if you were to want to package out your project as I am not providing it as an engine plugin but as a project plugin. If you don’t have any source files for your project currently follow the steps on the wiki to create a dummy/blank one and build the project which will generate the plugin binaries for you.

The plugin is too unstable in its repository form to build binary packages for as I am still updating constantly, I applied to put it up on the marketplace for free which would allow it to be an engine plugin instead and have stable releases pushed instead if it is accepted.

@gausswerks;625464

It happens with both mine and yours. With a drawer at full open, slamming it shut as hard as you can will usually clip the front of the drawer past where it should. Sometimes you can fish it out again, sometimes not. But yes, moot point, we certainly don’t need or want a bunch of physics for a simple drawer. All that aside it does work well. I tried loading the drawer with a bunch of smaller boxes, thrashed it around, everything behaves quite nicely except for the high speed closing glitch as described.

I fixed it, my re-positioning code worked fine but didn’t work after I moved it to the constructor, some of the values must not be ready yet at that point. I moved it back to begin play and the drawers work as expected now. Physics constraints really need some additional exposed variables, there is an open ticket to add them but its about a year old now so not sure what the progress on that one is

I will still be adding in the movement based version weekend anyway.