Is that all you can answer?
2013/5/3 Absurd Minds <goabs...@absurdminds.net> > Again, do some research. It has been discussed at length and your > questions answered many times over. > On May 2, 2013 8:05 PM, "Timur 'grammaton' Celikkesen" < > gramma...@gmail.com> wrote: > >> It is really dissapointing that users like Absurd Minds can divert >> this list from its intended use again in such an easy way. Please sort out >> your private problems that you have with Glenn Charpantier somewhere else – >> not here. >> >> You are again not contributing to this specific issue which is >> unfortunately not the first time and even more, you try to bash Glenn in a >> very childish way – this is not constructive or factual. Additional your >> response to the topic shows an obvious lack of technical knowledge and >> willingness to accept the public facts i listed before. >> >> If you are able to show us here one single technical proof for your >> response to the topic, which is transparent and conclusive – fine – but >> just dont write any subjective personal opinion without any substance. >> >> Even your arguement that this is a list for server-admins that want help >> with their problems and dont want to discuss, shows a real lack of >> dispassion. >> This rubberband behaviour IS a problem for the hosters and admins – it >> results in many support-tickets from users that are not following lists >> like this or community sites where this is already a huge topic. >> >> @Joseph Lopez >> >> Both can be related, so if you just unobjectively write to screw tickrate >> – you are also screwing the problem that seems to be most important to you. >> >> As i understand the explaination for this server cvar and its intended >> way to work – there is no bug that valve has to fix – it is a matter of >> Serverperformance, Clientperformance and the connectivity/network quality >> between both. >> >> Through the community Site i am running i have access to hundreds, >> sometimes thousands of users and their direct experience, the Bugs and >> Problems showing up after each update – and by that we also have the >> posibility to test on many different server setups, with various routings >> and hardware performances. >> >> We testet a lot related to the new server-cvar and as i expected on tick >> 64 almost nobody experiences this rubberband behaviour. Only Clients with a >> real poor network performance or frame-drops towards or under 64 still >> experience it. >> >> Switch the Server to tick 128 and the game starts to have this rubberband >> “lag” clientside (with vanilla settings on 3) >> >> ...and i think we all can be sure about, that it is more common that >> clients drop around or under 128 frames than 64 frames. >> >> Sry for this textwall but sometimes you just cant put it in just one or >> two sentences to explain your point. >> >> >> Cheers >> >> >> *From:* Joseph Lopez <lopezj...@gmail.com> >> *Sent:* Friday, May 03, 2013 1:05 AM >> *To:* csgo_servers@list.valvesoftware.com >> *Subject:* Re: [Csgo_servers] csgo update >> >> 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 >> >> >> _______________________________________________ >> 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
