How to set up physics constraint (component) while allowing for controlled location adjustment at runtime?

Development World Creation
, , , ,
1

I can best describe my problem by describing the goal:
I have an actor with a physics-enabled static mesh as the root. Imagine the root as a simple circular body. (The important things happen to this root mesh, it gets pushed around as necessary)

I want to have an offset static mesh from this main body and if something impacts this offset mesh, the force will transfer to the main body (hence the attempt at using the physics constraint). Sort of like a shield. I also want to be able to rotate this “shield” around the main body. So the main body gets pushed around and “holds” this offset item via the constraint, and this offset item should rotate around the main body in an input controlled fashion, but if anything physics-wise happens to either the main body or the offset, they act like a single physics object.

Initial question is if this is possible or are there too many variables to have this function simply through blueprints + physics constraints?

The issue right now is that when I set up the constraint between these two items, it locks them in place (the original orientation) and no runtime adjustment (e.g. set relative location/rotation, adjusting something the offset mesh is parented to) will rotate the offset mesh in the desired way. Does anyone have any ideas to throw at this?

2

Does anyone have any experience with this?

3

I think I tried something similar, I had a Weapon, whose root was the actual Weapon mesh. It contained an outer collider for an arcade-style (Fortnite) drop (only yaw rotation).

I spent two days trying to figure it out but eventually gave up and just replaced the Weapon mesh physics asset with the ‘outer’ collider.

I did so much messing about, but I was never able to treat the outer collider as it’s own physics entity (it always took the parent component’s physics into consideration - which I guess makes sense but still).

The only other solution I can think of (I never attempted as it would have required a large rewrite of code in my case), is to use a ChildActorComponent so it’s treated as an entirely different Actor (or at least I assume it does).