thanks for the reply,
however widget interaction works when I simulate server+client right from the editor and does not work on the client when I run server and client on two different PCs.
And if I leave steam enabled and run both PCs with two different steam accounts, they both display that I am playing the game , but I do not see hosted game
Then you aren’t setting the widget interactors up correctly in multiplayer on possession.
For the second one, it works, you need to make sure your settings are correct and that the actual subsystem is loading up. Make sure that you have the steam overlay on shift-tab and run with logging enabled to check for sure that the subsystem is being created.
Nobody get a crash for unreal in VR with 4.20?
I can’t be the only one. If you go to the Project, and OPEN any MESH, the engine crash… I tested in 3 diferent PCs and i got the crash in the three… Can anyone test please?
how should I set them up? I use your standard bp_teleport_controller and 3dwidget, did not do anything to customize their replication.
Here are screenshot representing how does it look like from both sides
Client side:
I got hands attached to what I’m grabbing, but they’re IK hands, so if I reach out farther than my model can reach, the object detaches from the hand.
Has anyone thought of a good way to solve ?
Edit: Maybe get the relative offset of where the hand should be relative to the controller on tick, and add it the grabbed actor’s transform?
Then I need to figure out what that offset would be. It’d be the grabbed actor’s offset along with the hands offset to the grabbed actor.
I haven’t messed with type of stuff much in the past. Trying to wrap my head around it.
I don’t know how old your build is, but in the template in late 4.19 / early 4.20 I removed trying to set up the interactor widgets on both ends for every pawn. was due to how the interactors work (creating a “fake” input entity) it was not only difficult to get unique index’s but it also bloated things that didn’t need to be, all for no real benefit (how the indexes are used in the virtual input array are less than ideal).
Generally you don’t need to see the other persons laser interacting with the menu, if you do, then you can change how the interactors are setup and pass in a valid unique index on remote clients for every pawn, you’ll have to manage somehow so that there is no overlap.
If the index’s overlap than then one set of the widgets just won’t work locally.
Edit from the second SS the client appears to not be able to interact, so you would be on the build right before I fixed it and removed the remote setup.
Hi there, might be a silly question but seems i stuck.
Trying to combine several grippable objects together. Attaching grippable component (with some angular / linear limits) to grippable static mesh actor led to fail for me, no matter with constraint or without it.
I managed to create a grippable object with a VRSlider component, and it seems to work fine. Except that object can not be grabbed from VRslider itself.
But now I’m trying to create a grippable suitcase with a lid. Used a VRlever component for a lid, and it’s works fine until i grab a suitcase.
Here is a video that shows what i mean: https://streamable.com/2s509
Is there a proper way to set up that kind of stuff?
Added new game to the list of use cases:
Hello is a known bug and the target fix is 4.21
you have to a change with the support stationary skylight.
The stuff bellow was from a post dealing with that crash
In 4.20.1 if you enabled “Forward Shading” and disabled “Support Stationary Skylight”, you will get crash(same error).
Try as it works for me:
if support stationary skylight on put Off
if Off put On
Your problem there is that the logic levers aren’t intended to be simulated, when you pick up the base of the suitcase it simulates the lid as well (they are auto welded), you can either unsimulate the lid OnGrip, unsimulate it on the main body dropping, or put a scene component between the two which will keep the lid from being simulated when the body is held.
You could also move to a straight physics constrained lid instead if you wanted to (using a manipulation grip on it).
Technically the lever should still “function” when simulated since it will directly set its location, however you appear to be forcing a manipulation grip on it instead of using GripObjectByInterface so its not using the CustomGrip type that it needs to be using (thus the spinning around hand physically simulated). The object specifically asks for the CustomGrip type with the interface, you need to be using it.
Edit I guess technically I could force unsimulation on grip on the lever itself, but generally it shouldn’t need it, in practice with a mockup it worked fine since it was still using the custom grip type.
As for grabbing an object from the slider itself case, the slider is its own grippable object, I allow gripping actors AND components on objects and child components cannot dictate the position of their parents. You can constraint two objects or add a second grip to the actor itself or use two actors, ect, there are multiple ways of doing it.
I don’t have a “pass grip up” feature built in that would force the parent to be gripped instead of the child if the child is set to DenyGripping currently, but you could easily add that in to your grip logic check. Its more of a user side thing, if the slider is set to DenyGripping then check its parent actor for the grip interface and grip it instead.
The angular limits part is essentially how the example gun was setup prior to me making it a slider, however I will note that the InteractionSettings got removed in 4.20 and put into a GripScript instead as they were generally far worse than just hand scripting a CustomGrip type.
Added another use case game to the list
are you all, who are using plugin, staying on the bleeding edge with updates?
Using my music industry experiences, it would have been insanity to update ANYTHING mid album or in the middle of a huge project…I guess its easier with unreal because you just back up a folder and can go back without installing anything, but still.
is there something wrong with 4.20 that I should know about? Its been pretty stable for me, of course I dont know how many game changing updates unreal comes out with but many of the plugins are barely making it to 4.20…
I was building a blueprint project and i figure epic updates the nodes so that they run correctly most of the time, i had no issues swapping over to 4.20 but i really wanted 4.20. I have heard that c++ migrations aren’t as easy. But people still do it just fine.
Do you need new features to build your game
has been teasing really cool code to, but ive gotten far without it.
Its been extremely stable for me.
Ive heard only good of 4.20
Hello !
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!
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, 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.
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. way there is no need to replace the hand BP in VRE. You might still need an interface, not 100% how would work, but 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 ?
Now drifting would be a sick little add-on to that
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:
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, is so that there is nothing preventing them from doing pretty much whatever they want with the plugin.
The downside to 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.
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 VRE+WM Integration - Google Docs
