when i set a Static Mesh as the Component’s “Child Actor Class” , “Add Movement Input” Node starts providing different results (movement which is unexpected for the provided input) .
i disabled the sub Actor 's physics (in the Component’s details) and tried to Attach the Component to the main Mesh (by dragging in Components window) . didn’t help .
Add Movement Input 's code shows only that it updates “ControlInputVector” which i can’t find how is being used .
maybe i should use another way of attaching Actors, which one would be the most performance-friendly ?
also, if i move the sub further from the main Mesh, the issue doesn’t appear . but i already tried all options i could find, to disable the collision .
Hey there @irvnriir! In most cases all you have to do to make components not effect a standard character’s movement (in real time control) is to make sure it’s not colliding with the player mesh or the capsule collider. However this is a bit different for any character that uses NavMesh for movement. May we see your object hierarchy and the details for the colliders? An example of the odd movement would help in telling you exactly where it’s failing as well.
Control Input Vector is basically just an input for the character movement component that that character movement then uses to move the character, which is why it doesn’t seem like direct movement.
i found out that if i disable collisions of all Components in the sub Actor, the issue doesn’t appear .
but i need these collisions . assuming that Character Movement Component ignores whether colliding Actors are attached, how to temporally make it ignore collisions of certain Actors/Meshes ? (preferably keeping physical collisions between the parent and sub Actors/Meshes)
is there a way to make Character Movement Component consider a separate/Component- Mesh or Actor a part of it’s Character collision for movement ?
So that’s a bit of a fun one, because any child component of a character is a child of the capsule, so it by extension get’s it’s settings but the character movement component itself is hard coded to only sweep against the capsule to determine movement.
So depending on your use case we may have to set it up differently. What’s your use case/goal here and I might be able to determine a way to get to handle that a bit differently. Worst case scenario could either make a copy of the character script and edit it, or use pawn movement.
I am having the same issue. My use case is I am trying to make mech characters with swappable weapons as arms. I need to add the ability for players to swap out these parts, and the visuals, the collision, and the firing code all need to be different and swapped out to coincide with each part swap. Hence attached child actor components are what I am using cause I can easily get the child actor component, cast to to a weapon base and trigger a “shoot” function that each child of that weapon base can implement differently.
However, these attached actors are interfering with movement. If I place them far enough out, there is no issue, if they are fairly close it can slow the character, and if they are attached very near the existing character and their mesh and collision capsule, they can completely block all movement entirely?
How is this functional? Attaching a swappable weapon to a character should be very basic functionality, why on earth is the movement component reacting this way to attached actors?
Hey there @Lord_JerevarTTV! Welcome to the community! I’ve also worked on a mech project doing something similar. How are you attaching the pieces? Generally one of the preferred methods I had was to attach and weld, which basically makes it an extension of it’s parent, so it doesn’t collide with itself. Though by the end of it, I had moved away from the base character controller as I needed more control.
Thanks for a response. So currently I have the child actors attached to a component that is attached to the main mesh in the components. These parts are also given sockets. I am using a set of modular mech constructor pieces from the marketplace. It is set up so that the chassis, or legs, or whatever, is the main mesh of the character component. It has a socket to attach a torso item, and then the torso item has sockets for left, right, and middle, to attach weapons, or a cockpit, or whatever else. So currently I have a the guns of the mech attached to body component, in terms of components, and then using the left and right arm sockets, provided by that peice.
So the weapons are not attached directly to the player character mesh. Could that be part of the problem? Currently I’ve just set the weapon child actors to have no collision, to get things working, but would prefer they do, so I can have more accurate hit detection than a sphere or capsule. I was thinking I may have to make a map of weapon sizes, and adjust a hitbox component dynamically to wrap around the no-collision having weapon-arms.
I am going to play with the component attachment order. Maybe I can attach them directly to the mesh, but still use the attached body pieces socket? I had not thought of that.
Thanks again, and I will report back with my findings!
That is why they are colliding with the capsule. They are effectively different actors.
So there’s a number of ways to go about it. You could just make a new collision channel for the parts that ignores the player’s collision type and keep your old attachment system fine.
For my system I had them attached directly to sockets on the skeletal mesh like the Valley of the Ancients machine:
Oh my gosh, thank you so much for the help! I got it set up a lot better now. I can’t believe I didn’t think of that.
As I am eventually going to be adding full customization of the chassis, and the core, and the weapons, I cant have the weapons attached directly to the mesh (chassis part) I need it attached to the body, so it’s mesh can be swapped out for a similar one. The other bodies may have the left and right socket in a slightly different place, hence why the weapons need to be attached there, so they can move dynamically with the assigned sockets.
However, I did already have a custom collision setting added to the engine (Player) which I was using so player projectiles ignored the player character when spawning out of it.
Anyway, long story short, I turned collision back on the weapons, but told them to overlap their own player type, and problem solved!
I am excited I can switch to mesh collision detection now, despite the cost. These mechs can come out to be some weird shapes, and capsules and spheres were not cutting it.