I want to rewrite how HitResult stores the pointer. So instead of providing UPrimitiveComponent, it would provide a wrapper struct that will hold UPrimitiveComponent and IPhysicsBodyInstanceOwner. Then I’m going to implement accessor functions that will check UPrimitiveComponent first and then fall back to IPhysicsBodyInstanceOwner. But could I store IPhysicsBodyInstanceOwner when resolving it once and then check it for validity, or should I store there TWeakObjectPtr<UObject> PhysicsObjectOwner as well as Chaos::FPhysicsObjectHandle PhysicsObject and then resolve the interface after each access?
I decide to do it like this to unify the interface once for all cases and not to check for a primitive component and then fall back to IPhysicsBodyInstanceOwner in each place in the code. Besides that, the aforementioned MovementBase is cached, so we can cache it not as a UPrimitiveComponent but as some proxy struct that I described above.
we fixed this by creating a fastgeo primitive proxy component to bridge the gap in the middle, allowing for a valid component to be used with the linetrace, unfortunately our terms mean I cannot provide this code, but hopefully epic can implement the same thing and fix this up for a hotfix or future release.
Could you add more details about what we are missing in FastGeo? Could you show me an example with details and see if the following function could fit your needs or not?
We provided the IPhysicsBodyInstanceOwner.GetPhysicsBodyInstandeOwnerFromHitResult to get the IPhysicsBodyInstanceOwner with the HitResult, and the associated physics information (GetPhysicalMaterial, GetCollisionResponseToChannel) could be obtained from it.
Our engine version is 5.5, and we are migrating the FastGeo plugin to our engine. Currently, we are facing two main issues.
The first problem is that when we perform line trace on FastGeo components, the Component and Actor properties in the HitResult are both null. However, many of our logic codes were previously written based on the Component and Actor results from HitResult. Is this approach not recommended?
The second issue is that we found the movement component in version 5.5 is not very compatible with FastGeo components, because the MovementBase is always null. What content do we need to cherry-pick to resolve this compatibility issue? Currently, we see that commit CL 41992364 is related to this problem.