Hitboxes (probby discussed a million times)

squadjot · Post by **squadjot** » Tue May 04, 2004 5:14 am

Hey Bani and crew

I was testing the hitboxes..first in etdefault..and afterwards in etpro..

is it me?..or are the hitboxes...pretty much the same...? actually..they looked EXACTLY the same as default..

i just heard that tere was done some hitbox fixes..true or not?

Deus · Post by **Deus** » Tue May 04, 2004 5:18 am

What do you expect them to be ?

Like bodyshaped ?

Hitboxes are edited afaik.

*BiO*Tron · Post by *BiO*Tron » Tue May 04, 2004 5:45 am

AFAIK there have been no changes to the hitboxes at all, only to the antilag code.

However, I've come up with a theory why so many players felt that headshots were more "random" now since ETPro introduced the new antilag code.

Everyone who is interested in this topic has surely read the following article: http://www.et-center.com/?page=articles&id=43
If not, do so quickly.

What you can see is that for almost no model the positions, where the head is displayed on the client and the actual head hitbox is, fit together. You can also see that the bigger discrepancies occur for strafing players. Finally, one can notice the biggest discrepancies for all models where the player strafes to the right.

As bani explained, the original vanilla ET antilag code was broken in several ways. From what I can tell, at least the framerate dependency bug led to the fact that you had to lead your shots slightly in order to hit, even with antilag turned on. Bani also mentioned that the server was generally lagging 50 or 60 ms behind (don't recall the right value) which probably means that you had to lead your shots as well.

Now imagine someone was always aiming directly at the head, with the old antilag code and now with the new one. When he was shooting at a player strafing to the right (or to the left, even if the discrepancy is not as big), what might have happened is:
On his client, he aimed perfectly at the head which - taking the actual hitboxes into account as you can see them in the et-center article - means that in fact he would MISS the head. BUT if there was actually need to lead your shots with the old antilag code, it would result in a delayed hit calculation on the server and therefore those shots would have been recognized as headshots.
With the new antilag code, which works much more properly, shots aimed directly at the heads of strafing players are no longer recognized as headshots because of the hitbox wrongness. In order to score headshots, you have to aim a little behind the head of a strafing player.

Now this is just a theory which might be wrong, but could the ETPro crew please think about it and tell us their opinion?

IdNotFound · Post by **IdNotFound** » Tue May 04, 2004 8:40 am

I believe ETpro didn't change anything else than the prone hitboxes, that was totally bugged.

The latest change to that is a gradual transition from standing to prone, not sure how (if going by crouch hitboxes on the mean time or something).

ETpro team can give you more details

Chr0nicles_ · Post by **Chr0nicles_** » Wed May 05, 2004 2:56 am

With the new anti-lag code (3.0.2) you can indeed just aim on what you see, but you get better results if you aim slightly behind the moving player.

squadjot · Post by **squadjot** » Wed May 05, 2004 6:15 am

Chr0nicles_ wrote:With the new anti-lag code (3.0.2) you can indeed just aim on what you see, but you get better results if you aim slightly behind the moving player.

well.. , if the hitboxes still arent fixed..it would depend on what direction the player moves...imo

ReyalP · Post by **ReyalP** » Wed May 05, 2004 1:03 pm

squadjot wrote:
Chr0nicles_ wrote:With the new anti-lag code (3.0.2) you can indeed just aim on what you see, but you get better results if you aim slightly behind the moving player.
well.. , if the hitboxes still arent fixed..it would depend on what direction the player moves...imo

As a general rule, the head is behind the moving animations, in the direction of movement. I.e. you have to 'trail' instead of 'leading' This is added to a fixed offset based on which weapon you are holding. SMGs have one of the biggest offsets.

Bani has said that this is too hard to fix, but IMO, it could be made a LOT better (say within 4 units of the model head 90% of the time, instead of the current which is often 10+ units away from the model). The server does know roughly which animation is in use (weapon held, running/walking/strafing/swimming) since these are assigned in bg_, and it could choose an initial offset based on this. Furthermore, it would be possible to verify and refine this by comparing the actual head postion and calculated head postion on a non-dedicated server. You might even be able to build some kind of lookup table automatically that way...

This is something I hope to try when I get the time. If it works out, I will certainly make the code available to anyone who wants it.

The downside of doing this is that everyone would have to learn to aim again. Given the ammount of noise the antilag fixes generated, I'm not sure how that would go over...

*BiO*Tron · Post by *BiO*Tron » Wed May 05, 2004 1:58 pm

SCDS_reyalP wrote:Bani has said that this is too hard to fix, but IMO, it could be made a LOT better (say within 4 units of the model head 90% of the time, instead of the current which is often 10+ units away from the model). The server does know roughly which animation is in use (weapon held, running/walking/strafing/swimming) since these are assigned in bg_, and it could choose an initial offset based on this. Furthermore, it would be possible to verify and refine this by comparing the actual head postion and calculated head postion on a non-dedicated server. You might even be able to build some kind of lookup table automatically that way...

This is something I hope to try when I get the time. If it works out, I will certainly make the code available to anyone who wants it.

The downside of doing this is that everyone would have to learn to aim again. Given the ammount of noise the antilag fixes generated, I'm not sure how that would go over...

Sounds like a good plan to me if you could make it work like you say. I think most people would welcome that change as it's simply more intuitive to aim directly at the head instead of a little bit behind it. Also, the current antilag code isn't out that long yet so it's not that everyone is used to a trailing aim since ages.

The most annoying hitboxes for me personally are those of crouched players. The actual head hitbox is the furthest away from the animation of the head and when you miss it, you don't even score a body hit. I guess many people have experienced those situations a lot where you are shooting directly at the head of a crouched (and strafing) player and don't get a single hit.

Post by **bani** » Wed May 05, 2004 4:39 pm

SCDS_reyalP wrote:Bani has said that this is too hard to fix, but IMO, it could be made a LOT better (say within 4 units of the model head 90% of the time, instead of the current which is often 10+ units away from the model). The server does know roughly which animation is in use (weapon held, running/walking/strafing/swimming) since these are assigned in bg_, and it could choose an initial offset based on this. Furthermore, it would be possible to verify and refine this by comparing the actual head postion and calculated head postion on a non-dedicated server. You might even be able to build some kind of lookup table automatically that way...

keep in mind the server has no idea what animation frame an individual client is playing. some animations move the head wildly -- the situp animation for wounded players is an extreme example, tossing packs is another one.

not to mention the player leaning based on trdelta. throw animations on top of that and...

also, there are still etmain antilag errors up to an entire body length or more. (etpro fixes this mostly, but there are still errors)

ReyalP · Post by **ReyalP** » Wed May 05, 2004 10:07 pm

bani wrote:
keep in mind the server has no idea what animation frame an individual client is playing. some animations move the head wildly -- the situp animation for wounded players is an extreme example, tossing packs is another one.

Absolutely. It would still be wrong some of the time, and grossly wrong occasionally. With the client an server guessing what each other are doing, it will never be perfect. OTOH it seems to me it could be much better most of the time, and rarely worse. Just adding offsets for holding an SMG and moving forward/right/left would be a big start. Strafing with an SMG is probably the most common thing we do, and it is one of the worst cases. Of course the proof will be in the actually doing it.

I am well aware of the antilag bugs.

Bedrock · Post by **Bedrock** » Wed May 05, 2004 11:16 pm

Strafe-left-nade

Strafe-right-smg

Run-forward-smg

crouch-smg-strafe-right

Lol?

squadjot · Post by **squadjot** » Thu May 06, 2004 12:04 am

how do you get the hitbox to follow you around` (if thats what u do here?)

Bedrock · Post by **Bedrock** » Thu May 06, 2004 12:14 am

I'm not sure, I don't take credit for taking those screenshots. Yes, those are the hitboxes. I don't know the commands to show them though, I had them before.. but right now all I can find is how to activate railtrails. =o~

squadjot · Post by **squadjot** » Thu May 06, 2004 12:17 am

well..devmode map then g_debugbullets 7...but then they just appear "freeze" when u make a "hit".. they dont follow you around (teh baxes)

=FF=im2good4u · Post by **=FF=im2good4u** » Thu May 06, 2004 1:34 am

i used to green and red ones

banimod / etpro / ettv forums

Hitboxes (probby discussed a million times)

Hitboxes (probby discussed a million times)

just thought these were interesting.