Increase the linear X drive damping value
Hey,
Are you consider supporting Pico Neo 2 googles in the future?
Thanks 
Could you show me screen shot of where would be. I tried looking just about everywhere to try to find and didn’t see it. I’m guessing I just missed it somewhere.
Click on one of them, then in the property window type Hidden in the search bar.
https://i.imgur.com/qlxIxGa.png
i did try that and it didnt seem to work. Would you know why that might be?
Then you hide the wrong one, if you are using the grasping hands they have their own attached to them.
Just fixed the SetLeverAngle issue, sorry I had misread your report weekend.
As for the negative value, whats your use case for setting that to a negative value? I’m specifically clamping it to positive values, if its just makes more sense mentally to you than I can ABS the value so it always turns positive on the back end.
Hello, with the gun tools and a interactive collision with physics grip type ( such as in a base template) seems to take a reasonable amount of ms. Upon profiling most of seems to come from updating the primitives and updating the overlaps. Is it not a viable grip type to use performantly with the gun tool at time? Anyone implemented physics firearms that would have a recommendation on how to optimize?
That is the physics thread cost of moving the object around, you’ll want to manage that by handling how many collidable bodies you have on the gun at the time, it really should never be a major issue unless you are going pretty extreme on component count. For that matter though, you’ll get overlap check costs that are hefty regardless of it being a simulating object or not if you are moving it around with lots of full collision components on it.
You can turn off overlaps, manage collision, or merge bodies to help alleviate it, same as on characters where a large portion (or even the majority) of the cpu cost ends up being in physics thread updates.
I’m going to assume that if its actually something that is noticable to you in profiling that you must have a large component count on your weapon and are running full collision instead of query only or something lighter.
Sorry to keep bothing you. Which component is it? I have tried the everything under leftmotioncontroller and rightmotioncontroller.
The GrabSphereLeft / Right are the red spheres, and just setting hidden to them to true hides them…
Make sure if you are testing in first person that its also ticked in the FPS subclass, because it does work…
I’ve only been working with Vive_Pawn Character. I’m working in first person, and didn’t realize . So to confirm, the FPS_VivePawn Character is a subclass of Vive_Pawn Character that can still have an impact on VivePawn Character?
I do have the red spheres in both Vive_Pawn Character and FPS_VivePawn Character turn hidden in game. For some reason they are still showing up.
I don’t have any other suggestions for you, that is literally the fix. I don’t know if you modified something somewhere or if you are using another subclass of them with it unhidden.
No, the other way around, FPS pawn only effects itself, but changes to the Vive pawn will effect the fps pawn since it is a child of it.
It only changes a couple of things (hand attached to camera, allowing mouse look, ect) so that testing the full vr pawn can be done in 2D.
Do you think if I were to delete it and then reestablish them, might work?
Hello! I’m running into a problem with my secondary hand dominating the weapon rotation when it is grabbed.
When two-handing a weapon and then fully dropping it, the dominant rotation hand flips from the primary hand to the secondary hand (see video below).
Is there to ensure that two-handed weapon grabs only allow the primary hand to dominate the weapon rotation?
Looks like you are using the secondary attachment on the back hand there, I’m not entirely sure what your grip setup is but you would just always want the secondary attachment property to be on the rear hand grip and targeting the front hand as the attachment point.
If you are using the template gun, it switches primary hands when you drop the rear if the secondary is attached, it then switches back to the rear as the primary if it is gripped at the socket, it may be that you changed the socket setup of your gun and its not performing that flip.
Since that part is all in the bps you can freely change the logic to correct it for your use case.
reaaallly shouldn’t need to.
Thanks for your quick response!
Oops, I actually missed using the secondary grab logic completely! I’ve been using the “GripObjectbyInterface” function for both primary and secondary hand grabs.
However, I still prefer method as I personally like how the weapons sockets essentially glue themselves to the GripMotionControllers.
When using “GripObjectByInterface”, do you know if there’s a way I can tell the logic that " is my primary hand" so it knows which rotation to follow?
Thats the thing, using multi grip with full grips doesn’t, you would need to unlock an axis of constraint in order for it to rotate like that with a physical grip. Also it doesn’t “glue” to the motion controllers at all, it would be finding a median between the two controllers, in fact it shouldn’t by default be behaving correctly for you at all without tweaking so it may be not even having a rear grip for you currently (multi grip would have to be on).
For it to function somewhat like that, you would just need to figure out which hand you want to be rotation free and call SetPhysicsHandleSettings and set the axis that you don’t want to be constrained on that hand to off.
With a gun tools script active the weapon orientation component will dictate what direction the constraint is facing, you can use that to make it easier to know which axis’s to turn off. The melee tools grip script does that by figuring out which hand is in the rear and which is in the front and handling constraint limits based on that.
If you wanted a literally accurate version you could also just use a physics prop script on the weapon and you would have to face both hands in the same direction and align them to aim the gun, no free rotation around a hand at all.