From what I have read there have been a number of issues with optimizations and VS 2019, Nothing much we can do, but the developers are fixing them. From what I can see this one is now fixed (I am now on VS 2019 Preview 16.5.0 Preview 1.0) I have been able to remove the pragmas and the model seems stable in release mode now!
Many thanks for making the code available, keep up the good work!
BEST PLUGIN EVER !
It’s exactly what i need for years ! Now I can use sub-stepping to make some car physics simulations in BP, really need a 4.24 version !
Hello. I did check on github, is it so that 4.24 version of plugin does not exist yet? Or am I looking wrong place maybe 
Thank You!
EDIT: hmm looks like i got it recompiled myself for 4.24. Will test later. If looks okay, can upload binaries to Gdrive.
Just pushed 4.24 version to the master. There are some small changes. What would be cool is to get rid of all warning about PCHs.
Thank You! 
Can this be used for commercial use? This is exactly what I’ve been looking for, I’m making an FPS and this is a requirement lol. Also you should make a market place page, so you can get some sweet money
Wonderful plugin
Hi, I have a problem with Get Transform - Component in the latest version of the plugin in UE 4.23.4
Both Physics Constraint Component and custom blueprint Scene Component return wrong location. The pink squares are the debug points in the location of the suspension mount component where I add force. It should be where the red arrows are pointing. The real locations of those components are correct, they aren’t really where the pink squares are.
I tried rotating it, the directions are ok then, but it’s wildly offset by a couple of meters.
Add force at location is wrong as well, but it just take X vector as the Y vector. I checked the code, can’t find any errors. The main parent body isn’t rotated as well. The stock add force and get transform work ok, no problems there. Please help.
AddForceAtLocation requires a physics simulating component as input, it won’t work on anything else. The location is in world space, so should be easy to debug.
What “GetTransform - Component” does is crawls over the hierarchy of components till it gets to the first physics simulating component and then calculates final transform backwards. This does fails sometimes if root component is not physics body. Like that bottom MMTGetTransform - Comp has “self” as input value which won’t going to work correctly, instead it should be physics simulating component or a child of one.
@ Ok makes sense. The parent is physics simulating, everything else is flat underneath it, but doesn’t simulate. So I just have to switch to using bones locations and everything will work, right? Thank you 
Didn’t work with sockets or bones ;( The main body component is skeletal mesh component with physics simulation. Its bones location are still rotated. How else can I define points relative to the center of the physics body?
I tried adding relative position. Without rotating it with the main body, the position is ok, but after rotating from the body rotation it it’s rotated 90deg X and 90deg Z.
Heyyy, I combined X0 Y90 Z90 with the body rotation and rotated the relative mount position and it works!
Hello)) Thanks a lot for such a marvelous plugin!!
Here I have this warning. Divide by zero detected. But I don’t know is it dangerous or not))). Can I just ignore it?)) Or maybe I can fix it somehow?)
You can track where exactly it happens and add a check for 0. Otherwise as this is BP it shouldn’t create any problems besides spamming log with warnings.
@… phenomenal plugin, thank you so much. I’m using it at the very center of my physics pawn control.
Here is the thing, I’m using the PID controller to AddTorque(MMT) in roll to my pawn… pitch and yaw is controlled by the player. I’m aiming to torque the roll to match the surface the player is hovering over. It works perfectly for small transitions, by getting the ground rotation from a line trace beneath the pawn. But when the wall is vertically in front of the player, and the player correctly pitches upwards… the roll reliably goes a bit haywire. I’ve tried it on Physics Tick, and normal Tick with the same results.
My formula is simple, PlayerRotation - GroundRotation and feed roll into the PID. Is there something I’m doing wrong?
Probably a gimbal lock. Using quaternions could help.
Thanks! I tried quats… still about the same result. Flip, I thought it might solve it too.
Might there be some issue with the delta roll magnitude (it’s trying to rotate the ‘wrong’ way around), with my formula for assembling the ground rotation, or with the way I’m applying the torque in local/world space? #puzzled
wooo… finally got it working… in this specific case, it didn’t need quats, just for the ground rotation to be transformed to local space… then applying the torque also in local space… thank you
