Hi. You need to use GetConnected method. This method gives you all actors “connected” to an actor. IsConnected also uses this method internally.
How you use it and when you call it depends on your implementation. For example, you can use GetConnected when you turn your battery on and then find all actors connected to the battery. I use the function like in the screenshot bellow:
You call it with your battery, and it will use GetConnected recursively, then return all actors connected to the battery, directly or via other actors. Then you can filter the list to choose only the actors you are interested in, like the lights, and turn them on.
I use this to make a prototype of modular cars and drones and stuff like that. I have different motors and thrusters and then a “computer”. When I turn the computer on it will use the BP above to discover all stuff it’s connected to and then command them. You can check those examples on my twitter:
MSSRExamples.zip contains the playable demo with all example levels, and MSSRExamples_Project.zip contains the corresponding project files. VR demo is the same as before, no changes yet.
Hello @ . I’ve recently bought your MSSR plugin. Thanks for creating it, it’s really functional and easy to use.
I’m using it for a VR project, and the modified BP_MotionController somehow disables the hand grip animation in the default VR Template. Hand grip animation plays only if you are grabbing an object in MSSR, but it should play whenever GrabLeft or GrabRight is triggered. Do you happen to know that where the blueprint flow breaks, or does enabling the animation (grabbing nothing) contradict with the MSSR functionality?
Thanks.
Original VR template (4.23): GrabRight plays MannequinHand_Right_Grab
Question 2: What exactly do “MotionControllerPawnDetach” do? Does it replace “MotionControllerPawn” as the player pawn? Mechanics I put into MotionControllerPawn don’t work with MSSR at the moment.
It seems I forgot to set bWantsToGrip, you can fix it easily if you edit BP_MotionControllerDetach Grab and Relase events, which are located in the “Grabbing” event graph. It should be like on the screenshots below:
Yes it replaces MotionControllerPawn, but it mostly the same. It uses BP_MotionControllerDetach instead of BP_MotionController. BP_MotionControllerDetach is where the bulk of MSSR code is located. in the Grabbing event graph. Basically, I modified the way objects are grabbed and releaed, but the rest of the blueprints are the original ones from the VR template.
And the “Detach” in the name is because in the beginning there was 2 VR examples. Another example simply used the DetachFromActor function, which was not really doing a good job keeping things realistic. In this version of the example there is a more complex algo that you can see in the BP_MSSRHelpers:: Detach function.
I get Invalid File Specified error from the BP screenshots you uploaded. Can you upload them again please?
Thanks for the explanation about the Motion Controller Pawn.
I would like to use the plugin for a modified/custom VR pawn, so is there any documentation about how to implement it into a blank project or VR Template from scratch?
VR example is basically the default UE4 VR template modified a little bit. The modified part is in those Grab and Release events mostly. You can check how they are done, they are not very complex. If there is something not clear feel free to ask.
Yes, the hands are working. Thanks a lot! Now I’m working on the other implementations.
MSSR works well while grabbing the default BP_PickupCube, but it won’t work with new grabbable objects. Here, I create one duplicate and one child from the default PickupCube. What could be the issue? The created new objects (child or duplicate) are grabbable in the default VR Template.
In most of the MSSR examples, the “Grab” event checks if the actor has a tag, usually “pickup”. Here, in the VR example, the check is in the “GetActorsNearHand” method (see pic). You can check one of the cubes, look for Actor Tags array in the properties. So you have to add a tag like that to your actor.
You can also change the code of the Grab to check some other criteria, like just grab anything which is a physics actor. The original example used an Interface PickupActorInterface to see what you can pick, but I don’t like this approach, because it forces you to use a custom actors. A tag can be added to any actor, including basic static mesh actors.
And to “snap” you need to have sockets defined on those meshes, but I suppose you know that already. If not, check Overview level in the example project and the tutorial video.
Under BP_MotionControllerDetach if you are using MotionControllerMap2. There are 2 example maps, MotionControllerMap and MotionControllerMap2. The “2” uses more advanced algorithm to detach things, so it uses BP_MotionControllerDetach and MotionControllerPawnDetach.
The difference between two is how they manage the “Detach” operation.(Grip+Trigger). The first map will just call UE’s DetachFromActor. The problem is that you can easily end up holding something with a hole in the middle.
Second map will rebuild attachment trees to avoid this situation. It will use MSSR’s snap sockets to find which cube is logically attached to which one then use that to make new trees without holes. The algorithm is in BP_MSSRHelpers Detach function.
I noticed a glitch with the parent objects. If you attach multiple attachment trees, some of the attached objects lose their physics. It really compromises the gameplay I am trying to implement. Can you replicate this, and any idea on how to avoid it?
Sorry for asking too much questions, but I loved your plugin and unfortunately I’m quite new to UE4.
Edit: Console log: Blueprint Runtime Error: “Accessed None trying to read property AttachedComp”. Blueprint: BP_MotionControllerDetach Function: Execute Ubergraph BP Motion Controller Detach Graph: Grabbing Node: Set Simulate Physics
No prob. I will try to reproduce that tomorrow. Physics in UE are tricky, because underlying PhysX library represents things differently, there no trees in PhysX.
I can’t reproduce it. I watched your video and tried to do exactly the same few times and it works correctly.
But I noticed something. You spawn new cubes right? Do you spawn them with all the right parameters?
Show me your spawning code please.
edit: I spawned cubes too and I have the same error. I will try to find why
I think I found it. The problem is the “auto weld” physics parameter of the BP_PickupCube. Usually it’s enabled by default, but in the PickupCube bp it was disabled. So I enabled it back and now it seems to work also with the cubes you spawn on runtime.
To enable it, you need to open the BP_PickupCube, disable “SimulatPhysics”, check “Auto Weld”, then enable simulate physics again. Otherwise it’s grayed out.
I want front face of a gemoetry to attach with the other one’s back only. Currently, two front or two back faces can be attached. Is there any socket implementation that I can use to avoid same-face snaps?
Some of physics parameters are very obscure. I try to understand how they work by studying the source of the engine and by trial and error. I think there are bugs i the engine too
>How do you modify the “force” preview material?
You can set it on the preview actor, it’s a variable.
> I want front face of a gemoetry to attach with the other one’s back only. Currently, two front or two back faces can be attached. Is there any socket implementation that I can use to avoid same-face snaps?
I’m not sure I understand, maybe you can show some example?
Did you tried +/- sockets? You can add a sign to the socket name, like “Socket+” or “Socket+_0” or “Socket-” etc. Those signed sockets will only snap to sockets with the same name and opposite sign, or to a socket with the same name and no sign.
There is also the “snap open only” parameter.
Those points are explained in the long tutorial and overview example, check that.
Btw, i think I understand what you mean. You should ensure that your sockets are pointing outside of the geometry. The X-axis (red one) should point outside, like the normals, not up or sideway. Because, by default, MSSR aligns things respecting this direction. Check where is the X axis on the pickup cube mesh sockets for example. This is explained in the tutorial too.
> Some of physics parameters are very obscure. I try to understand how they work by studying the source of the engine and by trial and error. I think there are bugs i the engine too
Well done on the good job then. Very much appreciated.
Looking at the extended tutorial now. Mine looks like pretty much a positive/negative pole issue. Here’s a scheme of my socket setup, the only snap that I want to enable, and two snaps that I want to avoid:
Yes, that can be solved with socket polarity. Call them something like Socket+ and Socket- and they will only snap in the right way, “plus” with “minus” only. There is an example with a hat and a “head”, and the sockets are called “hat+” on the head and “hat-” on the hat.
