For some reason the client side movement stopped working, i can still turn and look around. After packaging and testing with 2 HMD’s the view on the client side doesnt respond to input and it doesnt do room tracking.
The controllers aren’t tracking as well
I did nothing new but open the project again morning.
I feel it’s somewhere wrong in the Steam_VRPlayerController because no matter what pawn im controlling nothing works.
Is it set for auto possess? Teleporting to map point 0,0,0 is when the pawn gets taken away from you (like the server takes it because of auto possess)
Don’t know what to tell you, if the controllers are on the floor then they are being used by your steamVR, but the FPS pawn locks them from that so it should matter (using the FPS pawn right now for testing with my vive plugged in behind me).
Was going over some climbing blueprints today, its really quick (sub 10 mins) to do it single player, the problem is properly replicating it (with body collision against walls) in a network environment.
Started adding in direct movement (non velocity non acceleration unit movements on every tick) to the client side replication stack today, should make it possible to work the climbing in to a networked environment while using a character movement component (as well as other effects, leaving it open ended). The problem with just replicating movements over with an RPC is that the server will get things in the wrong order due to movement queuing and rollback the client without .
4.15 alpha branch has it completed for the simple character, the other one will take a little bit longer as I wasn’t already injecting direct movements into its replication.
Still not sure how I would want to approach hand location in the real world vs in the game world when in contact with surfaces (or if I should even support full body collision with climbing at all).
Awesome!
That’s an interesting thought. I feel that you won’t really need to worry about collision of the hand though.
You are tracing to a surface then sticking the hand to that surface essentially. So that trace alleviates the need for that collision. Completely depends on how your climbing system works i guess, how long that trace is Perhaps it breaks immersion for some people, just seems like a whole lot more to do though, heh.
With your hands fixed in place like that it also means that the person isn’t going to move around within the room space much (not from where they start anyhow), so i’m not particularly sure that sort of detail would be worth while.
I meant having “body” collision with the world while climbing. If you collide with the wall you would need to either push back or black out the view, with the push back method your hands end up not lined up with where they are in the real world anymore since they are “gripped” at a point.
Its not a problem with the normal climbing that everyone is doing where you don’t collide with what you are climbing on, I have just been thinking about whether there is a work around or not.
Im trying to set up a Slimmed down version of SimpleVRPawn. However, im having some trouble.
I have parented motion controller meshes to the motion controller components like done in traditional set ups. But when i press play the controllers are moving around on the floor? I can see in the example blueprint even though the hand meshes are parented to motion controllers in the simpleVRActor blueprint viewport, We are spawning the BPTeleportControler blueprint and then attaching those to the capsule within the event graph. Even though blueprint doesn’t have any motion controllers in it? The UE4 eample VR Player blueprint has alot of code that is redundant in terms of my project so i would like to avoid bringing it into my project to spawn from if i could. Is there a way i get the parented meshes to perform as expected without doing ?
There is one on the movement component and one on the character itself, I don’t remember off the top of my head which one works correctly with navigation atm
The default simplevrcharacter also has the meshes directly attached to the controllers, are you sure that both the controllers and the meshes attached to them have their locations set to 0,0,0? As for the teleport controller, that is attached even though there isn’t any controllers in it because I wanted to re-use epics teleport code for people used to it, I had to modify it to work with the external controllers, it is only for the template to show how to merge that part of the default template.
Regardless, yes, attaching hand meshs directly to the controllers should work, check their offset locations to make sure that they are set to 0,0,0.
Also if you want a stripped down pawn, you don’t actually need the VRExpansionLibrary component, it is just for advanced features of steam vr, it doesn’t have anything to do with the basic functions of a pawn.
Well i can not argue with the man who created the plugin!
It was all set to the defaults so it should all be at 0,0,0 but i shall double check when i get into the office tomorrow morning, I know the meshes were rotated? Does rotation matter? Plus the floor is dynamic so i had to make the capsule block all world dynamic to stop the character from falling through the floor and use changed the object type to of the meshes to vehicle. However, i was getting problem before i made these changes anyway. I am using 4.14 if that makes a difference as i did notice i got the same result in the example project when i stopped it spawning from the UE4 example map? The meshes went straight to the floor and stopped tracking?
Thank you very much for your help!!
Will double check all my settings tomorrow and post my findings.
Well the doors are using physx for interaction so that they behave as naturally as possible, its pretty simple how they work though, they just use the manipulation grip on the controllers.
You could get “close” to the same with a physics handle component instead and manually doing the logic.