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
