VR Expansion Plugin

[mordentral]

quick question about your addition transform example in the template. it was written in c++ so im not as familiar with deciphering it. how are you moving the gun around. i wanted to try a physicalised approach to recoil by applying force. so that i could work towards a more simulation feeling but im getting strange results with add impulse or torque nodes.

Add Impulse and torque will have some issues because you are pulling / pushing against the constraint, so it won't be flying straight back for instance since the constraint location will be closer to the handle, this is actually correct behavior, but you'll be hard pressed to get it really clean compared to a logical approach.

As for the addition transform, it is a base transform that is applied to prior to the wanted grip transform calculation, so it adds an offset to the final position / rotation that is passed out for the object to attempt to move towards.

If you DID want add force you would have to apply it after all grip movement and likely would want to total it up yourself, because each tick the grip is going to be attempting to re-orient itself to where it should be.

[Starkium]

As the Weapon Master VR Dev, I would like to comment on this; the reason I did things the way I did is 1.) I am not yet comfortable with interfaces coming from an inheritance background and 2.) I didn't want to "Copy" anyone's logic and get in trouble (really worried about this all the time). I assume for me to do what you wish I would have to make all of the events that pass on to the weapons generic and in identical to yours? What about variables passed through that you don't current pass with your grip logic? I am actually looking at changing to interfaces when we do our multiplayer update (version 2.0) later this year. When we get around to that would you be willing to help test the integration? I may even look into it for version 1.2 (1.1 is too close to being finished and released to go back to the drawing board).

I have mentioned in our thread that the best (current) way to combine Weapon Master and this plugin is to uses this plugins locomotion and our grab/weapon logic. I would like to make it clear that we have NOT integrated The OpenVR Expansion Plugin into our internal Weapon Master builds yet. Its something I really want to do but with about 20 features currently on the list of things to add, I simply haven't had time.

Thats said our actual game will be an amalgamation of WMVR and OVREP. Your locomotion is just far superior to ours due to the hoops we had to go through just to implement the stuff we wanted through blueprint (Yay c++).


I think my biggest worry is to "step on your toes" in some way but if peeps really want it I am willing to make big changes to what we have to make it better. Including your idea for generic interfaces.

This is from a while ago now, but I had the thought of instead of interfaces, you could make the WM interactions into a component you could attach to any hand blueprint. This way there is no need to replace the hand BP in VRE. You might still need an interface, not 100% how this would work, but this would eliminate the need to replace a bunch of stuff when using the two.

Also, I feel the inventory should be a separate thing as well. You shouldn't need the inventory in order to pick up a gun and use it. You could probably move the whole bullet inventory to like a "pouch actor" or something. Holsters are already separate actors so that's convenient, buuuut if I remember correctly there are dependencies for them. Summary, everything should be modular.

Does anyone else have thoughts on this?

[Starkium]

Got a little sidetracked today.....

Car works off of original character now though.

Now drifting would be a sick little add-on to that

[mordentral]

OMG please someone answer that question, i'm with the same doubt! I'm doing a project for my College(here in Brazil) and really wanna know how I get the pawn with only teleport as the mobility option. I really wanna use this plugin because it fits so perfectly on my project...

This plugin is insane! If there was something like that guy said, like noob friendly reading material for people that are trying to create things for Enterprise would be very nice!

Thank you so much!

The example template is showing off a bunch of different movement modes that can be achieved, they aren't hard coded into the plugin itself. You can set the Left / Right hand movement mode enum to a value and disconnect the switching event if you want to hard lock a set mode in place. I wouldn't really suggest that people base projects off of the template content, but to rather use it as a reference, however most appear to be ignoring my suggestions there.



In general to others:

Hello Hivemind!

What a fantastic plugin! Very nice work! Im not at all into making blueprints and not a at all into coding, but one of those visual designer types learning UE4 and VR, so im struggling a bit understanding how to use the different pawns. I have a project where i know I only need teleport (simple) and the grab objects, like the drawers and the potion bottle. (from the the demo project) I dont need climb and the other things.

how do i configure the pawn only to use those and not having everything avaliable via the grip menu? I have been trying to learn from the wiki and videos but im so very confused right now.

I wonder if anyone could point me in the direction of some noob friendly reading material or videos?

I got the project up and running and compiled.

Thank you in advance!

MJJ

I started some wiki documentation for basic grips today, but its fairly hard to make anything really baseline. I intentionally leave the implementation of the movement and gripping (control) logic up to the end user, this is so that there is nothing preventing them from doing pretty much whatever they want with the plugin.

The downside to this is that it also makes a significant barrier to entry to inexperienced developers.

I don't really intend to abstract it away anymore than it already is (exact opposite actually, I want to open it up more).

Writing up the "basic grips" tutorial made me realize how difficult it will be to break everything down in a simple manner.

[Starkium]

Thought I'd let everyone know that I'm writing up a document on how to combine weapon master and the VRE based on uberblockheads original findings, but then I'm taking it a step further and cleaning it up. Here's the live doc https://docs.google.com/document/d/1...t?usp=drivesdk

[sphinix257]

This is from a while ago now, but I had the thought of instead of interfaces, you could make the WM interactions into a component you could attach to any hand blueprint. This way there is no need to replace the hand BP in VRE. You might still need an interface, not 100% how this would work, but this would eliminate the need to replace a bunch of stuff when using the two.

Also, I feel the inventory should be a separate thing as well. You shouldn't need the inventory in order to pick up a gun and use it. You could probably move the whole bullet inventory to like a "pouch actor" or something. Holsters are already separate actors so that's convenient, buuuut if I remember correctly there are dependencies for them. Summary, everything should be modular.

Does anyone else have thoughts on this?

Generic and decoupled code is the way
I use an info container system where code keeps up with items its storing only when its part of it.
The next level up the chain has no record that the items below it exists until it has to store them.

So the mag acquires bullets that hold data that the gun collects from as many mags as it holds to make Projectiles. But doesn't need the inventory to do it. Nor do attachments affect it if they aren't present.
And mags do there own calculation without the gun for add & remove.

The struct arrays get a bit big and sort of a pain. but they really keep it organized


I think every item should stand on its own and call events to interacting items. In my personal guncode i have rewritten it so deeply and isolated from the plugin and character, that i could rip it out of the vr plugin and use it anywhere there is a way to pick it up. I could even ditch mags and spawn and attach it to be like a tank cannon. Interface commands are a beautiful thing.

[Starkium]

I really wish there was a discord for this. Getting answers would be so much quicker.

[mordentral]

I really wish there was a discord for this. Getting answers would be so much quicker.

There is but it is paywalled a little with the patreon, I answer so many questions daily that it was kind of necessary to limit access a bit.

I still answer PMs in discord when I can too though.

[sphinix257]

How can i find your patron. I dont normally donate regularly. But your plugin and template was the ground floor that i learned to code off of.
I was actually getting ready to give up because in my first month i wasnt even able to accomplish anything with the standard templates.

But i have vastly improved and even widened the scope of my first game because i have caught on since then, and gotten a bit of a foothold.

I definitely didnt have the skill at the time to write a pawn from scratch to get started, or grip code, or polish it. Or evenaa gun for that matter. and now that i do its has saved me several months to a year to keep using it, beings i work entirely on weekends and on my own.

Not to mention youve answered almost all of my questions and all this has all been free.

Id gladly donate to this plugin

Edit i found it. Extremely small text on my phone

[mordentral]

Pushed a commit to the main repository cleaning up some Client Auth logic and simplifying some functions.

Also started in on some tutorial documentation, first part of it is here: https://bitbucket.org/mordentral/vre...em%20Tutorials

[ch.rs.st]

Fantastic plug
how to make it work with unreal 4.20.2

Thank
,

[mordentral]

Fantastic plug
how to make it work with unreal 4.20.2

Thank
,

Download the master branch, or use the precompiled binaries for 4.20 (though i'll note that I am uploading new ones today).

[mordentral]

Listing recent commits in an update post, keep in mind that some of these are a week or two old but weren't worth making a post about just for them alone.
I am re-compiling the 4.20 binaries and will upload when done.

4.19 and 4.20 changes (got back ported to 4.19)

Simplified and improved the HybridWithSweep grip type.
It should now performs less operations while also being of a higher quality.


Allow gripping static mobility objects if the grip type is custom..why not
Corrected a bad commit on the dial component that was causing some incorrect rotations.


Moved SetHeld being called when an object is dropped to before OnGripReleased
is called.

Also moved it before OnSecondaryRelease is called

Also moved the call to the objects own OnRelease to before its parent
OnChildGripReleased as it makes sense that the object performs actions on
itself first.

This brings the flow of execution for dropping to parity with how it is done on grip.


4.20 only

Added GripStruct input Add/Remove Secondary Attachment point functions

Many many optimizations and clean ups regarding the gripping and dropping functions, lowering code bloat.

Added GripID as an input to DropObject and DropObjectByInterface, if the passed in object is
empty it will attempt to use the grip ID to drop instead.

I also added INVALID_VRGRIP_ID = 0 define for code use and locked out index 0 from being
used as a grip id, this lowers the total number of possible simultanious grips per hand from 127 to 126.


Exposed the GripMotionControllers DefaultGripScript pointer to blueprints so
that people can access it and set variables on it (if it is a blueprint base script that is).

Also Changed the default and gun tools grip scripts so that the pivot point is attained
from the ParentTransform instead of getting the controller location again. This is not
only slightly faster, but it also allows people to override the parent transform with something
else (say a remote component) so that the grip doesn't have to be based on the controller
itself.

(force/remote grips for instance could provide a proxy components transform instead)


Took a byte out of the positional replication for controllers and camera
by making the logical assumption that 419.43 meters is a size big enough for any
current roomscale technology.

THEN Took back 1 of the 8 bits that I saved everyone in order to add a
flag for quantization of the rotation on controllers / cameras.

You can now set it from its default Short quantization to a 10 bit per axis
quantization method, effectivly saving 2.5 bytes per rep and with 4x the granularity
of the engine BYTE rotator quantization.

This makes up for the lack of precision on the BYTE method but still allows for some
decent savings.

Also dropped a byte out of the CustomVRInputVector and RequestedVelocityVector.
41,943.04 UU's should be MORE than enough leg room for these values.

Also am now rounding MoveAction_Custom vector values to 2 digit precision. I was
already doing this for all built in movement actions but the custom ones should
also be restricted like this.

[malcriado]

Thanks for the update Mordentral!
Is there any sample where i could see "Closest Grip Slot in Range" in action? trying to make a hose, but i can only pick it from one of the ends instead of any of its bones...
The hose skeletal mesh is already setup for behaving like a chain, had already working on the epic vr template, but is not working on yours, dont know why.
Thanks in advance!
Francisco

[mordentral]

Thanks for the update Moredentral!
Is there any sample where i could see "Closest Grip Slot in Range" in action? trying to make a hose, but i can only pick it from one of the ends instead of any of its bones...
The hose skeletal mesh is already setup for behaving like a chain, had already working on the epic vr template, but is not working on yours, dont know why.
Thanks in advance!
Francisco

I assume that by "working in epic template" you meant that you added a physics handle to it or a constraint?

You need to specify the bone to grip it at because otherwise the plugin doesn't know, the template by default ignores the bone that is hit assuming that you don't want to grip there. There is a gameplay tag in the template that can be set on an object "AllowPerBoneGripping" that will pick up the hit bone when using a physx grip type.



If you don't want every bone to be grippable then you will need to change the blueprint logic a bit to return the set one that you DO want.


If you aren't using the template, passing in the bone name and transform instead of the objects will have the same result.



*Edit*

You could also skip all of this setup if you really wanted to and just constraint a grippable to the bone that you want held and pick that up instead.