Announcement

Collapse
No announcement yet.

VR Expansion Plugin

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    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.

    Code:
    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.

    Leave a comment:


  • replied
    Originally posted by ch.rs.st View Post
    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).

    Leave a comment:


  • replied
    Fantastic plug
    how to make it work with unreal 4.20.2

    Thank
    ,

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    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
    ​​​​​​
    Last edited by sphinix257; 09-11-2018, 03:35 PM.

    Leave a comment:


  • replied
    Originally posted by Starkium View Post
    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.

    Leave a comment:


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

    Leave a comment:


  • replied
    Originally posted by Starkium View Post

    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.
    Last edited by sphinix257; 09-10-2018, 06:46 PM. Reason: spell checking and wording. i originaly wrote it at work in a rush

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    Originally posted by Viperpog

    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:


    Originally posted by bleak_dk View Post
    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.
    Last edited by mordentral; 09-10-2018, 02:36 PM.

    Leave a comment:


  • replied
    Originally posted by mordentral View Post
    Got a little sidetracked today.....

    Car works off of original character now though.


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

    Leave a comment:


  • replied
    Originally posted by OneShotGG View Post

    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?
    Last edited by Starkium; 09-07-2018, 02:37 PM.

    Leave a comment:


  • replied
    Originally posted by sphinix257 View Post
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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

    Leave a comment:

Working...
X