I have tried and it works fine for me.
For packaged games i had to destroy the possesed pawn before traveling and respawn a new one once the travel was complete, not doing caused a crash.
Though im not sure what your issue is specifically.
Also, does anyone know how to ship the knuckles bindings made in the editor with a package game?
The bindings show up in the packaged under the steamvrbindings folder but it wont use them when running the game
Hi Rareden, thank you for your return. I was succesful, with a very simple project with VRCharacter, servertravel is fine, without destroying and respawning. Unfortunatly with our projet, client crash, and server looks like to be spectator. Anyway, we will investigate, is not the VRExpension plugin apparently, but UE4, sometimes messy with multi network setup. And good luck with steamvr…it is also sometimes a nightmare with manifest…
Hi,
Thanks for the plugin, just started using it and is amazing. I have a question that I could not find in the documentation, or maybe there was something about it and I missed it so sorry if it is a stupid one. I am trying to have two players play from the same room ( room-scale) and I have a map the size of my real room. When I spawn the pawns, I spawn them in 0,0,0 which is the center of both my real room and my game room, but if the players are not in the center of the room in real life, their pawn is going to spawn in 0,0,0 and from then, their real life position won’t correspond to their in game position ( Screenshot by Lightshot ). I don’t know if my exprimation was correct but what I am trying to do is instead of spawning the pawn in 0,0,0 I want to spawn the room-scale in 0,0,0 so that their real life location and in game location would match. With the original pawn from Epic worked without me doing anything.
Don’t use the spawning from the example template, it offsets by the HMD to match the actual position since most people don’t want 1:1 roomscale. Just spawn the actor itself at the 0,0,0 location and you will have behavior just like the Epic Template (delete the offset logic from the spawning that is, or write your own that doesn’t do it).
I am currently not using the one in the example. I am simply spawning an actor at 0,0,0 location (no other settings). I am using the VRSimpleCharacter as a parent class and I’ve unchecked the Offset by HMD option on the camera (not sure if was going to to something towards what I wanted to achieve but it didn’t solve the problem) . If I use a pawn derivated from VRCharacter instead it works. Is there any settings in the VRSimpleCharacter that does that or should I just use the VRCharacter?
Oh, you need to use the VRcharacter for exact scenerio, the simple character is simple because it doesn’t retain the full roomscale (didn’t have to re-write the character movement for it).
Can you trigger a grip without needing player input? i have a object that can be thrown and recalled, i want the object to be gripped again once it returns to the hand and attaches but without the player needing to grip it again.
Yeah call it manually from the controller it is returning to.
A few small changes prior to 4.23 dropping.
Patch notes here:
https://vreue4.com/patch-notes?secti…23-final-patch
Also I wrote a news entry about how I managed to extend my Valve Index cord range without latency and within a budget (default cord it comes with is right at the edge of DP 1.2 length limits).
Thanks for answer, setting up VectorDisplacementmap and down scaling to 4K resolve problem of texture appearing.
But, can you give some workaround for: texture appears upside down when SetSkyboxOverride_LatLong?
https://steamcommunity.com/sharedfil…/?id=676747488
There is a steam guide on Equirectangular image formatting for steamVR which is the image format used with the LatLong option.
I pass the data in as is so it should be in the creation step that you are getting improper results.
A question: I’m trying to use a Procedural Mesh (with slicing functionality), but I want to have control over the gripping options of the resulting mesh components.
Since there is no “Grippable Procedural Mesh” component in the plugin, do you have any ideas/recommendations on how to set up?
Someone a few posts up made one just by copying the static mesh component and changing the base class. The issue is that the default slicing functions only generate the default procedural mesh components so they would have to be copied over to the new base class then.
You can grip them normally with a Grip command, if you want more control than just the stiffness and damping though, in the latest releases, post the actual grip you can either call SetPhysicsHandleSettings to set an axis by axis stiffness / damping, or you can alter the grip structs advanced grip settings (set members) to choose the options that you want and then call UpdatePhysicsHandle to update the values (on the server if multiplayer, when it replicates down the changes the clients should auto update).
That gives you full control over the grips physics settings without it being interfaced as it forces it to re-init to the new values.
Hi, I’ve just finally given in and decided to try plugin (I only refused to at first because I thought it would be really difficult to get working in my project). I got it today and got all my existing character’s stuff implemented into the VRCharacter, but how exactly can we get the roomscale movement working? I added the UE Mannequin mesh but can’t seem to get working right. Is that mannequin supported with ? The plugin looks like amazing stuff, I’d really like to understand how to work with it.
Edit: sorry, know what, I haven’t looked at the example template yet. I’ll start there
Attach it to the ParentRelativeAttachment and set the ParentRelativeAttachment to “foot mode” which will place it on the floor before the HMD.
Holy ****… it can’t seriously be that easy. Thank you! I’m excited to get working. I’ve been putting off “figuring out” roomscale and I think it’s time. Where is “foot mode” you mentioned?
On the parent relative attachment, most other things just work, with the difference that when calculating positions for things and such you should be using GetVRLocation / GetVRRotation as that is the offset position.
Got it working, truly amazing! I’m going to have to resort to using a different mesh for myself versus what other players will see like most games. I was trying to avoid having to do that but it seems to be the way to go. I’ll be patronizing ASAP!
Thanks for your support! Unfortunately I’ve been playing with your suggestions for two days and I don’t manage to get it to work properly…
My main goal is to set up the grip as “Sweep with Physics”, as well as to use the Grip Priority to filter between multiple overlapping objects.
I have some questions on your input:
You mean duplicating it manually in the BP? Or creating a new component and setting up the attributes one by one?
Yes exactly… and as far as I can understand there is no way to copy over the ProcMesh (though the individual attributes ‘Vertices’, ‘Triangles’, etc) without losing the collision… and there’s no good way to dynamically create a high quality new collision.
My best attempt so far is to spawn a second copy of the actor and to do the whole thing twice (destroying one ProcMesh component in each actor after the slice)… But it’s not very efficient.
Is a Grippable Procedural Mesh at all on the roadmap?
He just copied my static mesh component class and changed the base class to a procedural mesh one (in c++). Then made it so after he slices something he copies the mesh from the proc mesh that it made to a new one of the grippable type and then deletes the original.
I could easily make a grippable proc mesh class, the issues I had with it was I am not really willing to support the slicing part by deleting originals and copying the data to newly spawned copies, its unwieldy and overly complex (and inefficient), so I would have to then go and make a custom slicing function to handle slicing specifically grippable procedural meshes (wish they took a class type pointer instead for that function).
At that point it is almost easier to contain the sliced components in seperate GrippableActors instead for ones that you want to pick up, and set the proc mesh to the root component.