Don’t know if helps, I went to the intermediate file (Bow3_pf1418999182.gen.cpp) after the build tool failed, changed the header from
#include “…/Plugins/VRExpansionPlugin/VRExpansionPlugin/Source/VRExpansionPlugin/Public/GripMotionControllerComponent.h”
to #include “E:/UE4/GladiusQuest/Plugins/VRExpansionPlugin/VRExpansionPlugin/Source/VRExpansionPlugin/Public/GripMotionControllerComponent.h”
Run again the UnrealBuildTool.exe from the windows cmd with the same instructions and worked, so it’s definitely an issue with the relative path.
Btw, when you nativize, are you running it as an Engine plugin or project plugin?
Project plugin, and yeah that looks like the auto gen source is generating the incorrect relative path… Not sure that I can do anything about that on my end?
I was nativizing for quest as well and didn’t run into that in mine.
I’ll post on the UE4 forums, hopefully someone will know how to fix it. I will also try to nativize your exemple template, maybe there is something wrong with my installation.
I didn’t see any guides to installing plugin on a source build specifically, so I followed the video on your website. The project opens and so far doesn’t seem to have any issues. Is the install really that easy for a source build project as well, or did I miss something?
For a source build, you will be building it out anyway, as long as you include the plugin at the project or engine level and re-build your project it will be fine. You just can’t use the pre-built packages without re-compiling them as they are under a different release (even if its the same engine version as the launcher binary).
Yes it is, and no, no current specific tutorials for quest multiplayer with it. Generally it works the same aside from the engine being buggy with oculus subsystem in 4.22 I believe.
You may want to host on something a bit more powerful than the quest itself generally.
Hi, can anyone help me with gripping? I’m using the VRSimpleCharacter and I implemented VRGripInterface in many blueprints but when I grab the item it seems to disappear, until I noticed the cubes were shooting off to other locations. In my VRSimpleCharacter I tried even replacing my call to GrabObjectToInterace with a simple AttachToComponent call that attaches the object to LeftMotionController, but I’m still seeing the same issue.
moving the head around will suddenly add more movement input, making the character move in different directions. happens in empty space (some components are attached to the character)
Are you on the very latest build? I changed some things regarding head movement rollback a bit into 4.23. I may need to make some more tweaks, though I wasn’t getting that behavior in testing.
Also need to know if you are using the VRcharacter or the SimpleVRcharacter, 4.19 was a decent number of releases ago and a lot of that code base changed to be more efficient.
Thanks for the reproduction, it was an issue with some vector projection that I was doing on the movement rewind. I reverted that section to its original implementation for now.
All repo branches 4.21 - 4.24 are updated with the fix
I was going to say that you were passing in the incorrect transform to the grip node, but if it is shooting out when just calling attach then its something else that you specifically are doing. Obviously without calling grip the grip code wouldn’t have any effect on the item anymore.
Hi
We seem to be getting a ton of rubber banding in multiplayer when using the VRMovement component, even in the editor just testing 2 clients or running as a dedicated server, the clients are popping around all over the place. All other objects replicate fine even on clients with high ping so im not sure whats causing in component.
keeps showing in the log
[SPOILER]LogVRCharacterMovement: Recovered move from OldTimeStamp 2.526060, DeltaTime: 0.010276
LogNetPlayerMovement: Warning: CreateSavedMove: Hit limit of 96 saved moves (timing out or very bad ping?)
LogVRCharacterMovement: Recovered move from OldTimeStamp 3.590748, DeltaTime: 0.308742
LogNetPlayerMovement: Warning: CreateSavedMove: Hit limit of 96 saved moves (timing out or very bad ping?)
LogVRCharacterMovement: Recovered move from OldTimeStamp 5.472024, DeltaTime: 0.011180
LogVRCharacterMovement: Recovered move from OldTimeStamp 6.035486, DeltaTime: 0.011590[/SPOILER]
Well the usual cause of that bad of client correction would be you improperly setting position or altering the clients position in a manner that the server cannot reproduce on tick. You have to follow the character movement components replication order or turn on client authority movement in order to do things that way. Other objects wouldn’t show the same signs because they aren’t replicated the same as character movement components.
There are a ton of things that you could be doing wrong though to cause that, keep in mind that the VRCMC is just a modified character movement component, the only major difference is it has some extended capabilities and the rotation is also server rollbacked by default which isn’t how the normal CMC handles rotation.
Not knowing what you are doing specifically with your setup though means I cannot give you an actual answer. You can feel free to PM me here or message me in discord about how/what you are handling movement with.
Got it working, and you where indeed right, was a missmatch in the versions.
But I am realy stuck on one problem, when I spawn ingame (on oculus quest) the camera defaults on the floor, so i gotha lie down with the headset on, reset camera and then stand up, been googling and searched on the forums here. But seems like people are using blueprints with the plug in, but i just got C++ files in the project, so i am not able to find the “track from eyes” and not “from floor”. Tried moving the camera as a quick fix, but it resets to the floor when i start the game.
That isn’t a plugin issue but yeah the tracking origin node just calls the c++ interface function from BP anyway so you can access it freely yourself from: UHeadMountedDisplayFunctionLibrary::SetTrackingOrigin.
Alternatively you could also just
if (GEngine->XRSystem.IsValid())
{
GEngine->XRSystem->SetTrackingOrigin(EHMDTrackingOrigin::Floor);
}
I’m not entirely sure why oculus’s headsets default to eye level tracking anymore since the majority of them are roomscale, but it is what it is and you will need to choose which tracking origin you want to use.
