ETPro HitBoxes

[SunLight]

Hi guys

 

So,

after that nice discussion on whether hitboxes match with the player model or not, I decided to investigate a bit further on the matter, to boldly go where no etplayer has gone before and finally learn something about when we all don't hit.

 

I chose etpro, since it's the 'standard' ET mod for all biased players like me.

 

Taken for granted that the delayed lines of b_realhead aren't faithful for players in motion (the mere idea of being able to see hitboxes in realtime for moving players is nonsense, with the client and server running 2 different simulations at different framerates, where the client has lots of interpolations, predictions, etc. etc.) so I won't discuss further on this (obvious for me) thing, you could ask, how can you test if hitboxes and antilag are ok, then?

 

The obvious way would be to draw a box (on the client) around the player model you see, at the moment you shoot, then when the server receives your command and does the hit detection and antilag, g_debugbullets will send you another box, with the 1st one still visible, you check if they match, and that's it. Pretty straightforward.

 

ETPro developers already made this thing (so it's not my idea), and I knew it already, I also knew from it that hitboxes sometimes aren't exactly aligned with what you see, but when it happens the difference is negligible. The problem is, I wanted to see the headbox too, and maybe the bullet line, insted they made it only for the bodybox.

---

How I did the screenshot:

 

NOTE: don't try it at home, and especially not online! only for testing, etc. etc. etc. this is a test lan server + an udp delayer to simulate pings, I'm not so dumb to modify etpro and go play somewhere. That being said, let's continue.

 

I had to modify etpro adding some short assembly code, to display hitboxes when I shot a bullet. Etpub does it in CG_FireWeapon, I did it in another place, namely where etpro does it for b_antilag debugging. I still have to fix the headbox, so don't pay too much attention to it, and maybe I'll add the bullet line too.

 

In the screenshot taken I had 48 ping. With a higher ping, the difference is more or less the same (so I can't whine for playing with a high ping, 2 bad). The blue hitbox is where I saw him (drawn by my code), the red+yellow headbox is where antilag calculated the hit (sent by standard etpro server via g_debugbullets). The bodybox without head was my own, just ignore it, look at the other player's hitbox.

 

The enemy was moving to the left in that screenshot. As you can see they match more or less. Sometimes the real hitbox (red) is ahead (like in this case), sometimes behind. It's not fixed, I guess it depends on several minor things, timers, etc.

 

I still have to fix the headbox and add the bullet line (which I guess will be the one which differs the most, between where it should be and where it is)

 

Stay tuned for more screenshots

 

[hobbit]

[PiNoY]

interesting. what is that white line ? is that the bullet trace? on that picture, did you get a body hit?

[CJ Brewer aka .nAbish?]

Interesting, I use to play pro myself.. Looking forward to more screenshots.

 

@lamer pretty much sums it up lolz

[SunLight]

interesting. what is that white line ? is that the bullet trace? on that picture, did you get a body hit?

Only the blue lines are drawn by my code, the rest is stock etpro g_debugbullets. The white line should be the part of the bullet trajectory that intersects with the hitbox.

 

As an update, for the headbox I tried to call cg_gettag, I tried to use cent->pe.headRefEnt.origin, but I see that both don't match with b_realhead, especially when the player leans way back. So I had a better idea, instead of bothering further with head origin...

 

The idea is, instead of drawing those blue hitboxes, I would just 'freeze' the player in place, by copying its entity as it was the moment I shot the bullet to a new entity.

When the server sends g_debugbullets boxes, I would see the real player (who will be already far away), and a frozen player where I saw him the moment of my shot. And I can check if the headbox matches with his head, without having to bother about the head origin

---

To simulate a connection with a ping, I have a little script (written in python) that acts as a proxy, so I connect to this thing and it delays my udp packets, then sends them to the real server port. I can choose ping, st. dev. of ping fluctuations, packet loss, etc.

 

Now you could say, why don't you use the built-in sv_packetdelay and cl_packetdelay to simulate pings? Because I wanted to be sure, and because nobody has a constant ping on the internet, there is always some randomness, so I used this proxy, and I can check hitboxes for players with any connection, high ping, low ping, unsteady, packet loss, etc. etc.

 

Another problem, and maybe here you can suggest me something: I know that Enemy Territory servers act differently if your ip is from a lan. Actually both client and server check this, and send more data if in lan, etc.

 

In some other tests in the past, I solved the problem by simulating ips via iptables nat rules, now I have to check whether it can be done in a more convenient way, I know there are some Linux live cds for network simulations, but I don't know if you can also simulate people connecting from outside. Actually both for the client and server, they should 'think' they are connecting to the internet and not lan... what a pain...

[PiNoY]

Would like to see that idea works, re-draw of past and present player location.

 

On simulating external connections by not leaving your "room", how about creating 2 separate virtual machines, each running from separate PCs ? Though this may require more RAM if you decided to use vmware or virtualbox software, maybe it can do the job for you? And probably use 2 separate non-private IPs and connect them via cross network cable, possible? I dont know but does Etpro algorithm validates which IP class a particular IP address belongs to?

[SunLight]

some screens (all done with ping 0 for now), I could have found better clothes for the 'frozen' player lol

 

here I 'froze' him while he was in the air. Even if I use knife it's counted as a 'shot' so a frozen player is created, but no debug hitboxes are sent from the server, because I didn't hit him. Then I switched to smg. The frozen player has no backpack, weapon or helmet because I draw only the head and body, in the same position and animation he had the moment I shot.

 

here I was shooting 1 bullet. All hitboxes and debug lines here are drawn by a standard etpro server and client, the only new thing is the colored player. I explain again how it works: the exact moment I shoot, a fake player appears exactly on top of the enemy.

He has the same position, animation, etc. as I saw him the moment of the shot.

This way, when the message from the server with the hitboxes arrives (based on ping it can take a fraction of a second) I can see if the hitboxes (sent from the server) match with the player as I saw him the moment I shot (the guy without weapon and funny colors)

 

here is a crouch jump (holding c while jumping) as you can see the bodybox is a crouch bodybox because he holds 'C' in the air. That's why pro players crouch-jump instead of just jumping, among other things it makes them harder to hit (but that's not the only advantage)

 

another random screenshot:

 

@Pinoy:

Then I have to solve that network thing, but it's a separate issue. Yes, the game checks if your ip is 127.0.0.1 or some other lan address.

[PiNoY]

These visuals make ET, though old, a more interesting to know and play. How are you going to solve the network thing ? can that be solved via a random delay function of your python script?

[SunLight]

These visuals make ET, though old, a more interesting to know and play. How are you going to solve the network thing ? can that be solved via a random delay function of your python script?

my python script already has ping randomness, the problem is that in the engine a function checks whether you are in lan or not, and force some values for higher network performance. I don't know if there are more checks other than that, that's why I wanted to do a real ip simulation, but the easier way would be (while i'm already modifying stuff) to just make that function always return false and problem solved...

 

On Linux I did the fake ip via iptables and it worked, but these tests I'm doing now are on windows, so I don't have iptables... maybe I could use iptables in the router, and make it redirect all packets sent to fakeip1 to my pc, and make them as if they are coming from fakeip2, etc.

 

I found a Linux livecd called WANem, seems promising. I didn't read anything about ip simulations there, but If I run it from a second pc, and I configure Windows to use that pc as gateway maybe I can do something even with my network noobness let's see...

 

 

Meanwhile I noticed that bullets are slightly delayed, meaning that when you run left, the real bullet is a bit to the left than the ideal one, and it depends on the player's fps (frame rate). With low fps the difference is greater. But hitboxes are quite accurate to the player model's position.

[Gengis]

I like it .... i remember my old days when i created an ET server on my PC and used it to see%2

[PiNoY]

If you use a linux gateway, then both PC connected with it can use public IPs (non-local), packets can just be re-routed to 2 IP networks via that gateway, that should probably work out. let's see how things can run on that scenario. it's pretty cool seeing how movements are basically calculated inside this ET engine.

[SunLight]

If you use a linux gateway, then both PC connected with it can use public IPs (non-local), packets can just be re-routed to 2 IP networks via that gateway, that should probably work out. let's see how things can run on that scenario. it's pretty cool seeing how movements are basically calculated inside this ET engine.

I managed to do it with the router itself, after all there is iptables...

 

I did something like this:

 

iptables -t nat -I PREROUTING -d SERVER_IP -p udp --dport SERVER_PORT -j DNAT --to-destination LAN_IP:S_PORT

iptables -t nat -I PREROUTING -d SERVER_IP -p udp --dport PROXY_PORT -j DNAT --to-destination LAN_IP:PROXY_PORT

iptables -t nat -I PREROUTING -d CLIENT_IP -p udp --dport CLIENT_PORT -j DNAT --to-destination LAN_IP:CLIENT_PORT

 

iptables -t nat -I POSTROUTING -d LAN_IP -p udp --dport SERVER_PORT -j SNAT --to-source CLIENT_IP:CLIENT_PORT

iptables -t nat -I POSTROUTING -d LAN_IP -p udp --dport CLIENT_PORT -j SNAT --to-source SERVER_IP

 

it worked, in fact the local server kicked me if I set a high sv_minping, and I had a low ping (it doesn't do it on lan, so it's a proof), and the client sent even 15 maxpackets as I could see from the bandwidth (in lan normally it sends all commands regardless). Plus all the ips in clientinfo on connect etc. were the simulated ones.

 

So I just used 1 pc + the router and that script to delay.

---

I made too many screenshots, then I think I will zip them. For now I tested with enemy ping = 0, and my ping and netsettings with several values. Tomorrow I will do the opposite (me 0 ping, enemy lagging or bad settings).

 

To summarize what I discovered up to now, playing only with my settings and leaving the enemy at 0 ping:

- if you have an unsteady high ping you miss, but not if you have an unsteady low ping

- if your ping is steady, then even with high ping you can aim well (but of course your enemy shoots before, so it's still a handicap)

- timenudge makes you miss (you, not your enemy!) either positive or negative

- maxpackets have no effect on hitting, but if you have a very very high ping low maxpackets feel less laggy

- fps lags and low fps are bad, because the real bullet line has a bigger offset with the ideal one

- prediction errors under fire are a bit higher if you have a high ping, but not so much higher than with low

 

Next time I will make tests with me at ping 0 and enemy with high ping, laggy, etc. etc. and I will post the whole set of screens, maybe I copy them in a single pic

[PiNoY]

Nice proof sun. So ping is a dead factor that influences hit accuracy of low ping against high ping players. Maybe there's a minimum threshold for a steady ping that gives better hit accuracy?

 

Personal gaming experience:

I do have a high ping but I lag more if I have normal nudge and default rate value. So to compensate that, I set a high rate value and negative nudge. What I don't get is that, if there is a minimum threshold 50,000 value for /rate variable but I really feel lag if I set it lower than 75,000, does that make sense? More lags are added when there's no timenudge for my case, as in delays on hit shots. Many times, I was hit outside the door but then I received the hit when I'm already past the door or inside the room, that I experienced a lot of times. Probably due to high ping without negative nudge. I also had to aim slightly ahead of the hit location (path before the enemy is supposed to move) so I can get a hit since I have negative nudge. I got used to it.

 

Awaiting those SS

[Moita67]

Finaly the "real" thing!

 

EXCELLENT !!

Another one awainting those SS

[SunLight]

Nice proof sun. So ping is a dead factor that influences hit accuracy of low ping against high ping players. Maybe there's a minimum threshold for a steady ping that gives better hit accuracy?

Talking about gaming experience, I think the highest playable ping is 98. Not much because of hits, but because if your ping is too high good players can kill you too quickly. With 200 ping sometimes being killed by a skilled player feels like being killed by an aimbotter.

 

Below there is the result of my tests, I put all in a pdf. You will see that (at least on etpro), using timenudge is bad for you. I don't know about Jaymod. Maybe in the future I will test jaymod as well, but now I really need a rest

 

As regards that rate thing, it doesn't make sense to me. The fact that you get killed behind the corner is antilag. It depends on the fact that your killer had a high ping.

 

---

Here is the file with all screenshots:

ETPRO HITBOXES AND ANTILAG TEST.pdf

 

edi:

woops, I forgot to zip it, nevermind the size was the same...

Edited February 22, 2013 by SunLight