Pushed a new commit to both the template and the master plugin
Updated to new branch code
Added local only grips that execute only on the client calling them (do not replicate objects using grip)
Removed actor/component seperation in grips and made it all work off of single uobject base
( change lowers replication cost and makes the plugin more generic).
Template was able to be made more generic now due to (no actor/component switches anymore for most things).
update might have bugs that I haven’t found yet, let me know.
Should be able to work on feature sets now instead of the backend with change.
Template required blueprint changes after the plugin update, since there are no longer actor/component outputs on the grip structure it unlinks it wherever it was used and you have to link in the grippedobject instead.
Did you test with KeepOriginalMovement or ForceClientSide? Because I don’t use KeepOriginalMovement on any of the objects, only ForceClientSideMovement. Maybe I didn’t understand your response entirely, just making sure.
All objects by default are ForceClientSideMovement, that is why I was confused about you running into KeepOriginalMovement being set to true. You are somehow either corrupting a struct or altering one without knowing it as even replicating an empty default struct it will be ForceClientSideMovement by default unless uninitialized (structs constructor never ran). Are you deleting objects a lot?
Nice, keep going!
Colliding with a wall bColliding should be set to true but generally I didn’t consider it because the actor/component itself will trigger an OnHit event and I didn’t see a reason to duplicate engine functionality.
Moving so fast that the object is farther than normal from the hand with physics grips there isn’t currently anything to tell you that, for the auto drop I read the constraint length and if it is too large than drop the object, I could add a function to get value if it is useful to you.
Auto drop btw calls the OnDrop event like a normal drop.
I am. Every time a player dies, I drop his weapons (so that he can’t shoot, it’s also a good indication that he died), and then I destroy them. We did some playtesting today and the assert was thrown randomly while we were just teleporting around. I am setting the members of the InterfaceProperties without an authority switch at begin play, could cause any issues?
Yeah that could possibly be an issue if it is only being set on one side, if you are resetting it to KeepOriginalMovement somehow for instance after it has already been gripped.
Like I said, the struct itself auto sets to ForceClientSideMovement when its constructor is called, the only way for it to bypass that is you to be manually setting it or somehow passing in an empty struct entirely with uninitialized values.
is AutoDrop part of the new commit you pushed out? I can’t find it in the one back a commit.
Currently whenever the player drops a key item (one that is spawned in with them, ie sword / gun / something) it attaches back to their hip.
The problem is that when my player is moving and runs into a wall / swings the weapon too fast it stops grabbing it but doesnt reset it to the hip/socket
That’s exactly why I am NOT using an auth switch on begin play, to make sure it’s set on both server and client. I am only playtesting with two grippable actors, and they have the same logic… I never change members after the initial initialization that happens on begin play.
Well that would trigger “OnDrop” on the held actor if it uses the interface. What are you looking for? An “OnAutoDrop” event on the controller itself that passes the object to drop back in? At that point it would probably be better to turn auto drop off and run your own checks, auto drop is just there for convenience.
By the way, for swords I wouldn’t suggest using a physics grip, there isn’t really a way around there being a slight offset due to the controller and the object being on different threads and if you run swords as a non interactive grip then they will feel attached to the hand instead of floaty.
Yeah I picked up some destructed objects before, you have to be able to trace them as they default to the async physics thread I believe.
Added in auto deletion of physics handles for pending kill objects,
ensured that grips are removed on pending kill objects.
Still better to manually Drop() an object prior to deleting it. is a failsafe.
I am having the hardest time installing ? Are there any detailed instructions on how to install plugin into 4.14.1. I read the:
Clone Or Download Zip and extract repository to a folder named “VRExpansionPlugin” in your “ProjectName/Plugins” directory, create directory if it is missing.
Add the VRExpansionPlugin to your projects PublicDependencyModuleNames in the projects build.cs if you have c++ code included.
IF you do not have c++ code, use the Add New button in the editor and add a blank c++ class to your project.
I will offer pre-compiled binaries for all builds as well eventually when the plugin is stable enough for it, but until then installing it in the project instead of the engine is better.
But for some reason, I get lost at step 2. Please help
If you have C++ code added to your project then just follow step 1 and start your project. It will ask you do you want to build, click yes let it do its stuff and you’re done. If you don’t have C++ code added then delete the plugin , start your game then add C++. Then start over at step one.
When I do step 1. I get an error that says “plugin missing or incompatible modules in VRExpansionPlugin - would you like to disable it? You will no longer be able to open any assets created using it.”
After clicking ok, another message saying
Plugin ‘VRExpansionPlugin’ failed to load because module ‘VRExpansionPlugi’ could not be found. Please ensure the plugin is properly installed, otherwise consider disable the plugin for project". Then the Unreal Engine does not open. Please advise on how to install for a block head like me.
