No, slots have nothing to do with it, they are just stored relative transforms that get decomposed and passed in to the plugin. You just need to make sure that the relative transform being used for the slot calculation is relative to the bone, and not to the mesh itself, that may be an oversite in the BP side of the template ( need to check) as I never specifically tested slots on per bone gripping. Should be easy enough to override and I could modify it in 4.25+ to handle it correctly.
You passing out a neck bone name as the slot just makes it use the location of that bone as the slot.
Slots have no logical effect on the gripping in the plugin (outside of a true/false in the melee script), they are a construct on the users end. The optional snap socket is a helper utility that I actually tend to suggest that people not use in favor of manually passing it in, as its more fully controlled on the users end when they pass it in.
Edit
Yeah it just needed a couple of node changes:
The template guns default behavior is to auto switch hands if the is no secondary slot in range when gripping with another hand, sounds like your secondary socket is out of the range setting for secondary hands when you go to grip it.
I don’t THINK that’s what’s happening – should have mentioned that it appears to grip the secondary properly, just that it simultaneously drops the primary.
Made a quick video
(You can see I tested the Secondary slot range settings to make sure it wasn’t that)
Secondary attachments are not full grips, they are modifiers to the primary grip, so it can’t actually exist without the primary grip still being active.
That being said the template gun does have the option of gripping the front fully when the rear releases, but that shouldn’t be what is going on in your video, that should be the hands swapping.
The default gun doesn’t use the “multi grip” settings where both hands get full grips at once.
I duplicated one of the other BP children that worked, rebuilt it from there and it works.
I compared the two BPs (new working vs non working) and can’t see any difference, so I’m not sure what I did wrong the first time around.
Thanks again
The hands are the exact same as the physical hands in the example. and even when the button is disconnected from the action I want, it seems to happen when the button bottoms out and the collision on the hand continues into the button. I’ll post a video as soon as I can on the issue.
Hi again,
i have a question concerning multiplayer testing. I am trying to find a way so that i can test multiplayer stuff from within the editor and so that one editor instance uses the HMD while the second instance uses the FPS pawn. Currently - using the template as a starting point - when i choose VR preview in editor and then start a 2-player / listen-server setup both instances seem to spawn the HMD pawn. So i tried to force one of the instances (e.g. the server one) into always using the HMD while the other is forced to use the FPS pawn. Currently i am trying to use the Steam_VR_Player_Controller for that. I am trying to hook into spot:
So one thing i tried was to use the isServer node so that i would branch of to the FPS pawn in case isServer was true. However no matter what i do the result is either both instances running the FPS pawn or both instances running the HMD pawn. Would it be possible to achieve what i want anyways? Is the right spot to look into? Any hints are greatly appreciated.
Cheers
Thanks for answering. Tested again based on the latest commit code. However, if you grip a bone outside the slot range, it will not work properly. And even when the bone slot grip is executed, there are times when the slot transform cannot be found properly. Did it work well when tested?
I think the approximate cause is known. The lower socket of neck_01 is found, but the nearest bone name may be head or spine_03 depending on the slot range. There are cases where the parent transform, which is the standard, is incorrectly set.
Hello , I’m running into an issue with climbing while in multiplayer. If you set PlayNetMode to PlayAsClient and turn on EnableNetworkEmulation, then climb on a surface and pull yourself into the wall, the player position begins to wig out (technical term), then you end up somewhere really far away. I’ve even seen it crash Unreal. Any thoughts?
Yeah really the socket needs to be chosen by bone, which is outside of the scope of the interface function itself.
You may want to insert a query there for your own closest socket check with some custom filters.
That or in the GetClosestSocketInRange query add a prefix of the bone name and be sure to name your sockets with the bone names prefix (IE: UpperArm_RGrip1), ect. That way it will only find sockets on the given bone, you can also override the GetClosestSocketInRange function on your grippable skeletal mesh itself and hard code specific sockets based on the passed in bone name prefix that way as well.
Either way should work for you, its just not a case that the template is meant to cover so you need to make some tweaks.
The Override Prefix field, could just straight pass the bone name into it where the node is called. If a bone isn’t being used it would just use the normal prefixes anyway, if one is being used though you can use the per bone prefixes or manually choose.
I managed to get the desired result by modifying GetBoneTransform. I felt it while making it, but if there is an example actor in the template for the solution for bone grip, it would be very helpful to other plugin users as well.
Looks like the packet loss setting is being pretty egregious, I had some packet loss mitigation for climbing but its not working correctly now, i’ll look into it. There are a lot of people using climbing in networked games currently, that severe of packet loss is fairly uncommon, i’ll figure out the cause of it doing that suddenly though, there have been a few network prediction changes in every recent engine version that may have interfered.
Mmm, that is actually the hardest solution here, the prefix modification would have been a lot easier for you.
I’ll add the bone prefix officially into the template and give an example manniquin. Adding the bone input to get closest would also work but its such a niche case that I think is better as it doesn’t require changing the interface function.
Try updating to the latest patch that I just put out for 4.24+
I had to makes some changes due to how the movement modes are handled now, but it should resolve your warping issue during climbing when packet loss is happening.
Hey , I’m looking for ways to smooth the motion controller inputs as a way to give more precise control while making controls a little less responsive, like they did with the game Onward with the scope smoothing, but I have absolutely no clue how they implemented that, I’m looking for clues on how about going to do or if you plan something for kind of recurring issue, thanks you in advance and if you reply make sure you mention me so I get a notification
There are multiple methods, I have two of them in the guntools grip script if you wanted to look at that. I have a few users using some naive frame to frame lerping in grip scripts as well for some smoothing.
OK so the start\stop network voice works but only one sided, the other guys in game can hear me but when they try to talk i cant hear them, its not a server\client issue because even when we restart the game and one of them hosts the game everyone can still hear me (i am the client now) but i cant hear any of them and they cant hear each other.
I’m thinking maybe is a network speed issue, as i have the fastest internet of the bunch (fiber optics with 100 MB upload and 1 GB down), is there a way to set the network voice bandwidth higher? let it work on slower connections?
before you ask, yes all the .ini file configurations are set up.
first, love your plugin, it is a fantastic amount of work and really helpful.
I was hoping you could help me figure out a problem I am having deploying to Oculus Quest with UE 4.25.3 and the current master branch of VR Expansion.
I upgraded a project from 4.24 to 4.25 and everything works fine locally via Oculus Link on PC, however, when packaged to launch on the Quest I get a black screen.
I have packaged and run a fresh project using the VR template, which is working fine with the same project settings. Adding the VR Expansion plugin and building results in the black screen again, when I remove the VR Expansion plugin the project runs on Quest as expected.
Is there any special combination of SDK/NDK known to work with 4.25.3?
Unfortuately I don’t get any logcat output when happens, as though the program is frozen at startup, so I’m at a loss as to exactly what might be causing .
