maxpackets whiners

[ouroboro]

As far as the reload thing goes... demos ?

no, i didn't make demos

but i'll try to get somebody to help me recreate the situation and record it sometime

[wipeout]

imo the best thing would be to force 30 on everyone, just so it's even.

It wouldn't be even. The amount of packets sent depends on your com_maxfps (assuming that you will reach your capping almost all the time). The only way to enforce this would be to only allow multiples of 30 as value for com_maxfps (30, 60, 90, ...).

For more info about how this works see this old esreality forum thread. I did some tests after I read this (I found it some months ago accidently) and saw that this is true. I explained in this thread on xfire.be how I did this and what I found out.

About the actual topic: I don't really know how the server uses the data it receives by the players or how the server makes the hit calculations, but assuming it interpolates between 2 packets received to make the calculations, wouldn't more packets make the interpolation more accurate?
Although i doubt that the error gap is going to be so big that it makes aiming impossible.

But as said above I have no clue how it works :/

[ouroboro]

very interesting. what say you, reyalP? according to that xfire topic, low upload does indeed = hard to hit...

i think whatever the final conclusions are, the leagues need to force some kind of settings which disable the ability of players to exploit this kind of thing.

can you say "make-me-hard-to-hit toggles" when you're capping the docs? i bet more than a few people can...

[wipeout]

very interesting. what say you, reyalP? according to that xfire topic, low upload does indeed = hard to hit...

That guy writing "laggy to aim him" is kinda subjective imho.
I guess we will only find that out if we know what effect a higher amount of packets has on hit calculations.

i think whatever the final conclusions are, the leagues need to force some kind of settings which disable the ability of players to exploit this kind of thing.

I agree here. Leagues shouldn't only force restrictions on cl_maxpackets, they should force restrictions on com_maxfps either.

[ReyalP]

very interesting. what say you, reyalP? according to that xfire topic, low upload does indeed = hard to hit...

Its not clear to me whether he is trying say the maxpacket user is hard to hit, or that they have a hard time hitting. Either case smells like bullshit to me, and I did a fair bit of testing changing the maxpackets around and looking for any difference. Even maxpackets 15 (the internal limit forced by the game) looks smooth and hittable to me.

The one thing he is right about is that FPS does effectively limit your maxpackets, and wipout is right about the rounding issues.

i think whatever the final conclusions are, the leagues need to force some kind of settings which disable the ability of players to exploit this kind of thing.

That presumes there is an actual thing being exploited, which seems far from proven to me.

About the actual topic: I don't really know how the server uses the data it receives by the players or how the server makes the hit calculations, but assuming it interpolates between 2 packets received to make the calculations, wouldn't more packets make the interpolation more accurate?
Although i doubt that the error gap is going to be so big that it makes aiming impossAlthough i doubt that the error gap is going to be so big that it makes aiming impossible.

But as said above I have no clue how it works :/

As I previously explained, it doesn't work that way. It uses positions calculated for each server frame and interpolates between those. So as long as there is at least one client command per server frame*, it doesn't make any difference to how other people see you, or how their hit detection is done.

* note that commands don't correspond directly to the packets controlled by cl_maxpackets.

[wipeout]

As I previously explained, it doesn't work that way. It uses positions calculated for each server frame and interpolates between those. So as long as there is at least one client command per server frame*, it doesn't make any difference to how other people see you, or how their hit detection is done.

* note that commands don't correspond directly to the packets controlled by cl_maxpackets.

So more than 20 packets won't affect hit calculations/detection.
What's the use of more than 20 packets then? (Sounds kinda useless now)

That presumes there is an actual thing being exploited, which seems far from proven to me.

bind x com_maxfps <enter very low value here>
Wouldn't you be able to exploit it that way? with very low value beeing smaller than 20 (like 10 or even less)

[ouroboro]

i have a question

knowing all you do about this game, reyalP, what settings do YOU use for the following:

rate
snaps
cl_maxpackets
com_maxfps
cl_packetdup
cl_timenudge (kidding)

if i'm to believe the xfire post, the best setting is 100/100. i'd actually been trying that recently without even realizing it was good, but i went back to 76/76 because i simply cannot accept higher recoil, and i hate fps toggles.

bani, how difficult would it be to regulate recoil regardless of framerate? because there are lots of combinations i'd like to try, including matching my framerate to my refreshrate, but the pistol recoil keeps me from doing it.

i'd like to request that in a future release if it's not too hard. if it'd be a huge overhaul, i'll cope

[ReyalP]

So more than 20 packets won't affect hit calculations/detection.
What's the use of more than 20 packets then? (Sounds kinda useless now)

Not exactly. To give a rough overview of how things work on the server:

Client commands are processed as received. These correspond to client frames. If your framerate is higher than maxpackets, the server still reconstructs one command per client frame. This is why things depend on client frame rate, not maxpackets. (The details of how the server does this are something I've been meaning to investigate, but haven't yet.)

Your client doesn't know right away that these things have taken effect, but it pretends they have, and predicts based on that.

In response to client commands, the server lets you move, and processes your shots etc. Thus higher frame rate and maxpackets gives you smoother movement, and potentially quicker reation both predicted on your client, and on the server.

Every 50ms, the server runs a server frame. This processes all the non-client entities, and generates snapshots of the world to be sent to each client. The snapshots include each clients state, although the clients themselves might have acted 0, 1 or more times between server frames. When this snapshot is received, your client finds out if its prediction was correct.

With antilag, hit detection is done on the positions generated for the snapshots, which is as it should be, since these are the only positions clients ever see. Because of the way time is set up, the hit detection request will always be between previous snapshots (unless you use -timenudge). The server does linear interpolation between the two snapshot positions, just as your client does when it is displaying the other player.

bind x com_maxfps <enter very low value here>
Wouldn't you be able to exploit it that way? with very low value being smaller than 20 (like 10 or even less)

Try it. In my observation (using 2 computers connected to the same server), the effect isn't significant to other people, even down to 5 FPS. Of course, trying to play at 10 FPS is absolutely horrid in any case. Even 20 FPS is pretty bad.

Try snaps 1 while you are at it This is very amusing to see how different it is from your POV and someone watching you....

knowing all you do about this game, reyalP, what settings do YOU use for the following:

I'm currently using
snaps 20 // no reason to use anything else, unless you are on dialup
rate 20000 // why not 25000 ? I dunno
cl_maxpackets 100
com_maxfps 0 // 0, see below
<strike>r_displayrefresh</strike> r_swapinterval 1 // my display runs at 75hz, so its the same as com_maxfps 75
cl_packetdup 1
cl_timenudge 0 // except when people start whining about other players net settings, then I use -5000

Note that running vsync on is an experiment, now that I have a system that can hold that 100% of the time. I previously capped at 76 with 76 maxpackets, if I remember right.

Nothing special about the above, I've tried a pretty wide range.

[ouroboro]

r_displayrefresh 1 // my display runs at 75hz, so its the same as com_maxfps 75

is that a mistake? do you mean r_swapinterval, or did i just learn something new? anyway, about that. i love vsync, it's way smoother. but i cant use it because i hate the "halving" that it does if my fps drops. would it be possible for someone (bani) to alter the way swapinterval works, so that instead of cutting the fps in half when it drops below a certain threshold, it simply disables itself until frames settle again, then reactivates? because that would rock imo.

cl_timenudge 0 // except when people start whining about other players net settings, then I use -5000

lawl. yeh i was using -999 for a while just for the puzzled responses. i'd say "it's so if my ping goes 999, i wont lag out". many believed it

[ReyalP]

r_displayrefresh 1 // my display runs at 75hz, so its the same as com_maxfps 75

is that a mistake? do you mean r_swapinterval

yeah, thats what I meant.

As far as changing how swapinterval works, that is in the engine, so couldn't be changed without a new ET patch.

[EagleReloaded]

If you're only generating 75 frames a second then isn't maxpackets 100 redundant if a packet is only sent for every frame generated?

[wipeout]

Thanks for the explanation reyalP

cl_timenudge 0 // except when people start whining about other players net settings, then I use -5000

Does it actually have an effect? Or (due to what you wrote above: "the hit detection request will always be between previous snapshots (unless you use -timenudge)") what is the effect of someone using timenudge? [And does it make a difference if he's interpolating or extrapolating (due to too low timenudge)?]

Try it. In my observation (using 2 computers connected to the same server), the effect isn't significant to other people, even down to 5 FPS. Of course, trying to play at 10 FPS is absolutely horrid in any case. Even 20 FPS is pretty bad.

I thought more about it beeing used when you can't shoot but somebody tries to shoot at you (reload, revive,...).
I once had the feeling that someone lags when he played with maxpackets 15. But maybe he had just a jumpy ping.

[ReyalP]

cl_timenudge 0 // except when people start whining about other players net settings, then I use -5000

Does it actually have an effect? Or (due to what you wrote above: "the hit detection request will always be between previous snapshots (unless you use -timenudge)") what is the effect of someone using timenudge? [And does it make a difference if he's interpolating or extrapolating (due to too low timenudge)?]

Well, its clamped at -30 in the engine, so even though /players shows up -5000 it should be the same is -30.

If your ping is quite low and you use -timenudge, it could impact your hit detection, by pushing your command times so far ahead that antilag can no longer interpolate. What antilag does in that case depends slightly on the implementation, but it can only be a less accurate representation of what you saw. In any case, it only affects the timenudger himself, not other people shooting at him.