ETPro HitBoxes

[S3ti]

It is true, I was experiencing that many time for the no immediate hitsounds and loses the helmet. Then the hitsound will come really delayed though. it's not totally no hitsound, but the delay is very noticeable atleast at my end where I can see that enemy got no helmet already before hitsounds will come. I guess my lag causes this.

 

Well that's just lag I would guess, but in the demo is no hitsound at all for the first hit (maybe even more) which is obviously a headshot. As said before I'm sure it happens vice versa too, hitsounds are played and you didn't hit. Will upload when it's obvious if I get it on demo.

[SunLight]

Seems not to have 2 many bugs, still beta but I don't know if I'll modify it unless there are serious bugs (at most with etpro, with other mods I don't think).

 

http://www.filedropper.com/ethitboxes

 

read the readme first!

 

You can connect with it only to servers with the word 'hitbox' inside the name (sv_hostname), so if you make a test server it must contain that word in the server name or it won't connect. You can change it on the fly with rcon.

 

I did this to prevent players from being silly, and trying it in public servers, it would be useless anyway if you don't have rcon acces to set g_debugbullets.

[S3ti]

Nice thx! downloaded...but today not in nerdmode, will try tomorrow

[SunLight]

Nice thx! downloaded...but today not in nerdmode, will try tomorrow

Now maybe I'll try to compile it with Linux. It will work out of the box for normal mods, but for etpro it means starting from scratch...

 

a couple of hints I didn't put in the readme, but probably you would still figure out

 

- on Jaymod, use only g_hitmodeGhosting, don't enable those reatime ones, or they would be recorded too.

For the bullet, g_bulletmodeDebug 1, g_bulletmodeTrail 0

 

- on Silent, Etpub, Noquarter(? didn't test this one), Etpro, it's the usual g_debugbullets.

 

- It doesn't matter how much cg_railtrailtime or g_hitmodeGhosting milliseconds you use, just put enough for the engine to 'catch' the hitbox, more than that is not necessary.

 

- on etpro it intercepts EV_LINE so it works even if you set cg_railtrailtime 0

[SunLight]

Why etpro hiboxes are (slightly) behind (and could be ok if they only allowed positive timenudge)...

...and why other mods hitboxes are (apparently) f. up in many ways...

 

First of all, a couple of words on how the game works and antilag:

When you play you don't see 1 server frame after another, you see an interpolation between 2 frames (see blue part of your lagometer)

Antilag makes a copy of all the snaps the server sends to you, then it needs to know the moment of your shot, take 2 old snaps so that your timestamp is in-between them, and calculate the interpolation between those 2 snaps.

 

So the moment of the shot is important, pity that *all* mods don't take it right (it's apparently 1 client frame before, i.e. 10ms at 100fps, 8ms at 125 fps, etc.)

etpro included, look (client had 100fps):

 

explanation: those lines in the shape of a '+' are the origins, coordinates taken from etpro own debug code (which cannot normally be enabled via cvar)

 

yellow = where you saw the player at the (correct) shot moment

light blue = where antilag thinks you saw him (pity that the shot time is behind 10 ms at 100 fps)

the 2 dark blue ones = the origin of the server frames before and after (those 2 snaps antilag takes from the past I mentioned before)

 

same thing at 43fps:

 

now the 'ideal' yellow line is way apart from the light blue one. in fact as I said, all mods take your shoot time 1 client frame in the past.

 

at 200fps:

with 200 fps, since one frame is only 1000/200 = 5msec, the distance is not so great...

 

 

now let' try 100fps and timenudge +10 (note: positive!) 10ms is 1000/fps, that is how long a frame lasts.

perfect! you can't even see there's more than 1 cross. pity that timenudge isn't allowed on etpro, or you could set it to 1000/fps and hitboxes would match

 

on jaymod, etpub, silent (i.e. *all* other mods I tested) the shoot time is behind like on etpro, but not only you can't change it with timenudge, but there seem to be much more bugs, in fact the distance is huge (more or less equivalent to 50ms, a full server frame)

 

jaymod (edit: all screens had 100fps):

 

and even if I set antilagdelay to 60 in the server (50 + 10, that is 1 server frame + 1 client frame), sometimes it fixes, sometimes it's still f. up

[rajaah thunder]

Wow , guess thats why ETpro produces better players than anyother mods . 

[SunLight]

they should allow positive timenudge from 0 to 10 on etpro... knowing that it could fix the origin, but they don't allow it, feels bad

and in jaymod servers they should set antilag delay to 50 maybe

[S3ti]

So the moment of the shot is important, pity that *all* mods don't take it right (it's apparently 1 client frame before, i.e. 10ms at 100fps, 8ms at 125 fps, etc.)

etpro included, look (client had 100fps):

 

Got the same results here, but this feels too extreme somehow. Looks all the same like on your screens but is it possible that the model copies are off, 1 frame ahead of the moment of the shot? Those were all 'standard' settings on the server, jaymod with a bot, client @ 125fps.

 

Here you can see hits but the bulletline doesn't even remotely intersect with the models but hits the box, but I'm sure it did when I shot (crosshair 100% on the model):

 

 

 

PS.

I like the filter/play features of this mod, very nice

Edited June 12, 2013 by S3ti

[SunLight]

Got the same results here, but this feels too extreme somehow. Looks all the same like on your screens but is it possible that the model copies are off, 1 frame ahead of the moment of the shot? Those were all 'standard' settings on the server, jaymod with a bot, client @ 125fps.

I know that when something looks so wrong the first thing you think is: maybe this method is wrong, and I thought it too, but consider a couple of things:

 

- I don't know if you tested with etpro again. Same modified engine, but on etpro hitboxes are on the player, so if the moment of the shot is wrong, why it's not wrong on etpro as well? Given that my engine does exactly the same thing with all mods?

 

- I also compiled a modifed etpub with extra debugging info, and this thing (hitboxes being 'behind') looks *real*, the debug info I added in that modified etpub matches perfectly with this modified engine, so how could I have made 2 different bugs in 2 different places, and they match perfectly?

 

---

 

I explain a bit what I did, and something more about the game

 

When you shoot, you don't tell the server 'hey, I shot a bullet now, then another bullet, etc.' you just tell the server 'I am holding the mouse button'

For weapons like pistol or rifle there isn't a huge difference between these 2 scenarios. (Aside from the fact that all weapons have a built-in delay of 100ms, so you fire 100ms after you push the button)

 

For weapons like mp40, thompson, sten, both the client and the server simulation (when you hold the button) calculate the rate of fire, and generate some events.

 

One thing you can see if you add debug code, is that the event on the client (you can see it with /cg_debugevents 1, the event is EV_FIRE_WEAPON) has a different time than the one on the server, that is the etpro bug (shared by all mods) I mentioned. (note: by 'time' I mean game simulation time, not real time, real time is obviously different because of ping)

 

When the client shows that EV_FIRE_WEAPON thing, it also plays the sound of the weapon, the weapon flash, etc. so for me that *is* the moment you shoot, and that's probably unquestionable.

And the server, when EV_FIRE_WEAPON triggers, makes you shoot with all the antilag and stuff, so the fact that these 2 moments don't match is a bug imho.

 

I make the copy of players in the frame when the client triggers EV_FIRE_WEAPON. In fact when I was still coding it, and it made copies of some 'unwanted' entities (your own hands holding the weapon ) those hands had a weapon with a weapon flash, that *is* the moment of your shot.

 

Maybe our brain has a delayed perception or something, we are talking about 8ms it's not much. But in 8ms a running player moves 1/4 of a headbox or so.

While on etpro the only bug is this (EV_FIRE_WEAPON on the server is behind 1 client frame, so at 125 fps it would be 1000/125 = 8ms behind), on other mods there seem to be much more.

 

The white line in my engine, is the line of your view at the instant of EV_FIRE_WEAPON.

The fact the your bullet matches with it (your own position is not antilagged, at most it's affected by client prediction), while enemies (which are antilagged) don't, is another proof that the moment of the shot is correct, and antilag fails in all mods except etpro.

 

---

 

I could find out more with that recompiled etpub, and in fact I did found out that hitboxes there are essentially wrong, it's not just a matter of shooting time, even if I forced the same shooting time of the client they were wrong, with more tests I could find out.

All mods antilag is based on Neil Toronto's unlagged2, in fact it's not a wonder that inside etpro I found a (disabled, but I reenabled it) debug message with the very same text as in etpub source, in quake, etc. ("Rec: time: " etc. etc.) that text comes from unlagged, maybe there was a bug in Neil Toronto's unlagged which etpro coders found and solved, and all other mod makers copied from unlagged and didn't realize...

 

But now I am a bit tired of testing, anyway I cannot modify it (or rather I could, but I couldn't force a modified etpro or jaymod to servers )

Hopefully they will fix it on Silent mod, which is the only mod that's being actively developed now, maybe they will make it even better than etpro hitboxes...

[Moita67]

 

Magnificent work SunLight

Very well done and well explained!

Thank you for sharing here in the forums

 

 

Regards

[S3ti]

Holy cow what a wall of text! But sounds reasonable

 

I know that when something looks so wrong the first thing you think is: maybe this method is wrong, and I thought it too, but consider a couple of things:

- I don't know if you tested with etpro again. Same modified engine, but on etpro hitboxes are on the player, so if the moment of the shot is wrong, why it's not wrong on etpro as well? Given that my engine does exactly the same thing with all mods?

- I also compiled a modifed etpub with extra debugging info, and this thing (hitboxes being 'behind') looks *real*, the debug info I added in that modified etpub matches perfectly with this modified engine, so how could I have made 2 different bugs in 2 different places, and they match perfectly?

---

 

No didn't test on etpro again, will do some more testing on both mods. I was sure that hitboxes are behind but this is a lot!

[Death_Reincarnated]

Hence why I play even better in ETPro than in other mods

 

Nice work BTW.

[SunLight]

Got the same results here, but this feels too extreme somehow.

those are omnibots, right? I made a new discovery... which is good news

 

Some time ago, since on etpro there were no bots and I wanted to train a bit offline, I made a computer enemy for etpro (no navigation, only fight and !iwant command to move it somewhere)

That bot was obviously better in fighting and moving than those lame-ass omnibots, it moved more like a real player, and I also add a mirror or delaymirror mode to make this enemy copy my moves.

 

I used it to test etpro hitboxes too, and he's got the same hitboxes as a real player.

Now I adapted it to work with all mods (still tends to crash, but if I fix it and I convert it from Linux to Win I could post it here).

 

And lo and behold, hitboxes of that fake-enemy aren't behind (or rather, like on etpro they are behind only that little amount, from the EV_FIRE_WEAPON delay bug).

 

I'm a bit confused, since a bot is a bot, how come omnibots have such crappy boxes? But I bet that with real players the boxes are like my own fake-enemy, and not like ominbot.

 

For etpro when we tested together, they were more or less the same as when I tested offline against that thing.

[S3ti]

those are omnibots, right? I made a new discovery... which is good news

 

Some time ago, since on etpro there were no bots and I wanted to train a bit offline, I made a computer enemy for etpro (no navigation, only fight and !iwant command to move it somewhere)

That bot was obviously better in fighting and moving than those lame-ass omnibots, it moved more like a real player, and I also add a mirror or delaymirror mode to make this enemy copy my moves.

 

I used it to test etpro hitboxes too, and he's got the same hitboxes as a real player.

Now I adapted it to work with all mods (still tends to crash, but if I fix it and I convert it from Linux to Win I could post it here).

 

And lo and behold, hitboxes of that fake-enemy aren't behind (or rather, like on etpro they are behind only that little amount, from the EV_FIRE_WEAPON delay bug).

 

I'm a bit confused, since a bot is a bot, how come omnibots have such crappy boxes? But I bet that with real players the boxes are like my own fake-enemy, and not like ominbot.

 

For etpro when we tested together, they were more or less the same as when I tested offline against that thing.

 

Yes it's an omnibot. ...let's test again on the server, just write me in xfire.

[S3ti]

Ok seems the hitboxes of omnibots are off as far it can get and are not representative at all.

Went online again and we did some parallel runs on jaymod and etpro, this can be considered as the final test I think

 

Jaymod:

 

 

Generally the hitboxes aren't the problem here and seem to match quite good with the model, most of the time.

 

The more serious problem seems to be the bullet when moving, here we just ran in a parallel line and tried to hit.

The yellow line is where I had to shoot, or it would be a complete miss. The red line is where it actually registers the hit!

It's far behind the model where I have to aim on my screen:

 

 

 

ETPro:

 

 

Still little hitbox errors sometimes, but aiming on the model and hits register. cl_timenudge 0.

 

Now with cl_timenudge 8 to compensate for the bullet delay of 8ms (1 client frame @125fps) as SunLight showed earlier.

I would consider it perfect and aiming is on spot with the model on my screen, hits register perfectly and the 2 bullet lines match very close:

 

 

Edited June 14, 2013 by S3ti