Originally posted by
jk_Chesterton
Explosions aren't working well if there are any objects whatsoever in the way, even things like door frames, etc (best watch that clip at 0.25 speed).
I was thinking about how I would code it and came up with this, I throw it out in case it inspires anything:
- Extend something like 24 vectors a short distance, maybe 20 units or so, around the explosion centre.
- The heads of the vectors would create a shape that looks like this but smaller.
- Delete any of the vectors that collided with an object.
- Check LOS from the heads of the surviving vectors to possible targets within the full 125 radius of the explosion's actual centre.
I dunno, it's just an idea.
Hey, thanks for the clip. I don't think that's an issue with the explosions, it's probably just a collision issue where the game thinks the projectile contact surface has a different orientation than it really does. I've implemented a tentative fix for 357 that will be pushed tomorrow. It's just that we have fast and slow environmental intersection queries. The slow ones provide more info and are used where it's important to accurately characterise the contacting surface (like with grenades). Linear projectiles were using the fast ones by mistake which would ruin the input to the splash logic so I think this will fix that.
At least I'm assuming that this is the issue. In your clip, unfortunately, you are dying and the round is also ending which could be factor. But I don't think so, as you seem to have 25hp when the explosion happens and that's 250ms of being shafted, minimum, so let's go with the collision theory. Let us know if this happens again after 357.
Regarding the idea, we'll try to first fix the problem that I think is there with the output of the collision query. In the future we'll probably be revisiting how the splash generally works anyway. (Though these queries are relatively expensive and we can probably get something good with less than 24.)
devtrackers.gg