Probably a simple question, but I’ve spent a bit of time on it already, so i’ll just ask. I was attempting to rebase my character to use VRCharacter rather than SimpleVRCharacter, and everything seems working after re-base, but I can no longer use a setWorldLocationAndRotation to set the character to be located where the HMD is in room scale on begin play. When I do that it seems the world is offset strangely from where it should be. My origin in game is not where the origin should be. I see I can get a VRLocation, but can’t set it. What’s the proper way to set the character world location with VRCharacter? I just need to set it to where the HMD is for begin play, and as a function to return to room scale positioning when needed.
Edit: Figured out that if I just remove the setWorldLocationAndRotation I was doing with SimpleCharacter based version, it is already in correct room scale position for VRCharacter based version. I still have the question of how I would get back to room scale position after using the movement controls with VRCharacter. setWorldLocationAndRotation is causing the world to be in a weird position so seems that’s not the right way.
Also, doesn’t look good after re-base. The VRMovementComponent seems to have lost its reference:
Would you know what might be causing that? If not, maybe I just need to update my character blueprint to have the latest and greatest from the example template at point. My blueprint work has been done on top of the SimpleVRCharacter from last December. Everything else seems to be working besides not knowing how to get back to room scale and VRMovementComponent reference though.
Add the camera location to the actor location and set it there, or if begin play is too early for that (it likely is) then you can get the HMD’s location directly with the node for that and then offset the actor.
For rotation you need to use ControlRotation unless you uncheck (bUseControlRotation) on the character. There is a rotate in place example in the nodes for the characters that gives rotation around HMD workflow as well.
As an alternative, look at the DoTeleport section, it adjusts by the HMD to place the character.
Thank you so much for sharing your work on VR plugin. You have enabled me to work on a prototype called Weaponmaster, where I am creating a medieval wave based game where the player can spawn various weapons depending on where they grab on their character. I wanted to go for a different approach than the Robo Recall inventory kind of approach, where the player more learns by memory and experimentation how to grab their torso to spawn different things (ie; grab behind them with their hands far enough apart to spawn a giant hammer, grab at their chest to spawn a quick shuriken).
In case it helps my fellow fans of your plugin, I’ve shared how I am doing that by overriding the gripOrDrop function and intercepting the nearest found object based on its name, then spawning an object and gripping it at an exact orientation (so things like throwing axes are gripped at the proper area).
I have a help question as well if you can spare the time:
I have followed your VRPluginTemplate and noticed when I pick up objects using the template the teleport and navigation commands are still active.
I exported the VRExpansion classes to my own project, and then re-added the GameplayTags so I could define grip properties on objects, but when using my own objects with the GripInterface or using objects like the BaseGun, I am not able to teleport while moving them.
One other small question–I have experimented with adding socket grips but when I tried with the axe I get a funny bug–if my character grips the axe on its socket, it becomes super tiny in their hand. Is because the scale I have set to 4?
For the teleport location trace I have a custom trace channel, it likely reverted to a standard trace channel when migrated to your own project and the trace is colliding with what you are holding.
For gripping at slots, how old is your build? I went in a few updates ago and updated the FindSlotInRange expansion library function to force the returned Scale3D to be 1.0f. is because the sockets
were inheriting their parents scale instead of using their own and that was causing the Relative transform to the object to be incorrect after converting (Relative transform of 4.0 scale to 4.0 scale is 1.0 scale, with method it retains the 4.0 scale).
I could technically return a relative position instead from the socket getting function but its more flexible keeping it world based.
If you load up the current template and set the gun scale to 4.0 it should work as you intended, if you don’t want to update yet you could force the return transform to be 1.0 scale or the relative transform to be the actors scale instead as a temp work around.
For climbing I’ve never had “two handed” setup in the template, is due to wanting it to feel as natural as possible. To do a two handed climbing setup you will have to detach the hand/controller mesh during the climbing move so that they stay in the same location and also change how it does the climbing movement vector to be an average of the two hands instead.
Its not actually possible to have it 1:1 with two hands since you are floating them in midair, so you lose some sense of presence, I prefer the one handed perfect 1:1 method. You can feel free to make it two handed for yourself, it would just be removing the climbing drop from the active hand and changing what vector it passes in to the plugin.
For step up, you bring the hand down to your ankles, the height is configurable, since by default collision is enabled while climbing in the template you can’t just pass through and up on to objects. You can disable collision while climbing or increase the step up height to something easier to reach if you want.
Whoot, so some new VR commits hit the master branch last night and they are really **** nice, will likely cause some plugin changes come 4.17 (for the better).
They are directly implementing tracker support finally, so I can drop the special controller for trackers.
Right / Left hand steamVR presets appear to be obeyed in engine now
OpenVR mesh loading is going to be supported in engine, and at the sub component level (something I hadn’t gotten around to yet), so I will likely drop the functions related to that from the plugin.
Fully customizable mirror window settings with included custom texture overlays are supported (async gameplay / custom mirrors / mixed reality support).
A mixed reality camera tracking system is added.
Oh, and new input bindings that are more generic / should support the Knuckles controllers.
I thought it might be related to late update being on, but the issue happens whether late updates are always off or on. I checked the collision on the mesh and it doesn’t look like it’s blocking anything.
You need to up the stiffness on the constraint, the value you are using is not strong enough to overcome the sudden direction changes.
Or alternatively you can use one of the hybrid grip methods.
That being said I am not entirely sure WHY you are gripping that with a simulating grip, it appears to be something that you could simply use a PhysicsOnly grip on so that it doesn’t have a constraint?
「That being said I am not entirely sure WHY you are gripping that with a simulating grip, it appears to be something that you could simply use a PhysicsOnly grip on so that it doesn’t have a constraint? 」
You’re right. There’s no good reason for me to have it simulating. Sorry, I didn’t read all the documentation correctly. I didn’t know that PhysicsOnly grips don’t simulate. Changing it to that fixed it perfectly. Also, now I know large numbers are required to effect change on constraints.
Thanks again!
Btw, I showed stuff to some co-workers here (at a game company I work for) in Japan and they loved the climbing bit more than anything. (I gave all props to you, of course.)
Only complaints were
①it’s hard to hop up over ledges
(I’m pretty sure I just need to change the VRClimbing StepHeight and maybe the multiplier to fix)
②Can only climb grab if hand is near surface of object (even the default white blocks). Other than increasing the size of the sphere I’m not really sure how to fix .
Regardless, both of these issues are not the fault of the plugin, just my usage of it.
After climbing, one of the higher-ups thought it’d be cool to be able to cast webs and swing like spiderman. In the docs, if I recall correctly, you said the climbing mode could be used for kind of more custom movement mode, but I wonder how you’d get pendulum/swinging physics to work right with that climbing mode. Have you already mucked with kind of thing?
I cant open any Blueprints after the instalation of the plugin do i have to code everything now in c ++? or do the blueprints still work but i have some other issue? sorry i m almost completely new to c++ or blueprints… EDIT: oookay nevermind now it suddely works…
Yeah change the step height, the default value in the template is pretty low (far lower for tall people or people that have issues leaning over a lot, its mid shin to lower shin height for me). It wouldn’t be that difficult to calculate a step height off of someones height during an initialization period at startup as well.
Edit As of the last update btw the multiplier is pretty much deprecated as I am running custom capsule step up collision for climbing step up now that should ensure it is easier.
Default white blocks you can stick your hand inside of and climb still, the climbing and gripping checks first run a trace the size of the sphere (traces are more accurate than overlaps with fast movements) and if that trace fails it falls back to checking for overlap (if inside of an object the trace will fail so overlap is used). The problem with the non white walls is that BSP does not trigger overlap inside of it so climbing is surface contact only. Its not the largest problem because you shouldn’t be using BSP for levels in the first place and collision volumes could be used around it even if you did.
If you wanted a more lenient climb detection you could bring the climb check out of the grip check code and instead check against the hand mesh or a larger collision sphere.
There is…um…a very unfinished grappling gun in the plugin template hidden away in a sub folder that I have never talked about. I got side tracked when 4.16 came out doing all of the updates and left it unfinished, but it works like spidermans web shooter. That being said how it functions is overly complicated (adding forces to the character directly during falling movement), it would be a lot easier to simulate the same effect in climbing mode by adding the force of gravity + a radial input to movement. I just wanted to play around with a full force based implementation.
What is the best way to look over ledges? Since the capsule tries to prevent your head from going through walls, it pushes you back. That part is good, but is there a way we could allow for knee height ledges that could be peered over?
Walking collision override or inset collision volumes, or not having them collide at all. Inset collision has the most over all control of those options as you can strictly define the distance / depth of overlap but retain all of the normal character features.
The only true to life method is using a waist tracker, because faking it with allowing “some” overlap just lets people walk through for that amount and doesn’t force a “lean” and also somewhat breaks the methodology of how characters work.
You are free to implement it outside of those 4 options yourself with overlap on a non pawn colliding object and teleporting back if the overlap is too far of course.
Got it. I’ll update to the latest. Are any BP changes necessary for the custom capsule step up collision to go into effect? Or is it all under the hood?
Actually, I can’t. I know a couple people have talked about same issue in the past, and you told them how to fix it for BSP. Since I refactored all the checks and stuff to work with the equipment items I made, and how they’re interacted with, I likely messed up the overlap fallback. Thanks! I’ll make sure that is properly set up.
I remember seeing some references to the grapple gun (either in thread or in the template project), I just never made the connection to swinging… Thanks, I’ll check it out and then see about doing the simpler “adding the force of gravity + a radial input”. I was thinking trigger to shoot and hold web, grip to reel in (double-tap grip to reel out).
I wonder if there are any forms of locomotion you haven’t implemented…
