Ah ok, thanks it’s firing and printing now for some gripped components after checking “always send tick grip” on the motion controllers, however it still isn’t firing when gripping my vr slider component… i made sure all my overlap/collision settings etc are the same on the slider component. Is there anything else I need to do to get it to work for specific components like the vrslider?
I perfectly understand that, so for me the important thing is the update of the plugin itself and the bug fixes, so tutorials are not vital, but Q&A is also a nice addition 
It fires for VRSlider, otherwise the slider wouldn’t move, you are likely confusing where to expect the event. It is fired on the gripped object itself, not the containing parent, so if you are expecting to work with it from a slider then you need to subclass the slider itself and use it in there.
If you were to grip the actor itself though, then it would fire in the actor context. I also wouldn’t enable GripTick globally unless you have a very good reason to, it is just additional overhead on most grips. Its fairly useless unless on a custom grip as you can use ticks or timers for normal grips, the only special thing about GripTick is that I fire it off in the controllers ticking time so you don’t have to worry about tick order with it and when the player / controllers move.
Hi , here’s the crash report for the steeringwheel issue. Thanks again for your help, I will support you on patreon end of month.
For other readers, is about an issue I posted about in the comment section on youtube: Weekend project - Car - YouTube
The issue in short: Replace mesh of steeringwheel in Sedan blueprint -> enter play mode -> grab steering wheel (works fine) -> release steering wheel results in hard Engine crash everytime.
A current succesfull workaround is to add a staticmesh component to the steeringwheel inside the blueprint, change the mesh in there and leave the steeringwheel itself alone (apart from making it invisible).
Mmm, yeah appears to be an editor error being thrown, it is really obtuse though and doesn’t give any real indication of what is going wrong.
Yeah, well as long as I have a workaround I’m fine with it, so on to the next fix
I’ve now also mated my custom wheels with the wheel bones of the sedan blueprint. My car has a different wheelbase than the sedan so I have to move some bones around to make the animation align. I’ve tried moving the bones inside the skeleton and also inside the mesh, they preview alright there but seem to have no effect at all whatsoever outside of those specific editors. I also want to try and move the bones inside the animeBP but the translate settings are all greyed out.
What’s the best way to change position of bones? In my case: I just want the rear wheels to move a bit towards the front.
I tried limiting the modes of movement that you have to only 4 (Teleport, D-Pad Press HMD Orient, RunInPlace, and Armswing). Once I’m in the last mode, Armswing, and try to cycle to the next, the text rendered says movement mode. Is there any way to fix ?
After your comment, I see I can do all the same things I was trying to do with GripTick by just assigning the gripped object to a var on Event Child Grip, and using Tick to act on that. Using enable/disable tick on event grip, and event release to minimize ticking. Looks like I won’t need the GripTick, and will toggle off as suggested. Thanks again.
so im having problems with the hands wiggling. ive givin my player a flashlight and theres a kind of springness that i can make it face a full 90 degrees off facing correctly forward if i move my hand and stop sharply enough.
well its really giving weird lighting results from the flashlight around the edges of the beam.
do you have a smoothing setting that might cause that active in the template. or is a ue4 bug/graphical stress.
note the scene looks great and feels smooth when i move my head. but sometimes the hands just wiggle like jello. causing that lighting weirdness
Add wheel bones to your specific car, you should read up on the physics vehicle documentation, I did not make a custom car base, just edited some code to make them play nicer over the network.
Don’t cycle to the next when in, reset to the beginning.
Yeah lots of the objects I turn ticking on during grip and then back off again after it ends. The “Child” notfiers are there just for notification, TickGrip is exclusive to the object to be moved because it is meant just to move the object for the most part.
? Hands should never “wiggle”, as for a flashlight, you probably have it being gripped with a physics grip and it is colliding with the hand that is holding it, turn off collision with the hand for it and up the physics stiffness on the grip.
You can also use a PhysicsOnly grip or just attach the flashlight instead, they don’t use constraints and act like parenting. Generally attachment would be best for a flashlight as you don’t need sweeps and things.
HI ,
How did you reset the value in the blueprints?
Ok. So i did some work yesterday, and found that forward render was responsible for most if not all of my lighting issue. I was baking my lights in but the flash light was dynamic and the directional light threw all kinds of strange stuff at me. And the standard deferred method might be better for my game as it didnt give any lighting bugs at all. And since im using lights in a dark scene. It actually seems to be helping performance.
The wiggling is still present though but it doesn’t seem to be a problem anymore. But im still going to take your advice and make some changes. Thank you for your help
There is a section where it loops through the values in the character blueprints, just alter the logic. The looping really is just for showing them in the template example, its not really meant for a game where normally you would set it via a menu.
I’ve been going through the Vive_PawnCharacter Event Graph and functions, but I can’t find part of the code. Am I looking at the right blueprint? Or is there a specific function that I’m not looking at? Or does part belong to the details panel of one of the blueprints?
It is the blueprint function “Cycle Movement Modes” in the movement category.
thanks a lot, I completely dismissed that, sorry
Pushed a new commit to the primary repository
Changed SecondaryRelativeLocation into SecondaryRelativeTransform, is to allow
for more complex secondary grips in the future and things like forehand tracking during a grip.
Converted physics grips to use the same pathway regardless of type (no longer a seperate
logic branch for manipulation grips, now they just use different defualts).
Removed the bDoNotSetCOM option from the advanced physics settings.
Replaced it with an enum with a bunch of seperate options that also now apply to the
manipulation grip. These extra options are in the AdvancedPhysics section of the grip
settings.
/* Use the default setting for the specified grip type */
COM_Default = 0,
/* Don't grip at center of mass (generally unstable as it grips at actor zero)*/
COM_AtPivot = 1,
/* Set center of mass to grip location and grip there (default for interactible with physics) */
COM_SetAndGripAt = 2,
/* Grip at center of mass but do not set it */
COM_GripAt = 3,
/* Just grip at the controller location, but don't set COM (default for manipulation grips)*/
COM_GripAtControllerLoc = 4
These allow for more complete physics control of held objects, as well as makes it easier to
have multiple physics grips on a single object (future patch is going to give IsHeld an array
of controllers instead of returning a single one).
has the side effect of slightly lowering memory (1 transform) and slightly lowering
CPU costs of physics grips (less transform logic and checks) as well as greatly improving the
flexibility of the physics grips.
Added grippable actors to the grippables prefabs.
Lets you change out the root component at will to use skeletal or static mesh components.
is useful for making a base class and changing out the type of root component further down.
It was always possible to do in BP, but makes it easier by pre-defining it.
I suggest using the plugins OptionalRep(Static/Skeletal)MeshComponents as the roots
as they implement the optional movement replication and you will be missing the
StaticMeshComponentReplicatesMovement option that StaticMeshActor adds in.
Hi ,
Hoping you might be able to point me in the right direction in tracking down a bug.
So I set up the 4 way base station with my vive pro’s via page:
http://holocafe.de/en/blog/posts/how…-base-stations
Everything works with my setup in 4 way until I launch the game with the trackers turned on, which causes the crash.
The crash seems to be a null pointer issue.
The issue seems to be specifically with using the 4 way lighthouse tracking setup and the 2.0 htc trackers and the template. Maybe openVR, grip motion controller component, or something else.
To narrow down the issue:
-I tried your latest template, and it has the same crash so it isn’t isolated to my setup.
-I checked the default steamVR space which does show the trackers moving around so they do seem to work in 4 way lighthouse setup within steam itself.
-The 2.0 trackers have been working in a 2 way lighthouse setup so no issues there.
I realize I’m probably out on a limb here with the 4 way tracking setup, but I’d like to try and isolate the issue and continue to push forward with my tracking setup with the much needed robust tracking. I’m trying to move into using C++ more often,and hoping since you know the code, you might be able to point me in the right direction in terms of where to put breakpoints or what else to try to isolate further on the issue.