To summarize, as I understand from reading the code, hit detection works like this:

- A list is made of the objects within some distance of the projectile.
- Each object is checked to see if it can hit the projectile, which may be random based on their interaction.
- 25 positions, starting at the old projectile position and finishing at the new projectile position, are checked to see if they're inside an object that can be hit. If not, and the projectile has fragments, it checks whether they're in proximity range of an armed hostile, but farther away than the previous position. If it detects a hit or proximity trigger it will detonate at that position. (Unless it's a proximity trigger and the failsafe is still active.)
- If no hit or proximity trigger is detected and the projectile has fragments, it checks ahead of the new projectile position to see if it would hit anything in the next tick. If so, it will detonate at the new position.

This works fairly well when the projectile is fast compared to the things it might hit. However, if a ship approaches the projectile from the side, or from the front at particularly high speed, the hit location can be inside the ship. In this case projectile fragments will all immediately hit the ship. With a recent update, only half of the fragments will be created, but this isn't an ideal solution. For one thing, I think radius fragments may not appear, causing missiles that use them to do no damage sometimes. But it's also weird that no projectile fragments would be emitted away from the ship.

Instead, I suggest moving the hit position so that it's outside the ship. (EDIT: To be clear, this would only apply to projectiles that fragment.) If a collision is detected after the first (old) projectile position, then the hit position could simply be moved back along the path a small fixed distance.

However, in cases where the ship hits the projectile from the side, the old position may be inside the ship and the nearest point along the projectile's path that's outside the ship may be some distance back. In this case, I suggest checking a point that's the projectile's old position plus the ship's velocity times one tick. If that point is also inside an object, the projectile was probably fired inside the ship (or there are multiple objects close together), so just set off the projectile at the previous position. However, if that position is clear, step from there towards the new projectile position until a hit is detected, then go back a small fixed distance. It won't be exactly on the path the projectile would have taken, but it will be in the same position relative to the ship where the hit "should" occur. If no hits are detected along that line, then the ship actually passed behind the projectile and it should continue on, assuming the ship doesn't trigger proximity detonation. (EDIT: improved algorithm)

Also, the efficiency and/or accuracy of collision checking could be improved by using a variable number of steps based on the projectile's speed, so you aren't skipping lots of pixels or checking the same pixel repeatedly.

EDIT: Furthermore, if a projectile that fragments comes within the minimum desired distance of an object that can set it off, it can explode there. There's no need to check to see if it will get closer. These changes might eliminate the need for the look-ahead part of hit detection, making fragmenting weapons more consistent in how much damage they do, and thus easier to balance.

megas 23 Feb 2016:

Need to be careful explosions are not shunted too far away in case the player wants to fire from within the middle of a huge target.

nms 23 Feb 2016:

Good point. I don't think it would come up much, because essentially the projectile position would only be shifted sideways if its initial position was inside the ship, but that point wasn't inside the ship on the previous tick. And it would be shifted by at most the distance the ship is moving in one tick. But I did change the algorithm for this case to be more efficient and clearer about the distances involved.

the_shrike 23 Feb 2016:

See also: https://ministry.kronosaur.com/record.hexm?id=3946

Which is a partial duplicate.