I have a projectile that uses a projectilemovement component to move until its first Hit event, at which point physics becomes enabled on the root component which is a sprite.
Even though the projectile is moving quickly, collision seems to work perfectly when it’s a projectile. But not when it’s simulating physics. At this point hit events sometimes get called when the projectile is not even near the thing it supposedly hit. I drew debug boxes to clarify it for myself. Sorry for the godawful appearance of the blueprint scripting.
Anyway does anyone have any idea of why this might be happening? This collision only happens after the thing it has supposedly run into has been successfully cast as a capsulecomponent. So you would think the hitlocation would be somewhere inside the bounds of the capsule. But it’s not and I don’t understand why. Is this location that I am getting the location AFTER the projectile has already “bounced” off of the thing it just hit? If so, then why would the hit location still be wrong? Thanks for your help.
EDIT: actually the same thing DOES happen even when the projectile is still moving according to the projectilemovement component, without physics simulated. so I guess it’s just a problem with fast-moving collisions? But then shouldn’t CCD resolve this problem? I could fix this problem by doing a raycast every tick, couldn’t I? But should I have to do that? Does this have to do with weird aspects of Sprites, like “collision thickness”? I have tried changing that property from 5 to 500 and it doesn’t seem to change anything.
After doing some research, the best conclusion I can come to is that this is just an inherent problem with the physics in UE4. Maybe it’s inherent to PhysX but I assume PhysX has some way to actually do CCD, it just doesn’t work in UE4 at least at this point as described by these people here:
I am also experiencing things like that just standing in the same spot pressing the same fire button key, the projectile behavior is totally inconsistent. Sometimes things will actually bounce backwards off of a surface which is almost parallel to the motion of the projectile, and sometimes it works normally. I have also encountered interesting bugs like that the InitialOverlap boolean of the hitresult of an onHit event will be incorrect. I am left to conclude that high-speed collision is basically broken in Unreal Engine 4 at this point.
It also doesn’t help that when I try to add breakpoints, this happens within about 60 seconds generally:
Even though my computer has 16GB of ram, the latest mac operating system and the latest unreal engine (4.15.3). It would be really nice if Epic would stop focusing on what new features they can add into the next Sizzle Reel Feature Showcase and make it so that doing random extremely basic fundamental things like adding a variable to a struct on which a datatable is based does not corrupt your entire project every single time, which apparently is business as usual and considered totally acceptable. Also, how are you supposed to develop on a platform where you never know if something isn’t working because the blueprint might just be “corrupted”? Like this person, for example:
So my next course of action at this point is to just rebuild the entire blueprint manually, and maybe it will work because the old blueprint was corrupted. But even if I do that, clicking on “replacing references” with the new blueprint I manually created might crash the unreal editor every single time, as it the last time I tried to do that, and therefore be impossible. In which case in addition to manually recreating the blueprint from scratch, I would have to go into every other blueprint that referenced this one and recreate/rewire every reference (although I assume some more things would break in the meantime while I’m trying to do that). But that still might not do anything because the blueprint might not be corrupted. There is no way to know. But no, adding Volumetric Fog and more new features for VR is a lot more important. But hey, at least performing the following operation: “Right click → create structure” no longer crashes the mac editor every single time, as of… yesterday (4.15.3 update)… Just my two cents…
