Make a function to which you feed a socket name.
Then an event you call.
Then feed the event a flip flop set up with 2 different socket names - see if the weapon moves around - once you call the event.
Remeber that its the weapon that should move, not the hands.
Do it as a simple test just like explained first - once it works, build up from there.
I fixed it, but Iâm really not sure what the problem was. I moved the LHIK function into the AnimBP instead of running it inside the AnimBP through the players blueprints, and that small change made it work somehow.
My best guess is that it was returning a transform of 0 on everything (other than the scale values) in relative space to the right hand, so it would just default to the right hands location. But still; why would it not get the transform of the socket anyway? If it was returning a value, what was stopping it from returning the LHIK value?
Strange, but thanks to those who made an input.
So, you donât know this, itâs not documented - probably at all.
You shouldnât have any code into an anim BP, not even on transition nodes, if it disables fast path (some nodes do, some do not. The thunderbolt icon).
Evrything should be done on the character BP, using the animation BP instance and changing its variables.
Variables should only be stored in the animation BP so that everything can be on the same page (reading state from the anim BP).
If you want to debug the previous code just output the transform in a print string - you should do that just as a default anything things donât work anyway.
If itâs 0,0,0, then the socket doesnât exist or the reference to the skeletal mesh was not found.
You have errors logs and warnings - an invalid reference to a skm is going to issue a warning. They get buried quick, you have to search the log for âwarning".
All of this also doesnât really change the fact that if itâs like in the opening g post image your IK canât reach the target due to the shoulder width / chain setup as well (need to involve the clavicle in most chains).