I’ve noticed that calling UPrimitiveComponent::SetCollisionEnabled can have inconsistent behaviour if you’re also changing the collision state of the actor itself. The reason for this is that the function checks if the new collision state differs from the current one, but actually checks the actor’s collision state rather than the component’s. So if you attempt to set, for example, NoCollision, but the actor currently is set to have collision disabled, then the change is ignored, even though you’re trying to change the component collision specifically. Then if you turn the actor collision back on, the component collision won’t be in the state you expect.
This is simple enough to fix, we can just change the first line of the function from
ECollisionEnabled::Type CurrentType = BodyInstance.GetCollisionEnabled();To
ECollisionEnabled::Type CurrentType = BodyInstance.GetCollisionEnabled(false);And then we correctly check against the component’s collision state.
However, the reason I ask this question is that this has actually come up twice on UDN before:
[Content removed]
[Content removed]
In both cases the responder agreed that this looks like a bug, and in the first case there was an issue created, but it was closed as won’t fix almost 2 years later.
I can make this change myself, but I’m curious as to whether there’s some reason this change wasn’t made by Epic. It makes sense that true would be passed to check the actor collision state by default, as externally you want the primitive to appear to have no collision if the actor has all collision disabled. However I don’t think it makes sense in this function, but it could be that I’m just missing something.
Thanks!
Dan