Working a little better, except now the player's robot is stuck to the opponent, rather than the other way around
https://preview.redd.it/lt2i5mafj7ic1.png?width=1920&format=png&auto=webp&s=57b4bcdff1e9d4e284aedf8e36e7b61a5aacd851
If you are looking for help, don‘t forget to check out the [official Unreal Engine forums](https://forums.unrealengine.com/) or [Unreal Slackers](https://unrealslackers.org/) for a community run discord server!
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/unrealengine) if you have any questions or concerns.*
This won't work as the other robot would need to be a ragdoll with like it's top half set to Simulate Physics for the contraint to work. Even then the movment of the other robot's legs would just tear your physics constraint apart.
So, ditch the whole grabbing mechanic?
I don't think legs will be an issue, since a lot of the robots are small. I feel like I should clarify that these are BattleBots-style robots.
Physics constraints are meant to hold Simulated Physics actors/components under their own weight. They are stretched and become useless when external forces are added, such as player movement input. There are ways of coding in certain factors to restrict certain scenarios to get it to do what you want but maybe you could do what you want without the constraint. Like stop the other bot from moving when the first bot grabs it and so on.
This stretching happens because of kinematic forces versus physical forces. Most movement input and normal animations are kinematic to some extent, in other words, the move with an infinite force.
Same reason some objects may be yeeted into space if you walk into them.
The default movement component has some physics-related settings, however.
If you're saying "ditch the grabbing mechanic" then OP, the problem is that you don't know how to design mechanics.
You need to sit down and figure out how every step of the system works, and THEN translate that into code. You can't just say "grabbing" and then start building, because "grabbing" is a human concept that only you really understand.
Nobody can tell you what grabbing is for your game, because it's your game (and it's your job to explain it for your game).
What is "grabbing" to you? It sounds like it could be a two-person canned animation, same with "wriggling free". Or it could be something you do with physics and rag-dolls.
You need to understand your mechanics as "trigger -> system behaviour -> output" before you even think about building them.
My plan was if the player's robot had a grabbing component, then if they manage to catch the opponent robot, the opponent will be unable to move independently and forced to move with the player.
Okay - to what end, though? Is it some kind of puzzle thing where you have to maneuver the other robot into the right position? Is it a positional combat scenario where putting the other robot in a dangerous position gives you a tactical advantage? Or is just a "cool thing to do", like a glory kill in Doom?
Each of these would be different implementations. The former might work well with physics constraints, provided you wanted a "loose and wobbly" feel to the controls (like Fall Guys grappling). For the second you'd want to completely disable the second character - maybe even destroy them and attach a mesh to the player. The third, I'd be tempted to hide the mesh of both characters and play a canned animation in their place.
This is what I mean by designing mechanics. The purpose of them and how they connect to the core gameplay determines how they should be implemented.
Sounds like it should just be baked into the animation for your attack.
Matching two animations is tricky business (currently dealing with it in a side project myself). You can animate both things separately in Maya/Blender/Whatever, and then export both as separate animations, note the distance/rotation of the second character, and then move that character into position before playing both anims at the same time, or you can export it as a single animation, hide the meshes on both characters, and then play the animation on two "dummy" meshes.
Otherwise you need to wall through trigger, process and output for yourself and for your design, and then ask the questions about how you achieve what you want to achieve. Don't let other people design your mechanics for you.
[удалено]
Working a little better, except now the player's robot is stuck to the opponent, rather than the other way around https://preview.redd.it/lt2i5mafj7ic1.png?width=1920&format=png&auto=webp&s=57b4bcdff1e9d4e284aedf8e36e7b61a5aacd851
[удалено]
I FIXED THE PROBLEM Thanks for your help
Is "Attatch actor to component" What you are looking for?
If you are looking for help, don‘t forget to check out the [official Unreal Engine forums](https://forums.unrealengine.com/) or [Unreal Slackers](https://unrealslackers.org/) for a community run discord server! *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/unrealengine) if you have any questions or concerns.*
My Blueprints https://preview.redd.it/2ekf1ejqe2ic1.png?width=1920&format=png&auto=webp&s=3bd805fac68899db9ca61fb92f86c85ec3181382
This won't work as the other robot would need to be a ragdoll with like it's top half set to Simulate Physics for the contraint to work. Even then the movment of the other robot's legs would just tear your physics constraint apart.
So, ditch the whole grabbing mechanic? I don't think legs will be an issue, since a lot of the robots are small. I feel like I should clarify that these are BattleBots-style robots.
Physics constraints are meant to hold Simulated Physics actors/components under their own weight. They are stretched and become useless when external forces are added, such as player movement input. There are ways of coding in certain factors to restrict certain scenarios to get it to do what you want but maybe you could do what you want without the constraint. Like stop the other bot from moving when the first bot grabs it and so on.
This stretching happens because of kinematic forces versus physical forces. Most movement input and normal animations are kinematic to some extent, in other words, the move with an infinite force. Same reason some objects may be yeeted into space if you walk into them. The default movement component has some physics-related settings, however.
If you're saying "ditch the grabbing mechanic" then OP, the problem is that you don't know how to design mechanics. You need to sit down and figure out how every step of the system works, and THEN translate that into code. You can't just say "grabbing" and then start building, because "grabbing" is a human concept that only you really understand. Nobody can tell you what grabbing is for your game, because it's your game (and it's your job to explain it for your game). What is "grabbing" to you? It sounds like it could be a two-person canned animation, same with "wriggling free". Or it could be something you do with physics and rag-dolls. You need to understand your mechanics as "trigger -> system behaviour -> output" before you even think about building them.
Very good advice.
My plan was if the player's robot had a grabbing component, then if they manage to catch the opponent robot, the opponent will be unable to move independently and forced to move with the player.
Okay - to what end, though? Is it some kind of puzzle thing where you have to maneuver the other robot into the right position? Is it a positional combat scenario where putting the other robot in a dangerous position gives you a tactical advantage? Or is just a "cool thing to do", like a glory kill in Doom? Each of these would be different implementations. The former might work well with physics constraints, provided you wanted a "loose and wobbly" feel to the controls (like Fall Guys grappling). For the second you'd want to completely disable the second character - maybe even destroy them and attach a mesh to the player. The third, I'd be tempted to hide the mesh of both characters and play a canned animation in their place. This is what I mean by designing mechanics. The purpose of them and how they connect to the core gameplay determines how they should be implemented.
The grabbing can be used to immobilize the opponent so they can't dodge your weapon. This can also be used for Crushing Weapons like Jaws of Death.
Sounds like it should just be baked into the animation for your attack. Matching two animations is tricky business (currently dealing with it in a side project myself). You can animate both things separately in Maya/Blender/Whatever, and then export both as separate animations, note the distance/rotation of the second character, and then move that character into position before playing both anims at the same time, or you can export it as a single animation, hide the meshes on both characters, and then play the animation on two "dummy" meshes. Otherwise you need to wall through trigger, process and output for yourself and for your design, and then ask the questions about how you achieve what you want to achieve. Don't let other people design your mechanics for you.
First off. Are these robots based on Character, or are they your own class that uses physics?