You aren’t supposed to turn off the chaperone, they used to have the keys accessible to developers to turn off and I believe removed them being writable to from non overlay applications because some programs were maliciously turning off the boundries.
That being said I haven’t specifically tested turning anything like that off since they made a statement.
Also I don’t provide a function to write to any of the property keys as normally there is no reason to ever do so for a game, I only provide reading functions.
I updated project to 4.22 and installed new version of Plugin. Has there been lot of changes? My FPS Pawn isn’t working correctly anymore as a Client. The relative location of the Hand components are wrong (everything under MotionController)
In Image below, Server is the Top one. The Sphere should be in front of player. When playing as a client, location changes to be top of the players head. Not sure what is causing . I can adjust it in beginning of the game with Authority tests, but something doesn’t feel right.
Ah Yeah I forgot to mention that in the patch notes, Epic fixed an engine bug and introduced a far worse engine bug in its place with the fix.
I have had a bug report in since preview 1 mentioning it but they have the fix slated for 4.23. I had to modify the FPS Pawn to attach later as well. Sadly it effects more than just the hand re-positioning and I imagine that a lot of peoples projects just started having some issues in 4.22.
Original Issue
Bug report from “fixing” that issue
If you care to vote on the second one at one point to raise its priority, its actually a FAR worse bug than the original “fixed” one as it comes up a lot more often.
I just downloaded the template, switched it to 4.20 and added in the pre-built binary package for 4.20 however when the project loaded up I get a ton of errors for about 50% of the BP’s. Is a known issue?
need advice on cabinet blueprint. i did change the mesh and position of the cabinets. but seems contraint position locked. how can i fit the constraint position to main cabinet? (when i rotate the cabinet blueprint on the level?)
You would have to change the constraints settings to account for the different axis of rotation, i’m sure there are engine tutorials for general constraint setup around. The grip itself doesn’t care what you setup there so nothing on my plugins end would need changing.
However I would actually suggest not even using constraints for that unless you really want the simulation for pushing against them with objects. Using the VRLever component is 99% of the time the better solution as its more solid (and I recognize the fire engine in the background and they would behave better in motion with the main body ;p).
Or at least I am assuming that you are attempting to change the axis of rotation, as actually rotating the cabinet in the example template works fine.
I upgraded my game and the plugin to 4.22 and everything went well except for one frustrating bug. All static mesh components on gripped objects were not late updating. Skeletal mesh components were fine, it was just static mesh components.
I’ve spent a few days trying to debug . There didn’t appear to be anything wrong with how the motion controller component was performing the late update on the gripped components. And I wasn’t getting the same behavior on the project that comes with the plugin. But then I discovered that it had to do with the scene capture component I was using as a mirror so I could see my player in 3rd person.
You can test out in the plugin’s sample project. Grab the gun, go over to the mirror, and press the button to turn on its camera. You’ll see that the gun (which is a static mesh) no longer late updates. Turn off the mirror’s camera, and it correctly late updates.
So isn’t an issue with the VRExpansion plugin itself, but within the engine. I just wanted to let people know about bug in 4.22 so you don’t spend days trying to figure out what broke with your own objects. I’ll have to put together a test case to submit to Epic (unless someone beats me to it).
So after a few months break to work on other things, I came back to my project. You told me to use a Drop and Socket node - for dropping an object and socketing it to something. I’m still pretty new, maybe I’m just missing something obvious, but I haven’t figured it out yet.
Attached is how I’m attempting to use it, in a blueprint for an object to be dropped and socketed (a sphere), (the static mesh component), and attach to a separate blueprint object (get cube). I’m just using a grippable static mesh actor, do I need to override the “normal” object dropping in the Vive pawn? (using the template)
Yeah it replaces the “drop” node, way it does the drop AND the socket in one step, removing potential packet ordering issues.
The newer templates check “RequestsSocketing” and if the object wants to socket at the time of release it calls DropAndSocket instead. But that is entirely optional and can be decided in any way you want.
Hi everyone. I posted in the answerHub and reddit because I don’t thintkhis is a vrexpansion issue but since it’s VR related I thought I would give it a go here.
I am pushing steamVR skeletal input through an anim pose on a skeletal mesh (standard UE4 hand mesh) using valves recently released unreal plugin.
I also have a fully replicated player pawn (thanks to plugin)
I’m running into an issue where the animations of the hand are not replicated between server and client (though transform is). Furthermore, the animations my pawn drives are duplicated locally on other players pawns (the other pawns are mimicking my finger curls and splays).
I’ve solved problem years ago but am revisiting it now and running into issues. I feel like the skeletal mesh component used to have a replication option like “replicate skeletal mesh” or something.
Have you noticed that after upgrading to 4.22 the render custom depth system is not working in VR anymore? When trying to highlight something, the highlighted edges are showing really weird and are all over the place. With traditional way everything works. Is it a Engine Bug, or is there something changing in VR plugin?
They changed much of the rendering system in 4.22, there is an open bug report about the custom deph buffer having issues currently which most highlights use.
That being said, the custom depth buffer has ALWAYS had issues with the forwarded renderer with MSAA due to scaling precision inaccuracies.
None of the Valve SteamVR plugin is setup for replication currently, in fact the layout of it is somewhat against replication being easily added. I’m waiting for a solid stable version of it (hopefully with some suggested changes) before I decide where to take my module that implements the same thing and how best to merge the two. Currently it doesn’t look very good for me being able to avoid a lot of custom implementation.
The reason your hand animations are duplicated is because their animation node is directly querying SteamInput for the current hand poses, means it will always take the local players hand poses. I will likely need to create an alternative node that takes an optional transform input to work off of instead of the hard coded query.
Also though, in most cases you will likely want to replicate and use finger curls / splays for your hand animations, it is more friendly to pose blending and has far less overhead for replication, in that case it would just be replicating the curl values and applying them in the animation graph to blend between a fully closed and fully open hand pose depending on the grip.
Its really only when nothing is held that you would want to fall back on the full transform list.
Thanks for the reply . I really appreciate everything going you’ve been doing for the VR community.
I figured I was going to have to go that route, but I was worried about latency and honestly hoping for an out of box solution. I’ll ditch the SteamVR anim pose node, replicate finger curls through my pawn and cast the variables as effectors in the anim blueprint. That “should” do the trick because that’s what I did for replicated skeletal meshes before.
Any default replication wouldn’t be any faster latency wise, its still ping limited regardless of who is sending.
You can run the replication at a lower rate and lerp between last and current values to reduce the cost as well. I’d imagine that eventually when I see where they end up on their plugin I will make some default replication setup and merge it into the main SteamVRExpansion module. For now i’m sitting on it though since their plugin is very much still early alpha and has some strange design choices.
Pushed a new update live to both repositories yesterday, forgot to update thread. I made a bucket updating system for 4.22 to manage the client auth throwing addition and when I saw the new subsystem engine capability I decided it made more sense as one of those. Figured that as long as I was cleaning it up and generalizing it more that I would add some blueprint accessibility to it as well for others to use if they choose too.