I’ve heard several people say that while packaging, the Steam API will be disabled and that’s expected. Which seems to be the case because I finally got it working!
We were using the development build instead of the shipping build (which I didn’t realize existed). Once I put the steamapp_id.txt folder in the shipping build, it worked! Thanks again for all the help and for the creating the plugin.
Development build works with steam as well, the demo project is a dev build, you just don’t need the App_ID.txt file unless it is a shipping build.
Just finished making sure the plugin was 100% on the 4.17 preview (had to make some changes due to OpenGL / Vulkan change for SteamVR and some minor code changes in motion controllers).
New social screen nodes in 4.17, “Texture” mode specifically is interesting considering that you can turn off split screen in settings and render a second player to that texture.
Also lets you map seperate camera views to the screen: IE: the mixed reality solution people are using currently.
The VR model loading functions appear unfinished and not ready currently in engine for 4.17 preview at least. Until they are finished and/or exposed to blueprint I will leave my nodes intact in the plugin.
The main plugin will get a 4.17 branch tomorrow, if you want to check it out even earlier the template already has one for 4.17.
Just trying to check out some things before pushing a branch for the main repository.
Edit 4.17 test branch is up for the main repository, i won’t be making pre-packaged binaries until the next preview release as this one is pretty unstable.
Hi Mordentral,
I’m using the 4.15 version of your plugin and get a submission packaging error due to my use of the GetIsHmdConnected node in a front-end widget blueprint. Nativization is enabled. It complains about an undefined struct in one of the plugin’s headers.
Is there an easy fix for this?
Thanks once more for the fantastic plugin. I’ll be upgrading to 4.17 as soon as the current project is complete.
In 4.15 nativization was still a little…iffy…Also if you aren’t doing fully nativized then you need to ensure that you nativize any blueprint classes / structs that are referenced by the nativized class or it will throw errors like that.
Paste the error it is giving you and I can tell you if there is an easy fix or if it is an incorrect nativization setup (also which nativize mode you are using).
Cheers,
I have Blueprint Nativization Method set to Inclusive.
The errors I get are:-
E:\Projects\VMI\VMI_Stanhope\Plugins\VRExpansionPlugin\VRExpansionPlugin\Source\VRExpansionPlugin\Public\VRExpansionFunctionLibrary.h(46): error C2079: ‘Z_Param_Out_ATemp’ uses undefined struct ‘FBPActorGripInformation’
E:\Projects\VMI\VMI_Stanhope\Plugins\VRExpansionPlugin\VRExpansionPlugin\Source\VRExpansionPlugin\Public\VRExpansionFunctionLibrary.h(46): error C2079: ‘Z_Param_Out_BTemp’ uses undefined struct ‘FBPActorGripInformation’
Alright, its not pulling the struct from the Precompiled header when nativizing.
You can either add
#include "VRBPDatatypes.h"
Around the top of the file between the other includes.
Or download the newest version of the 4.15 locked branch, I added the line there for you.
This is not an issue in newer versions as they are now Include What You Use and don’t have a precompiled header like used to be the engine standard.
That did the trick! Thank you. 
Pushed a new commit to the repository 4.17 branch (I won’t be updating main page with changes until the release patch notes but these had to happen due to an oversight).
Forgot to commit some of the steamVR settings and code changes over for 4.17.
Deprecated the vive tracker component as motion controllers finally control it
Made VR stereo widget work correctly in this build, however still cannot use the
world locked setting as it floats off position and weirdly with movement.....
Still using my custom world locked setup for now.
I’m going over the final setup for the c++ lever component now as well since 4.17 seems stable.
If I based my project on your 4.16 template and upgraded it to 4.17 with the newest version of your plugin.
Will I miss out on something important from the template? i.e. the stuff that is in the Content/VRexpansion folder which I based a lot of my objects on.
Or is there anything else I need to think about when update to a later version of the engine?
4.17 is mostly minor changes to get it working with engine changes, I have been updating the 4.16 branch with any actual changes instead of 4.17.
Ok. Thanks for the quick answer.
Ive been having some problems with online matchmaking. Everything seems te be set up correctly and it integrates into Steam, however, sometimes the game fails to find the other hosting server. I try changing the host between PC’s, but it keeps telling me no servers are found. Then after shutting down the program a few times, it finally appears in the server list. Is there a reason why the server finding is so unreliable? Is there something I should do to find the other hosting PC quicker? Can it be because I’m packaging the game quite a lot in different iterations and it gets confused with versions?
Cross build servers don’t work because by default the engine filters sessions by build ID.
However the more likely reason is that currently the SteamVRHomeBeta interferes with the Steam subsystem loading for some reason.
That is a good point, these problems have started after the Home Beta update. I’m gonna do some further research, thanks.
Pushed new commit to the plugin (4.16 master branch)
Skeletal mesh fixed when it has a rotated root bone and is gripped with physics
Still not as optimal as I would have liked, but having to deal with center of mass
and the root bone rotational difference between physics body and main is aggravating.
Also fixed the center of mass setting to an offset location when the object is scaled.
Added ClientSideAuthoritive_NoRep grip replication mode, acts just like ClientSide_Authoritive
except it doesn't tell the server about it. Basically it behaves like the old LocalGrip identifier.
Added IsALocalGrip function to the blueprint characters to clean up checking BOTH of the modes
instead of just the one in some spots now (IE: where it chooses to call grip on client or server
side).
Set all grippable components to auto replicate by default.
Otherwise a lot of funky things can happen, I think I removed this setting a few patches ago but it
has proved to be important in most cases in multiplayer so i'm forcing it to default true
again. Can still be disabled if you want.
*Note* Stereo layer widget components appear to be updating incorrectly all of the sudden, I think this has to do with
the new steamVR patch. I haven't found a fix yet, I can't test on Rift to see if it is working as intended there at the moment.
Hey @mordentral!
Judging from the demo vids, and wiki pages I must admit that it sure seems like you’ve done some amazing work on that plugin.
Also it seems you’re very active in updating and developing it which really makes using it in long-term projects a valid option.
Our studio has recently released an indie VR title on steam (http://store.steampowered.com/app/571860/Galactic_Core_The_Lost_Fleet/).
The last week few weeks have all about learning and designing what’s necessary to evolve it into a VR multiplayer game (we’re thinking dedicated servers).
In any case, I’ve been struggling to find an efficient way of play-testing VR multiplayer in the editor.
I mean even the most basic things, like checking if a replicated actors behaves as expected, if all client’s received some RPC call, if game is consistent between clients.
So a few questions in terms of general multiplayer VR development workflow:
Commented in bold above
“In 2D, I have a function setup so that if I am not specifically launching in VRPreview then it uses a copy of my character with the head and hands locked (ie acts like a normal character).”
Yeah I get what you are saying, we have a similar “KMS mode” setup that runs if HMD is not connected. Is yours available in the template/example project that’s currently available?
“See above but set client or server to non vr mode, can launch from uproject without packaging for local testing”
You mean running the editor from the cmd like “…UE4Editor.exe” “C:\Users\vr\Documents\Unreal Projects\NextStep\myproject.uproject” 10.100.102.2 -game -fullscreen -log -nosteam"?
And do you actually run your multiplayer testing this way as well, having clients/server all run on a single workstation?
“You appear to have some more complicated movement systems in your game”
Even though it comes off as being complicated, I’m hoping it should be not too complicated to pull off in multiplayer, since it’s mostly navigation which by itself is predictable and should be able to run almost completely on the client side (once a path has been calculated on the server).
However since I’ve completely ignored the character movement component in my implementation (I mainly use the “set location along spline” + “Set actor location”, more or less) and so completely ignores not only physics (which we handle artificially), it will also not be able to take advantage of the built in network features such as correction etc.
Needless to say, I manually handle the whole syncing of the “character location relative to camera/HMD offset location etc.” logic myself.
That’s why I was looking in to your implementation as it seems to almost magically combine the best of both worlds.
Correct me if I’m wrong but using the “navigation” locomotion option you displayed I could achieve a similar result, at least for walking around.
For the jumping I would have to choose between the physics approach which you use and a “spline movement” approach which we currently make use of
In any case I’ve downloaded the example project along with the plugin and will be trying it out and playing around with it asap.