[TF2] Improved closest hitbox detection for arrow projectiles

[KeplerTF2]

This PR includes a bug fix from #634

The old method uses the direct distance from the arrow to a hitbox to determine which is closest.
The new method uses the distance from the trajectory the arrow is traveling in to the hitbox.

The old method often led to scenarios where an arrow would visually be moving towards one hitbox, but end up hitting a completely different one that it was technically closer to.
This new method fixes that with more visually consistent hitbox detection.

Old Method

huntsman_old.mp4

New Method

huntsman_new.mp4

[wgetJane]

i was thinking of the dot product being used, but this is smarter

btw if you want this to depend on #634 i think it's better to either manually include its changes or cherrypick it

[woahloxk]

Make hitbox of half dustbowl

[mastercoms]

I think dot product would make more physical sense vs. cross product here. I also think if you did want to weight based upon a proportion of trajectory onto the hitbox direction, vector projection would probably work better?

[KeplerTF2]

I think dot product would make more physical sense vs. cross product here. I also think if you did want to weight based upon a proportion of trajectory onto the hitbox direction, vector projection would probably work better?

The reasoning for using the cross product instead is that it's calculating the shortest distance from a point (the hitbox) and the line (where the arrow is travelling). This results in getting the hitbox the arrow would get closest to if you let it keep flying.

The issue with the dot product is that you'd be doing it between the velocity, and the vector between the arrows current position to the hitbox. This would create a bias where further away hitboxes have lower dot products and are more likely to be hit than hitboxes closer to the arrow

[wgetJane]

here's an alternate solution that doesn't use cross product if you want:

while i personally think this pr works ok enough, i went and tried to make a more "robust" version (which is probably too overkill): #1600

[KeplerTF2]

I do like your robust version, either mine or yours would be good additions, I suppose it'd just be preference between a simpler and good enough solution or a complex but even better solution.