There is a 4.18 Preview 1 branch up that appears to be functional in the repository now, I would be careful however as the editor has crashed on my several times already and preview appears to be rough.
I’m having trouble attempting to make the teleportation arcs visible over a network (it’s the final step I need to implement a ‘spectator mode’ in which a host becomes a camera that can see exactly what a Vive_PawnCharacter player on a client computer is seeing).
I have tried making all the components in BP_Teleport_Controller replicate, making many of the variables replicate (such as the SplineMeshComponent array SplineMeshes), removing the branch for IsLocal under BP_Teleport_Controller EventTick, and making all the code after it replicate as Multicast. Even so, there is no sign of the client’s teleportation arc on the host camera. The host camera is accurately following the client camera so is not a connection issue. Is there something I missed, or something I need to manually implement?
Also, thank you for all your hard work. We appreciate it!
mmm?
Are you working off of a very old version of the template (like pre 4.15?) or did you modify it? I set up arc replication a while back.
If you are on your own project and just trying to get Epics arc to replicate you can follow what I did, you need to spawn the teleport controllers on remote clients as well. By default the Epic setup spawns the teleport controllers locally, you need to spawn on both, and then when activate teleport is called you need to replicate that to remote clients as well.
You don’t replicate the meshes as the actors are local, you replicate when the teleport system starts and stops and have the local clients draw the arcs.
Really? I checked other tutorials on youtube and they all used the spring-arm concept , thought VR would require a special trick. Would you suggest to actually move the camera or just rotate/zoom the entire base plane?
Move and scale the pawn
4.18 Preview 1 beta branch is up on the main repository.
I am compiling all binaries for 4.17.2 and will edit post when the pre-packaged binaries are up for it.
Edit Pre-packaged binaries for 4.17.2 are up
Yes, I was working off an older project which used 4.15. Like you said, the newer 4.16+ projects did have replication, but I hadn’t used them in a while and had forgotten.
It turns out 4.15 already has the teleportation controllers replicated, but not the activate teleport notifications. I translated your replication code from 4.16 into the 4.15 pawn, removed an ‘IsLocal’ branch and it now works perfectly.
Thank you for the help 
Yeah thats an editor issue, I don’t remember what causes it,. you’ll want to check answerhub…
[RIGHT]طراحی سايت](http://www.novinwebsite.com)[/RIGHT]
Thank you for the help
Yeah, blueprints aren’t very mergable so I can’t really port down changes to older versions. That is why I keep the reference template always on the very latest (non preview) engine version.
Hey ,
I recently updated to 4.17, and noticed that the “optional waist tracking parent” seems to have stopped working for VRCharacter’s parent relative attachment. I can’t set the “tracked device” to a tracker anymore, and settings for that section don’t seem to have an effect. I was thinking it might be due to the temporary Grip Tracked Device component having been removed as epic supported the trackers in their component?
I’m not seeing that, its still attaching to a given component for me and the code is still the first branch ran so it overrides all other options when there is a waist parent.
Also the trackers aren’t removed in 4.17, they are deprecated for removal (I remove them in the 4.18 branch), that being said they might be broken in 4.17, I didn’t see the need to re-vamp them getting the correct device ID yet again since they are no longer useful.
Also I need to change how the waist tracking works soon (have a better solution) as well as merge the foot and snap turning into it. I have those slated for 4.18 as well.
I’ve got prob where grippable static mesh objects can’t be picked up at all unless a certain part of a hand sphere is barely clipping into it.
If the hand sphere completely covers the mesh, pickup doesn’t happen at all. If 50% of the hand sphere clips into it the mesh’ll just drop. It’s almost the opposite of the prob I had before with sockets.
(ss of required hand sphere location on the object in order to pick it up)
Any clues what could be wrong? I pmed a link to the project where the issue’s happening. I can pm the link to anyone who’s willing to help. I spent too much time trying to fix it but got nowhere.
I cloned a commit from about a week ago because I wanted to try the “use feet location” toggle so i might be on a version between 4.17, and 4.18. Anyway, sounds great for 4.18 plans. I’ll just wait for that.
I already responded to your PM yesterday…
You have a volume blueprint in your level that is taking up the entire spawn space and collides with the VR trace / overlap channel. So every time you go to pick something up it is hitting the volume around you instead of the object unless directly overlapping it. The reason your hand has to be there is because it forces the sphere to be the first trace hit.
Just fix the collision settings on your volume.
Edit Also for future reference, try adding a break point or print string after the GetClosestObject node to figure out what you are gripping, shouldn’t have been a long thing to debug.
There is no version “Between”, if you were on the 4.18 migration branch it wouldn’t compile for you at all.
I actually don’t think i’m going to change the tracking method in 4.18 after going over it yesterday, but adding the foot / snap turning to it should still be done.
Regardless the parenting works, you may be confusing the tracker no longer moving (staying at 0,0,0) with the parenting being broken? Just replace the old tracker with a motion controller or grip motion controller.
Maybe I’m just confused about how to use it then. I had grabbed commit 8a3ea61 of expansion plugin example from 09-20, which is where the “use feet location” was added, and I’m using the plugin in version from there. The “Tracked Device” field is set to None, and when I try to set it to something it gives me a list of component types, but “grip motion controller” and “motion controller” aren’t available types from in there. Changing other settings in there doesn’t stop capsule from following HMD/camera location.
Use the “SetTrackedParent” interface function for the component, not being able to select subcomponents of the same actor in a uproperty pointer is an engine quirk (flaw?), a setter function gets around that.
I also just did the updates for it today and went ahead and merged them into 4.17 as well, so there is that.
Great plugin!
Currently looking into the template and just got a question. The VRLever component settings only allows rotation in X OR Y axis. Is there a way to allow rotation in both X and Y (like a control stick in a cockpit)?
I tried to work around by using the engine default physics constrain however I can’t seem to fix the constrain to the parent when the parent (a vehicle) starts to move in the world.
Thanks.
Its one of the things I was considering to add to the VRLever, however I hadn’t bothered yet because, as you already tried, my first inclination would be to use a physics lever for that.
To fix the parenting issue when moving, you either need to attach it to the vehicle with the constraint, or have it constrained to a non simulating component inside of the vehicle which follows along by itself.
i’ll note that its on my feature list for the non physics lever currently, just waylaid behind other things.
Edit I’ll move it up on my TODO list, if I get time today I might take a crack at it.