Check the other threads about why higher tickrates are better. We don't have to discuss it in a mailing list where server operators get help with their servers.
Also, you should like you're still butthurt. I sincerely apologize for causing you to embarrass yourself so fully a few months ago. On May 2, 2013 5:35 PM, "Glenn Charpantier" <gl...@candrom.com> wrote: > "Please stop." > > You are (yet again) not contributing with your message, instead you just > uselessly spammed tons of inboxes. > > It is indeed a legitimate question, and in the right place. > > > > Sent from my iPhone > > On 02.05.2013, at 23:31, Absurd Minds <goabs...@absurdminds.net> wrote: > > Please stop. > On May 2, 2013 5:24 PM, "Timur 'grammaton' Celikkesen" < > gramma...@gmail.com> wrote: > >> In the past Valve argued in a very reasonable way why they forced the >> tickrates for other Source-Engine Games. >> >> We also know from the CS:GO changelog that we already had Bugs related to >> Tickrates higher than 64. >> >> One of the causal conclusions from Vitalys explaination could be that it >> is generally better to leave it on 64. >> >> Valve is running their own Servers on Tickrate 64. >> >> So the question is why are the logical arguments for other Source-Engine >> Games not taken into consideration for CS:GO? >> >> Unfortunately the last real information regarding netcode is more than a >> year old (a tweet from Chet Faliszek via the csgo_dev Account) and that >> CS:GO uses an updated Version from the Netcode done by Kirsch (who also did >> the original Code for 1.6) >> >> If this “updated” means that arguments for other source-engine games are >> not effective for CS:GO and that documentation like the Latency >> Compensation Methods from Bernier or other older informations from Kirsch >> are obsolete related to this specific subject... i am fine with that... >> >> I just want to know where is the technical difference between other >> Source-Engine Games and CS:GO >> >> So please stay cool....it’s generally just a legitimate question after >> reading Vitalys Mail ....not an attempt to start an unnecessary discussion >> ;-) >> >> >> Cheers >> *From:* Saul Rennison <saul.renni...@gmail.com> >> *Sent:* Thursday, May 02, 2013 9:56 PM >> *To:* csgo_servers@list.valvesoftware.com >> *Subject:* Re: [Csgo_servers] csgo update >> >> Let's not start a "discussion" on tick rate, please! >> >> >> On Thu, May 2, 2013 at 7:02 PM, Timur 'grammaton' Celikkesen < >> gramma...@gmail.com> wrote: >> >>> This is really a very good explaination and as i understand it – you >>> can take this also as an argument to finally force CS:GO to a specific >>> tickrate. >>> >>> I was always a bit confused why the argumentation for the tickrate 66 >>> force at CS:S (which is logical) was not used for CS:GO (with 64 Ticks). >>> >>> Related to this i want to call up one specific point in a previous >>> changelog... >>> >>> -Limiting physics timestep to 64 to eliminate high tickrate physics >>> bugs, such as bouncing guns >>> >>> >>> As long as you give the choice to select the tickrate, the community >>> will always choose the higher value – regardless if it makes sense or not. >>> The competative part of the community will always discuss about it. >>> >>> ...but as we all should remember.......it took just some few days after >>> the tickrate force or fps cap... to end years of unnecessary discussions. >>> >>> just my 2 cents >>> >>> >>> Cheers >>> >>> >>> *From:* Vitaliy Genkin <vita...@valvesoftware.com> >>> *Sent:* Thursday, May 02, 2013 6:56 PM >>> *To:* csgo_servers@list.valvesoftware.com >>> *Subject:* Re: [Csgo_servers] csgo update >>> >>> >>> The value for *sv_maxusrcmdprocessticks* specifies maximum user >>> commands that server will handle from a client in a single server frame >>> tick. >>> >>> E.g. if you run a 128-tick server with max 3 usr cmds per tick, but your >>> client runs at sub-64 fps then the client might experience incorrect >>> prediction on movement and what you refer to as “lag”. The solutions here >>> would be to: >>> >>> 1) disable the user commands limit completely on the server with >>> *sv_maxusrcmdprocessticks >>> 0* >>> >>> This would use old behavior and allows clients with any low framerate or >>> high packet loss to fully execute all queued up movement packets on the >>> server and allows clients to maliciously inject additional movement packets >>> for execution on the server thus possibly attaining a higher than maximum >>> movement speed or movement speed bursts observed by other players. >>> >>> 2) increase the user commands limit to allow slack for clients running >>> with low fps with e.g. *sv_maxusrcmdprocessticks 16* >>> >>> The higher the value the higher “movement burst speed” can be observed >>> by other clients and can be attained on a single server tick by a cheater >>> or user with severe packet loss or low fps. >>> >>> When running 64-tick server with default setting of max 3 user commands >>> per server tick clients might observe incorrect prediction on movement when >>> running with sustained fps below 25 fps or when running at 64 fps but >>> dropping 30% of packets or a combination of these unfavorable conditions. >>> Even when a local client encounters incorrect prediction on movement all >>> other players in the server still see their movement as smooth and from >>> other players’ perspective the movement speed is always within max movement >>> speed. >>> >>> To diagnose the case of clients being affected by the setting of max >>> user commands you can use “sv_maxusrcmdprocessticks_warning” convar, >>> setting it to 0 will spew all server ticks and clients for whom user >>> commands are being dropped, setting it to 1 will spew no more than 1 >>> message per second, setting it to default -1 disables the spew. Once you >>> narrow it down to the client you can disable competitive min spec on the >>> server and capture the client statistic with “net_graph 5” on the client. >>> Let us know if you encounter clients running at sustained fps >= server >>> tickrate without any packet loss that experience dropped user commands and >>> we’ll be able to investigate further from here. >>> >>> Thank you, >>> >>> -Vitaliy >>> >>> *From:* csgo_servers-boun...@list.valvesoftware.com [mailto: >>> csgo_servers-boun...@list.valvesoftware.com] *On Behalf Of *Loïc Péron >>> *Sent:* Thursday, May 02, 2013 9:23 AM >>> *To:* csgo_servers@list.valvesoftware.com >>> *Subject:* Re: [Csgo_servers] csgo update >>> >>> >>> >>> *sv_maxusrcmdprocessticks "3" makes players lag when moving.* >>> >>> >>> >>> *sv_maxusrcmdprocessticks "0" fix it.* >>> >>> >>> >>> ------------------------------ >>> _______________________________________________ >>> Csgo_servers mailing list >>> Csgo_servers@list.valvesoftware.com >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >>> >> >> ------------------------------ >> _______________________________________________ >> Csgo_servers mailing list >> Csgo_servers@list.valvesoftware.com >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >> >> >> _______________________________________________ >> Csgo_servers mailing list >> Csgo_servers@list.valvesoftware.com >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >> > _______________________________________________ > Csgo_servers mailing list > Csgo_servers@list.valvesoftware.com > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > > > _______________________________________________ > Csgo_servers mailing list > Csgo_servers@list.valvesoftware.com > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >
_______________________________________________ Csgo_servers mailing list Csgo_servers@list.valvesoftware.com https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
