What would you like to change in the Global config?

[deej]

Code: Select all

command "sv_cvar com_maxfps GE 60"

Not such a good idea cause I tend to set it to 0 to remove maxfps limit. I will be forced to 60 then. maybe use

Code: Select all

command "sv_cvar com_maxfps OUT 1 59"

Adapted, thanks!

[ReyalP]

Most Pointless restrictions ever.

Why?

Because it doesn't stop any real problems or exploits, but does cause some people problems ?

The whole idea that maxpackets 30 makes you hard to hit is complete BS.

[jump3r]

<strike>command "sv_cvar b_simpleitems EQ 0"
command "sv_cvar r_detailtextures EQ 0"
command "sv_cvar r_subdivisions IN 0 20"
command "sv_cvar r_lodcurveerror GE 60"
</strike>

[Dersaidin]

command "sv_cvar r_lodcurveerror GE 60"

You could leave that one, otherwise you get some weird stuff like this for example:


However you can shoot through the extra visibility in the lower detail one.

[deej]

Because it doesn't stop any real problems or exploits, but does cause some people problems ?

The whole idea that maxpackets 30 makes you hard to hit is complete BS.

Could you please detail this a bit more because I don't get it.

People tell me: if you put maxpackets at 100 and your FPS does not go over 100 you send exactly 100 packets, i.e. 1 packet per frame, so the server can do optimum hit prediction.

Is this not true then? Please shed more light on this then cause with only "it's BS" you're not exactly convincing.

I based my settings on this post from yourself where, from what I can tell, you say it would be beneficial to actually up the maxpackets to improve hit detection/prediction. I just added the fps restriction in an effort to make sure people would send as much information as possible.

[ReyalP]

People tell me: if you put maxpackets at 100 and your FPS does not go over 100 you send exactly 100 packets, i.e. 1 packet per frame, so the server can do optimum hit prediction.

Is this not true then? Please shed more light on this then cause with only "it's BS" you're not exactly convincing.

When your shot is evaluated, the server interpolates your targets position between two known, actual positions on the server, each of which were generated for a snapshot that was sent to you (and everyone else). Snapshots are only generated once per server frame (20 times per second)

Whether your target ran 1 or 10 frames between those two points doesn't matter at all. You only saw the player interpolating between the positions sent in the snaps on your screen, and the server does the hit detection using the exact same interpolation between the same two points.

There may be some warpyness if the targets frame rate goes below sv_fps, but even that gets smoothed out a fair bit.

If you want a more detailed explanation, go download the unlagged 2.0 source and look at the included documentation. It is more detailed than the unlagged FAQ. If you want even more detail, integrate that code into ET with a much of debugging stuff (as I have) then come back an tell me where I'm wrong. Alternatively, do a well controlled blind test, and show me that people can tell the difference between targets running maxpackets 30 and 100 to a statistically meaningful degree.

[deej]

If you want even more detail, integrate that code into ET with a much of debugging stuff (as I have) then come back an tell me where I'm wrong. Alternatively, do a well controlled blind test, and show me that people can tell the difference between targets running maxpackets 30 and 100 to a statistically meaningful degree.

I was going to thank you for your post right up to this point.

I only asked an explanation so that I could tune restrictions, I never stated you were wrong in any kind.

Lose the attitude cowboy, you helped code a mod, not save the world from WMD.

[ReyalP]

Lose the attitude cowboy, you helped code a mod, not save the world from WMD.

*shrug*
The point of that was that I have some factual basis for what I posted. I am open to the possibility that I have missed something, but it will take more than "OMGZ I CAN FEEL IT" to convince me.

Anyway, I apologize for the attitued such as it is. It's a general reaction to the people promoting this nonsense, not you in specific.

And just to be clear, I didn't help write the code that's in etpro (I independently integrated unlagged 2 into etmain).

[deej]

*shrug*
The point of that was that I have some factual basis for what I posted. I am open to the possibility that I have missed something, but it will take more than "OMGZ I CAN FEEL IT" to convince me.

Anyway, I apologize for the attitued such as it is. It's a general reaction to the people promoting this nonsense, not you in specific.

And just to be clear, I didn't help write the code that's in etpro (I independently integrated unlagged 2 into etmain).

No problem man, I can understand that you can get a bit irritated when people keep asking the same over and over again and saying "they think there's a problem with netsettings".

All I'm looking for as a config creator / cup organiser is the best balance in restrictions to mitigate the "hard to hit netlamer" whine, even if it is probably placebo the way you describe the inner workings of the code.

From what I can tell from all I have read, maxpackets 30 is good enough but higher maxpackets can't hurt or even perhaps improve client-side perception of gameplay.

So maybe we should indeed put everyone on maxpackets 60 or even 100. It might not help their gameplay from a scientific pov but it might help their perception of smooth gameplay. And perception is all what counts within a comp community .

[ReyalP]

FWIW, TWL required maxpackets 50 for a short time (in preseason a few seasons back). The game became unplayable for a certain fairly small portion of players, so they reverted to 30.

If it were up to me, I'd allow maxpackets all the way down to 20 or 15, and let the whiners whine.

[ouroboro]

i always thought the antilag in etmain WAS unlagged. now i are teh confyoozed

as for whine, remove /players and it will vanish like magic

[ReyalP]

i always thought the antilag in etmain WAS unlagged. now i are teh confyoozed

It was a hacked up implementation of unlagged 1. Unlagged 1 itself had some design flaws.

and TBH, I agree about removing /players. Or the netsettings part at least, seeing who is ref is OK.

[jump3r]

command "sv_cvar r_lodcurveerror GE 60"

You could leave that one, otherwise you get some weird stuff like this for example:


However you can shoot through the extra visibility in the lower detail one.

doesnt matter (imho). it wasn't restricted before, so coz this minor change yes?

[squadjot]

command "sv_cvar r_lodcurveerror GE 60"

You could leave that one, otherwise you get some weird stuff like this for example:


However you can shoot through the extra visibility in the lower detail one.

doesnt matter (imho). it wasn't restricted before, so coz this minor change yes?

well it has been like that for ages, but never the less it could in some extreme cases give you an slight advantage, as u might be able to see stuff ure not supposed to.. and i think the performance you gain by tweaking it is minimal, so restricting it woundt bother me.

[jump3r]

well it has been like that for ages, but never the less it could in some extreme cases give you an slight advantage, as u might be able to see stuff ure not supposed to.. and i think the performance you gain by tweaking it is minimal, so restricting it woundt bother me.

i dont care about performace etc, but i just dont like too many restrictions. coz then you can also restrict r_depthbits (omg wallhax!!11) and many other cvars...

see, there are more urgent cvar problems than these above.