Just a reminder that you wanted to expose “Set Crouched Half Height” as has not been implemented by Epic. Thanks!
Done, smallest commit yet
The low gravity mode feels amazing. Thanks again for making so accessible!
Let me know if you run into any issues with it, it was a very quick and basic conversion of flying movement to get it going.
Pushed a new commit to the plugin, is a few days worth of changes and sadly will cause c++ users to make a change (GripInterface has a new function).
I intend to leave it as is for awhile for bug fixes with movements and grips due to some sweeping changes made here, during down time from the major
systems I will likely be converting the interactible components from blueprint to c++ and making them cleaner (the button already saw considerable cleanup
recently in blueprint).
Post the interactibles conversion I would like to get to some of the feature requests. The Force constraint setting was actually a feature request, I implemented it first
due to being close to another one of my wishlist items already.
Plugin changes
Added advanced physics settings for the interface, by default they are turned off
however when turned on they can be used to change constraint settings beyond the normal
acceleration based with stiffness/damping for angular being auto calculated.
One use would be to change it from an Acceleration based constraint to a force based one.
would create better behavior with manipulation grips in some scenarios as well
as offer a method of delayed / weight simulated grips (would likely need the custom
angular stiffness and damping set then as force values for these are far higher than
acceleration values).
I have plans to add more features to the advanced settings in the future. When deactivated the
additional grip property costs 1 bit to replicate. When activated the replication cost
is dependent on what in it has been enabled.
I have been wanting to expose the physics settings more to the user and is probably the best
way to do it (Like auto center of mass setting on grip). I would love to merge the normal stiffness and
damping into the same structure but it would break many projects so it may never happen.
C++ Actors/Components using the interface will need to implement the new getting function
for the advanced physics settings (if ever merged it would replace the separate stiffness
and damping functions instead).
Now using a nearly check for better precision safety when checking for replicated changes for
stiffness and damping.
Added optional angular stiffness / damping setting to the SetGripConstraint blueprint function
Added visual and editable indicators to grip interface settings that are controlled by a boolean
(IsInteractible / UseAdvancedPhysicsSettings). To make it easier to work with them.
Made some WalkingCollision override changes to be more reliable and consistent as well as use
more custom logic and less hackish workarounds. Will need feedback on how it behaves now.
New ClimbingStepUp fixes (for VR Char only ATM) appear to help a ton with
step up issues. Adds a configurable variable to the StepUp settings that sets a seperate
threshold for when a capsule is considered within stepup range making it significantly harder
to accidentally fall back off backwards when stepping up. Should not be increased beyond the radius
of the capsule (is noted as such on the variable comment).
Hello,
(I’m running a version of the plugin from a couple weeks ago.) I opted to convert all of my user equippable items into grippable skeletal/static meshes so to retain all those checks and balances implemented.
tl;dr
2 Questions:
① Is it OK to consolidate the Grip Enum (Hand_State_Left/Right) with my custom one? Afaik, it looks like that Enum is only used for the Hand Blendspace1D.
② I want to change the gripping controls such that climbing is enabled when pressing triggers while hands are Empty, and those special Equipment Grip Interface objects I made are equipped/Unequipped by pressing Thumpad face button 1/3 (respectively). In order to accomplish , would it be best to do separate grip checks (each of which are modified checks based on all the logic in the GripOrDrop flow) for all of those buttons? (Once an item is equipped, I have that actor do all the trigger_value and grip pressed checks in order to execute item-specific behavior)
Currently, gripping/ungripping in the Vive_Pawn is based (solely?) on the triggers. I want to change those gripping controls a bit without getting rid of those C&Bs, but I’m a bit lost on how I should go about it.
My VR_char has 4 things parented to holsters on different parts of the body (RR-style).
I want to accomplish the following 3 things, but I’m afraid I’ll mess up the current Checks that are already in place.
①Enable gripping&climbing only if Trigger is pressed while hand is Open.
( works perfectly currently, using the default grip logic, but it conflicts/overlaps with the 2 things I want to do below)
②Equip holstered item if Face Button 1 is pressed & Hand_State is Open & Grab Sphere collision is overlapping & Item_Type == Empty.
lerp its pos/rot back to the calling hand’s socket, set Hand_State is Grab & Hand Item_Type = <itemtype>
③Unequip item if Face Button 3 is pressed & Hand_State is Grab & Hand Item_Type != Empty
Then lerp its position back to its holster, set Hand_State is Open & Hand Item_Type = Empty
(The reason why I want equip/unequip on the thumbpad is so I can use the trigger and grips for item-specific actions when an item is equipped.)
I gave each Equippable item an Equipment interface that just monitors its respective Equipment’s Holster position/ID and sets the respective hand Item_Type; is so I can play item-specific grab animations)
First two answered in the quote above, rest below.
I set up the button mappings in the input settings, you can feel free to change what goes to them, or directly link new logic instead. You won’t be able to do anything super custom with the template without deleting and refactoring a bit, its just the nature of the beast. Even if I consolidate every little bit of the logic into functions that you can just call from subclassed characters there will still be instances where its not going to work with something special you are doing, the template isn’t gospel, it is supposed to be an example of how to set up things, there is a lot in it that you can likely remove and the gripping logic is based around just pick/place/use interactions.
If you have really custom button mapping that you wish to use then you’ll want to copy the VRCharacter and work off of the copy instead of the original or a subclass. Then you can delete and rework as you wish without losing your references, it will also let you compare with future examples.
Thank you for all the info and sorry for the long post.
The Try to Grab Object function’s got Drop Object and Grip Object funcs. If those funcs take care of the unparenting/parenting of objects and Gripped Actors array, along with some other magic, wouldn’t that mean I have to/should use them any time I drop/pickup an object; otherwise that’d basically defeat the purpose of me making them grippable? I was thinking I could just call drop object w/ Simulate unchecked before doing a custom function that returns the Object to the holster. Just want to make sure if that is one, not so bad, way to do it.
On a side, I just now found out that the BitBucket vrexpplugin url changed (used to be “vrexpplugin”, now it’s “vrexpansionplugin”). affects the Specific Commit walkthrough a little bit.
<anyone>
I followed the Update Plugin instructions (Safe Method version) gave a while back (on Page 25). fsr, the .uproject won’t generate new project files (.sln). Anyone else seeing problem? Running 4.16.1 and trying to update current with Master VRExpPlugin as of a couple minutes ago.
Edit: Nevermind, I figured out that deleting Advanced Sessions was the cause of the .sln not getting generated.
Yeah you should use those if you want to grip/drop an object with the plugin (have it in the array and replicated). For traditional grips like parenting you don’t have to use them.
GripObjectByInterface()/DropObjectByInterface() will grip/drop an object and auto fill in its grip settings by querying the interface.
As for the name, it shouldn’t have ever been the shorthand, are you sure you weren’t working off of a branch that you made? Regardless I corrected it in the setup tutorial.
Got it, thanks.
Shoot sorry, is all my bad. I got the right screenshot for the plugin url, but for the copy-pasteable url I copied the url for the template and removed “template” from it, wrongfully assuming it was the only difference.
When updating the plugin, should we not delete the Advanced Sessions folder?
The template depends on that folder for the server browser, so no I wouldn’t delete it. You can manually remove it by editing the .uproject file and then delete the server browser object if you really want to.
First off, thanks for making the plugin! It’s extremely useful. I’ve been trying to get the VR replication to work for ages and is perfect.
Quick question, do you need anything further to get the multiplayer working? I sent a copy of the template (with a few minor changes) to my friend, but we haven’t been able to find each other. We start SteamVR, open the project in the editor, host a server, and try to search for each other. So far, no luck. We’ve been able to connect using the Advanced Sessions plugin on a different project in the past, though. Not sure why we can’t connect here…any ideas?
SteamVR Home currently breaks the steam subsystem in UE4, you’ll have to disable home currently in order to find servers (the subsystem will literally not load with home active).
Little overview of how to use the new VRButton c++ class.
…not used to using a single screen in ue4, i forget to switch windows a lot, don’t mind it.
Hmm, that wasn’t it. We both opted out of the SteamVR Home Beta in the SteamVR settings and still couldn’t find each other. Do both of us need VS2017 for 4.16 to work properly?
Oh sorry I missed you saying that you were running it in editor. That won’t work, you need I package the project and send that to him. Steam doesn’t load in editor previews aside from standalone and even if it did, it would technically still be different builds and autofiltered by epics subsystem.
Ah! Alright, I was hoping it would work without packaging the whole project. I’ll try that tonight.
Thanks for the help!
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.
Pushed small update to the plugin to fix a few VRButtonComponent issues and update the sessions plugin in the template to the newest version.
Hi ,
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?