[GlaD-Solitary]

BladeKiller, on 01 June 2012 - 09:09 PM, said:

No, those will not be changed because we asked someone who is an expert on Q3 and worked at id software for 10 years and he confirmed that TwentySeven was right not to change those for Q3's networking code.

That's more due to unlagged than the Quake 3 Engine. Q3E runs great with higher net settings but unlagged is hard coded in a way which does not allow us to simply bump up those numbers without larger issues popping up.

I think in this case making the distinction between Q3E and unlagged is very important. Q3E is very capable of the increased net settings but unlagged is currently restricting us from doing so.

This post has been edited by Solitary: 02 June 2012 - 07:12 AM

[|PWNY|Nitro]

Frankie V, on 03 June 2012 - 01:34 AM, said:

Well changing a few values in the network system may produce positive results but the idea that it is in fact that simple is not the case. For that matter stating easy and simple in the same sentence as a feature upgrade is considered rather insulting, as I found out the hard way, to most programmers and knowing what I know in hindsight any programmer joining the team, with the exception of John Carmack, who says that for his first magic trick is going to “patch” the net code would scare the hell out of me.

Granted I’m not a coder but over the past few years I’ve been at least a reliable witness as to what happens when someone mess with anything in the code that relates to timing in general and in all cases, guaranteed, something totally unrelated will break that was total unexpected as well as unrelated.

The bottom line and word from more reliable sources besides uncle Bill or cousin Tom is the net code is something you just don’t mess around with to get it right and if something we do attempt in the future to upgrade it’s going to require an effort far greater than what it took to update the collision detection system.

Sure we can change a few numbers and if we are lucky, fat chance, it will do as advertised but that even then such a change is going to require extensive testing so if everyone wants to wait another year the most we can say right now is who knows.

Bottom line we are just not ready to fix something that is not fundamentally broken.

I could understand that if you were talking about changing the servers SV_FPS rate since this is the timing method used by the game. however I have to disagree when it comes to rate/maxpackets, these are just simple client updates and the more the better, if its too much the server could just drop/ignore the extra updates.

there are many games out there (but I'll refer to the game most popular for comparison on these forums :P) such as COD which allow upto 100 max packets and 30k rate.
now I know you dont want to be another cod series but capitalising on Activision success can only benefit urban terrors success for the future.

it would be nice to atleast try new options since the auto updater will soon be available, and changing the limit of maxpackets to say 63 (126fps/2) for a couple days for testing can't harm anyone except those willing to test it.

[Kr0m]

The black helicopters came and took the troll-ish/flame bait/unrelated posts.

Keep it civilized please.

[Kitty]

BRAVO!!!I'm sooo excited!

[attackxie]

Solitary, on 02 June 2012 - 07:10 AM, said:

That's more due to unlagged than the Quake 3 Engine. Q3E runs great with higher net settings but unlagged is hard coded in a way which does not allow us to simply bump up those numbers without larger issues popping up.

I think in this case making the distinction between Q3E and unlagged is very important. Q3E is very capable of the increased net settings but unlagged is currently restricting us from doing so.

and soli here is 100% correct part of the issue that was discovered was that the unlagged code needs some fine tuning for the higher throughput not a major overhaul just some tweaking in the way it processes things particularly the way it handles "out of order events" and "roll back" as well as some of the msg types are slightly borked because of timing issues
but even all the minor quirks included in most cases its a drastic improvement in FEEL and 'hits quality' providing everyone has a decent computer and is capable of maintaining at least 60fps

This post has been edited by attackxie: 04 June 2012 - 11:35 PM

[attackxie]

tl:dr
the case is as follows
with the client/server running at 20Fps/snaps you have the following conditions

1. if the client or server drops a frame it needs to wait for the next snap window ~20fps out of every 60/125 or the client is running so if you double that so the client will have a greater window of accuracy you add some "fault tolerance" so instead of sampling only 20 out of 60 or 125 you sample 60/125 or 30 out of 60 increasing MSG reliability(optimal would be snaps @ 125/cl_maxpackets 63/rate 125000
2. cl_maxpackets/rate should be the same and cl_maxpackets need to be no greater or less then /2 of sv_fps/snaps again timing issue's and late data = wtf hits or bullets from noware
3. people running at less then */2 of the snaps/cl_maxpackets ratio will suffer(auto dectect system specs and gussimated connection speed would prevent this

4. the unlagged code needs to be adjusted to accept the new parameters and the animations should be re-timed for the higher tick-rate
all of the above has been tested by people that know as much about the q3 engine as anyone here

This post has been edited by attackxie: 05 June 2012 - 04:49 AM

[MajkiFajki]

Any chances for video from event? With English subs ofc

[Yuri]

[quote]Any chances for video from event? With English subs ofc /quote]

Yeah... I would really like to see, or at leas hear, how it went!

[dreta]

Can't wait.

[GlaD-Vortex]

I was told by a reliable source that most if not all cheat clients work based on player numbers (when you type /rcon status or serverstatus). Has this been changed to lessen the ridiculous cheating issues in competitive play?