Move and scale the pawn
4.18 Preview 1 beta branch is up on the main repository.
I am compiling all binaries for 4.17.2 and will edit post when the pre-packaged binaries are up for it.
Edit Pre-packaged binaries for 4.17.2 are up
Yes, I was working off an older project which used 4.15. Like you said, the newer 4.16+ projects did have replication, but I hadn’t used them in a while and had forgotten.
It turns out 4.15 already has the teleportation controllers replicated, but not the activate teleport notifications. I translated your replication code from 4.16 into the 4.15 pawn, removed an ‘IsLocal’ branch and it now works perfectly.
Thank you for the help 
Yeah thats an editor issue, I don’t remember what causes it,. you’ll want to check answerhub…
[RIGHT]طراحی سايت](http://www.novinwebsite.com)[/RIGHT]
Thank you for the help
Yeah, blueprints aren’t very mergable so I can’t really port down changes to older versions. That is why I keep the reference template always on the very latest (non preview) engine version.
Hey ,
I recently updated to 4.17, and noticed that the “optional waist tracking parent” seems to have stopped working for VRCharacter’s parent relative attachment. I can’t set the “tracked device” to a tracker anymore, and settings for that section don’t seem to have an effect. I was thinking it might be due to the temporary Grip Tracked Device component having been removed as epic supported the trackers in their component?
I’m not seeing that, its still attaching to a given component for me and the code is still the first branch ran so it overrides all other options when there is a waist parent.
Also the trackers aren’t removed in 4.17, they are deprecated for removal (I remove them in the 4.18 branch), that being said they might be broken in 4.17, I didn’t see the need to re-vamp them getting the correct device ID yet again since they are no longer useful.
Also I need to change how the waist tracking works soon (have a better solution) as well as merge the foot and snap turning into it. I have those slated for 4.18 as well.
I’ve got prob where grippable static mesh objects can’t be picked up at all unless a certain part of a hand sphere is barely clipping into it.
If the hand sphere completely covers the mesh, pickup doesn’t happen at all. If 50% of the hand sphere clips into it the mesh’ll just drop. It’s almost the opposite of the prob I had before with sockets.
(ss of required hand sphere location on the object in order to pick it up)
Any clues what could be wrong? I pmed a link to the project where the issue’s happening. I can pm the link to anyone who’s willing to help. I spent too much time trying to fix it but got nowhere.
I cloned a commit from about a week ago because I wanted to try the “use feet location” toggle so i might be on a version between 4.17, and 4.18. Anyway, sounds great for 4.18 plans. I’ll just wait for that.
I already responded to your PM yesterday…
You have a volume blueprint in your level that is taking up the entire spawn space and collides with the VR trace / overlap channel. So every time you go to pick something up it is hitting the volume around you instead of the object unless directly overlapping it. The reason your hand has to be there is because it forces the sphere to be the first trace hit.
Just fix the collision settings on your volume.
Edit Also for future reference, try adding a break point or print string after the GetClosestObject node to figure out what you are gripping, shouldn’t have been a long thing to debug.
There is no version “Between”, if you were on the 4.18 migration branch it wouldn’t compile for you at all.
I actually don’t think i’m going to change the tracking method in 4.18 after going over it yesterday, but adding the foot / snap turning to it should still be done.
Regardless the parenting works, you may be confusing the tracker no longer moving (staying at 0,0,0) with the parenting being broken? Just replace the old tracker with a motion controller or grip motion controller.
Maybe I’m just confused about how to use it then. I had grabbed commit 8a3ea61 of expansion plugin example from 09-20, which is where the “use feet location” was added, and I’m using the plugin in version from there. The “Tracked Device” field is set to None, and when I try to set it to something it gives me a list of component types, but “grip motion controller” and “motion controller” aren’t available types from in there. Changing other settings in there doesn’t stop capsule from following HMD/camera location.
Use the “SetTrackedParent” interface function for the component, not being able to select subcomponents of the same actor in a uproperty pointer is an engine quirk (flaw?), a setter function gets around that.
I also just did the updates for it today and went ahead and merged them into 4.17 as well, so there is that.
Great plugin!
Currently looking into the template and just got a question. The VRLever component settings only allows rotation in X OR Y axis. Is there a way to allow rotation in both X and Y (like a control stick in a cockpit)?
I tried to work around by using the engine default physics constrain however I can’t seem to fix the constrain to the parent when the parent (a vehicle) starts to move in the world.
Thanks.
Its one of the things I was considering to add to the VRLever, however I hadn’t bothered yet because, as you already tried, my first inclination would be to use a physics lever for that.
To fix the parenting issue when moving, you either need to attach it to the vehicle with the constraint, or have it constrained to a non simulating component inside of the vehicle which follows along by itself.
i’ll note that its on my feature list for the non physics lever currently, just waylaid behind other things.
Edit I’ll move it up on my TODO list, if I get time today I might take a crack at it.
Thank you very much. I have tried to attach a grippable static mesh (lever) to the sedan in the template and attached both the lever and a physics constrain to a scene component that is not simulating physics. However, the lever would fly away once I start the car while holding the new lever.
It didn’t happen today, but I’ll get to it tomorrow
Thanks a lot for the help. Actually I tried seeing what was hitting it in Get Nearest Overlapping Object before posting. I never saw that volume get hit, though; maybe my hand position was off somehow, because it kept returning a GSM.
I removed the VR Trace on the volume and was still seeing the issue, but time I was getting the my mesh Menu (3d widget actor) in Nearest overlapped object. Turning off collision on the Widget Component, of the 3d widget actor, fixed the issue. In the end, collision settings was the problem. I never imagined that huge volume would be involved.
Thanks a ton for the help!
Has anyone noticed UE4 editor slowing down quicker than it used to (in 4.14, 4.15) when keeping Vive_Character BPs open for a while?
Whenever I open my Character BP that’s based on the Default_Vive_Pawn, performance degrades rapidly. After keeping it open for about 15 minutes, adding a single var, or just opening a new tab takes upwards of 10-30 seconds or more - even with only the Event Graph tab open in it, and no other floating windows open in the editor. (Also, I still got about 6gb of free ram left at that point)
That would be very helpful! Thank you very much in advance:D