screw tickrate. im worried about the lag issue / rubberbandlag. hopefully this is fixed soon
On Thu, May 2, 2013 at 3:59 PM, Drogen Viech <drogenvi...@googlemail.com>wrote: > So what arguments do you have besides "LOL THE OTHER THREADS SAY HIGHER > TICKRATE IS BETTER"? > > > 2013/5/3 Absurd Minds <goabs...@absurdminds.net> > >> Thanks for subscribing me to a bunch of spam. >> On May 2, 2013 6:02 PM, "Absurd Minds" <goabs...@absurdminds.net> wrote: >> >>> 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 >> > > > _______________________________________________ > 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
