I love the plugin, and it has worked wonders for the game I’m working on, but I’ve run into a slight issue I was hoping somebody could help with.
I am working on a vr weapon system, and currently I’m trying to implement shotgun mechanics, but I’m having some trouble with the secondary grip. For other weapon types, I’ve simply made the bolt a grippable box with a static mesh child, then scripted whatever interactions I need.
For the shotgun, however, I need the pump to work as the secondary grip point on the gun, as well as have it work as a constrained interactable for the weapon mechanics.
Is it possible to make a child component’s grip act as the secondary grip on the weapon, or to make the weapon’s secondary grip interactable?
Or am I simply approaching from the wrong angle?
I’d appreciate any help, as I’ve been stuck on for a bit and it’s the last thing standing in my way before my system is largely complete.
You can have the pump as an entirely seperate grip on its own to move it, or just track the location of the hand relative to the barrel and handle it yourself.
You don’t want to try and re-orient the actor to face the pumps location as that also effects the pumps position since it is a child component.
So if you don’t want to do any custom setup, easiest would be to add a another grip to the pump when the secondary grip is started, and remove it when the secondary grip is stopped. However I think you could get cleaner results by doing the pump logic manually off of the secondary grips current location and the sockets location to get barrel offset.
Okay, was the route that I was attempting to go, but it turns out I was accidentally referencing the wrong controller, so it wasn’t working. Oops.
So I sorted that, but I suck at vectors and math, so I’m having an issue, in that, whether or not it works properly is determined by the direction the weapon is facing. Clearly I’m approaching incorrectly.
If anyone could tell me what I’m doing wrong here, I’d appreciate the help.
Inverse transform the position to be local to the gun, you don’t want to do in world space, making it local to the gun gives you only the forward (X…Y for marketplace guns) axis to worry about.
Awesome, thank you so much. I figured I needed to do it in local space, but had no clue how to get the data to local space.
I have one last plugin related question if you wouldn’t mind.
I’ve got the movement working properly, and I only want it to move on Secondary Used. Which I’ve also got working. However, when I press secondary use, the the gun sort of rotates away from the secondary hand, then quickly corrects itself.
Is something you know of / something you know how to fix? It just jumps a bit every time I hit the use button.
Thanks again.
Edit: It seems like it’s releasing the secondary grip for a fraction of a second, and the weapon rotation is moving back towards the primary controller’s rotation, then snapping back to the secondary controller. I dunno if that helps anything.
Your secondary grip is releasing on SecondaryUsed? It shouldn’t be, OnUsed isn’t actually attached to anything in the plugin itself, its a helper function for you.
Are you sure you aren’t somehow running the secondary attachment code again on used?
Okay, so looking at it, it seems to have something to do with how I was attempting to use the gameplay tags. I basically disconnected all the code I had attached to the various functions and it was still happening.
Currently the setup I was trying to use was grip the secondary with trigger, then use trigger down for “on secondary used,” then trigger release for “on end secondary used .” I was using the grip for secondary drop. Basically, I wanted to keep grabbing consistent with the rest of the things in the game, but also thought that using grips may be awkward for moving the shotgun pump, so thought trigger would also be ideal for use.
It seems that having grip and use to the same button is causing it to release the grip for a moment then re-grab. It does work, however, if I use trigger for grab and drop and then simply use grip press and release for the use functions.
Edit:
Okay, so I tested on a fresh install of the template as well, to make sure it wasn’t something I specifically did in the mess of code I have. If you change the gameplay tags on gunbase to drop secondary with grip and to use secondary with trigger, it’ll do the twitch thing.
So I’m also finding that if I set the default gunbase values to:
Secondary Grip = side grip
Secondary Drop = side grip
Secondary Use = trigger
Secondary End Use = trigger release
Then it’s not allowing me to secondary grip with the side grips at all.
I cleared it back to default values as well, then set secondary grip and secondary drop to side grip and it doesn’t appear to be letting me secondary grip with the side grips at all. Dunno if all is helpful or if I’m simply missing something here.
Currently Drop is priority over use in the BP, arguably it should be the other way around. Regardless you shouldn’t have them on the same button anyway as if it is the other way around then you can’t drop secondary.
You can delete/add gameplay tags during runtime (the gunbase does on grip), to remove grip/drop on trigger and replace it with grip/drop on side grip (like it does when held at the handle for the primary grip).
As for the setup, yeah I found a missing check in the BP from when I converted everything to the cleaner gameplay tag checks. I fixed it and fixed a missing return in the DropOrUseSecondary function as well. The template repository is updated with the corrections.
Awesome, thanks for the feedback. I think it’ll be just fine now with the update and your advice. I’ll give it a look in a bit when I get home from work.
My wall of text was a bit confusing, but I had use and grab on the same button, but drop on another, because like you said, it would cause conflict / keep you from dropping altogether.
That’s why it was confusing me, as with the primary grip in gunbase, use and grip are both on trigger, so I figured I could do the same for secondary.
I did edit the gameplay tags in the actual gunbase event graph and was still having the issue.
Anway, thank you again for all the help.
EDIT:
Your update fixed the issue! No more twitching when secondary trigger is set to use. Thanks again!
I hope you don’t mind me asking a question. If is the wrong place to post question I apologize. I am new to Unreal and am trying to learn blueprint and I created a room with a light and and one of your button actors you included in your VR plugin. I come from a C# background so I am familiar with coding. I can get my light to turn on by changing the visibility of my light in the Event BeginPlay on my level blueprint so I know my light is good. However, when I try to use the Button Pressed Delegate Signature of the Button actor in my level blueprint and attach it to the Toggle Visibility it never fires. Even when placing a Breakpoint on the Button Pressed Delegate in the blueprint it never breaks. It obviously breaks if I put breakpoints in the Button Actor’s class, but the event never seems to get forwarded to the Level Blueprint. Is there more that I would need to do to get to work?
I also see you have some sort of electrical target array in which I assume you can set it to change multiple targets. I tried also adding Current state changed on my button actor instance inside my level blueprint but that does not seem to fire either.
Is there any example documentation on how should be wired up in blueprint?
You have to bind to the event of that specific button if it is remote, type in Assign or Bind in the context menu for the component reference. The green + event additions are only for Actor local context, they don’t work outside of the owning actor. The binding is for a second remote multicast delegate that I have alongside it that is also called and works with outside actors and blueprints ( as is engine best practices).
the confustion is understandable though, since selecting the reference still shows the big green assignment button, but it only creates a template event when out of local context.
Edit A note, originally the button on the mirror was a blueprint example, when I made C++ versions I deleted them all but left that one as an actor. You can literally just add a VRButtonComponent on any actor that you wish now.
After all time I’m still very excited about the plugin. Great work!
I’m now trying to get multiplayer working. For that I’d like to test multiplayer like you do here: First test of multiplayer in template - YouTube
I know how to switch to fps vive pawn. So I have one laptop with the fps vivepawn and one with the normal vive pawn.
Been searching thread but could’t find someone asking question unfortunately.
Just how do you start the server in the FPS vive pawn game? And can you play in editor or do you have to package the game first?
Default setup is over steam as its easier for multiple VR players to test with.
L button turns on laser beams for the FPS pawn and you can interact with the server menu to host / join. In game the app menu button on the vive pawn turns on the lasers for interacting with the menu (oculus is missing an equiv button in openVR because it is taken up for steam menu, so i need to rebind that key still for touch).
The actual session blueprints are in the 3DMenu, its not exactly the best place for them but I wanted people to be able to just delete that one actor and not have any assets tied to my session plugin anymore for the template.
You can’t play in editor currently because both instances that are spawned will be VR and even standalone can not find sessions as it can be a different build ID. Just packaged as Development since you don’t have to do anything special for that for testing.
Edit I will note, though I haven’t tested it in 2 steamVR updates the last I knew the SteamVR Home Beta being on takes context for the steam sessions and breaks the UE4 Steam Subsystem (won’t load). Unless directly running the exe from steam you’ll want to turn off the Home Beta if you can’t host/find over steam.
Great! It just works as in the video I can finally test if the things I created actually will work in multiplayer…
I did have to disable SteamVR Home beta, remap the laser beam to a different button because I’ve got the Oculus and create a new steam account for my laptop but now it works perfect.
I assume is 1 to 1 in comparison with a released game right?
Except for rare random differences with dedicated servers yes.
If you package shipped you need to also include an app_id.txt file in the .exe directory with your steam app ID in it.
Dev is nice for testing because you retain console and debug rendering.
Edit That being said, I tend to test new multiplayer things with two flat pawns in editor, and then package out to test specifically in VR at the end of the feature to ensure it works right. The core multiplayer work being done for my plugin I don’t need to re-test base things too often. is waaaaaaaaaay faster iteration and retains easy debuggability and easier profiling.
Pushed a few commits the past week, just collating them here.
Plugin
Fixed VR Lever not responding when of an axis is 0.0f
Corrected a replication issue with client authoritive grips where
since I don't replicate some variables when the secondary grip is being sent as removed
the server would lerp incorrectly back to base position.
Improved the Parent Relative attachments behavior when lerping with yaw tolerance
Changed the additive transform for grips so that it applies seperately from the secondary grip rotation.
stops the addition rotation from being overidden by a secondary grip.
Template
Fixed some bad logic in the Vive_PawnCharacter that kept secondary grips from behaving correctly sometimes.
Here is a little present for the awesome VRExpansionPlugin.
I came across another problem where I wanted to use the VRLeverComponent for and I decided to work again on it to make it rotate smoothly over the flip point. It is in a state now that I thought the VRExpansion Plugin could also make use of it, so I took my freedom to send it to you.
Below you find attached a 4.18 version of the example project just like in the video. The code additions in VRLeverComponent should just work fine also in 4.19 from what I saw. I marked every code change necessary with the comment “spaceharry” in h. and cpp file. Feel free to also use the mesh from my video in your example project.
Edit: The files here didnt have the correct version. You can find them below or later in a new version of the ExpansionPlugin soon.
Basically the lever rotation limited to yaw and pitch now works like kind of telescope and it behaves almost like it when moved by motion controller.
As of now there are two variable exposed to blueprint to take ajustments on: FlipZone and LerpOutSpeed.
FlipZone defines a zone on a sphere near where the lever would flip around its roll axis or small location changes from the motion controller would cause swirling rotational motions. As of now inside zone the lever can only increase or decrease in pitch to avoid those problems. FlipZone value can be increased to further stabilize swirlmotion or decreased to allow more yaw rotation before locking in.
LerpOutSpeed is just for lerping back to “real” motion controller location after leaving the flipzone.
I didnt need to limit the rotations axis as of now, but I surely will take a look at it. Also currently lever doesnt return to its initial position. implementation is not perfect in any sense, but still I thought that someone could use a light projector on the stair platform.
I’ll look into it, there are obviously still some rotational accumulation issues with it and some drifting, but that is to be expected with what is basically a corrected lookat. It has a pretty nasty singularity where it flips continuously trying to account for the last position over and over (don’t let go of the lever like in the video, keep sweeping it around without letting go).
I wouldn’t be adding it to the XY one though like you did, I don’t want that mode to act in that manner, but it would be a good fit for XZ assuming the singularity and drift can be accounted for.
I can finally test if the things I created actually will work in multiplayer…
