首先介绍一下《CSGO控制台参数大全网站》,该网站收录了游戏之中百分之90以上的控制台参数及其英文解释,有兴趣的玩家可以研究一下。这是网址:
除了网站查询,还可以通过在控制台输入cvarlist指令来获取最全的控制台参数及英文解释。输入cvarlist按Enter,控制台会自动生成一个列表,它包含了全部的控制台参数,由于内容太多超出了控制台的显示范围,可采用分割列表的方式来解决该问题。输入cvarlist a按Enter,生成的列表中所有参数的首字母均为a,内容也不会超出控制台显示范围。根据这种方法,可依次查询首字母为b、c、d~x、y、z的参数。还有一种方法可以直接导出全部控制台参数,具体在抖音内搜:csgo共有多少条指令?教你提取最新指令。
我会将我目前在使用的参数设置放在最后,可以尝试一下,如果觉得不好用,直接删掉整个config文件夹,游戏设置就会自动恢复默认,顺便说一下,修改参数指令必须在大厅时修改,开始对战时是不能修改的。
稍微有点用参数介绍(其他非网络优化方面的实用参数我就不介绍了,网上非常多):
cl_lagcompensation 开启客户端延迟补偿功能,0关闭,1开启。默认值1,最佳设置值1。
sv_lagcompensationforcerestore 开启服务器端延迟补偿功能,0关闭,1开启,默认值1,最佳设置值1。
sv_lagcompensateself 是否允许对因玩家个人设置而带来的额外延迟进行补偿。0关闭,1开启,默认值为0,官匹锁定为0,不能修改。这条参数我是真心希望官方不要锁定为0。官匹反正是锁0值的,不能修改,其他对战平台我不清楚。原则上来说能开启自然是最好。该参数我就设为1,官匹服务器要强制锁定为0那是官匹的事,万一其他平台服务器能允许用1呢?我就不用单独去修改它了。
fps_max 游戏帧数上限,建议拥有144hz或240hz显示器的玩家设置成300,建议拥有360hz显示器的玩家设置成400。听说职业玩家电脑好的有设置800fps的。
fps_max_menu 在打开武器购买菜单购买武器时,或在(UI)用户大厅界面时的帧数上限,建议拥有144hz或240hz显示器的玩家设置成300,建议拥有360hz显示器的玩家设置成400。听说职业玩家电脑好的有设置800fps的。
net_threaded_socket_recovery_time 客户端每隔多少毫秒就会向服务器发送一次数据。默认值60毫秒。也就是说客户端每秒钟会向服务器发送16.6次数据。(1秒(1000ms)除以60ms=16.66666)。但是你发现没有?你玩游戏时,客户端每秒钟会发送64tick或128tick给服务器。也就是说客户端每一次向服务器发送的数据中可能会含有4到个8个tick。那么如果我想让客户端与服务器的通信频率与tick数量保持一致,也就是一次通信只发送1个tick,那么64tick下就得将该参数设置成15.625(毫秒),128tick下就得将该参数设置成7.8125(毫秒)。
net_threaded_socketrecoveryrate 客户端单次发送给服务器数据的容量上限。默认值6400。64tick下我设置成2400,128tick下我设置成1200。
net_threaded_socket_burst_cap 解释这个参数前先举个不恰当的例子,你下载一部电影,大小有1GB,需要通过网络来传输。网络传输并不是将整个1GB的电影直接传送给你,而是将这1GB的电影分割成很多很多的小数据包,逐个发给你。net_threaded_socket_burst_cap这个参数就是数据包的容量大小。默认值1024,我喜欢把它调大点,调成1200。
net_splitrate 当一个数据包装不下客户端单次发送给服务器数据时,就用2个数据包去装它,实在不行就用3个或4个数据包去装。该参数的意思就是将客户端单次发送给服务器数据分成多少份。64tick下我设置成2,128tick下我设置成1。
通过设置上面4个参数可以确定客户端每秒向服务器发送数据的容量上限,平替cs1.6和cs起源中的cl_rate这个参数,在csgo中cl_rate这个参数被移除了。
1.当服务器为64tick时,我想让我的客户端每秒向服务器发送数据的容量上限为153600。
一是net_threaded_socketrecoveryrate 2400乘以(1000毫秒除以net_threaded_socket_recovery_time 15.625=64)=153600
二是net_threaded_socketrecoveryrate 2400除以net_threaded_socket_burst_cap 1200=net_splitrate 2
2.当服务器为128tick时,我想让我的客户端每秒向服务器发送数据的容量上限为153600。
一是net_threaded_socketrecoveryrate 1200乘以(1000毫秒除以net_threaded_socket_recovery_time 7.8125=128)=153600
二是net_threaded_socketrecoveryrate 1200除以net_threaded_socket_burst_cap 1200=net_splitrate 1
上面4个参数的建议值就是这么来的,并不是瞎写的。了解原理后,还能有很多种设置,看你自己的喜好。
cl_interp 可以这样理解:服务器每秒发送给你64tick或128tick,你的客户端会在此基础上绘制出游戏画面。就拿64tick来说,1秒钟服务器发给你64tick,那么连续相邻的两个tick之间的间隔时长为0.015625秒(1秒除以64tick)。客户端会在这0.015625秒的间隔时长内插入模拟预测帧,达到画面平滑的效果,否则你的游戏画面就会像幻灯片一样。所以cl_interp的意思就是设置插入帧补值的时长。设置该参数值为0时,会自动生成最佳设置,也就是1/64tick或者1/128tick。
cl_interp_ratio讲这条参数之前先回顾一下小学知识,1个点只能确定一个点,2个点可以确定一条直线,3个点就能确定一条曲折线,5个点差不多能画出一条弧线了。倘若把这里的点替换成csgo中运动着的敌人呢?在cs起源中cl_interp_ratio这个参数的设置值范围可以从1到5。不少人称这个参数为延迟补偿,这个真不是延迟补偿。不过我也说不出来它叫什么,叫延迟插帧?好像也不对。我只能解释它到底是做什么用的,未方便解释以服务器为64tick时来论述。
当设置为1时,客户端在刚收到1个tick后,就会立刻将这1tick转换为1帧画面,并且在这1tick所包含的数据基础上推测出未来15.625毫秒的画面。前面有说小学知识1个点只能确定一个点,用1个tick所包含的数据去推测未来15.625毫秒的画面,推测结果肯定是不准的,容易造成人物运动画面不连贯、卡、甚至瞬移。
当设置为2时,客户端在刚收到1个tick后并不会立刻将这1tick转换为1帧画面,而是等待下一个tick的到来,等收到了第二个tick后才将先前收到的tick转换成1帧画面,然后通过对比2个tick,精确推测出2tick之间的插帧画面,进行插帧后,最后才将第二个tick转换成1帧画面收尾。前面有说小学知识2个点可以确定一条直线,2个tick所包含的数据能将人物运动画面修复的非常顺滑、连贯。但是延迟1tick才转换画面,会导致15.625毫秒的延迟,而且这种延迟不是网络延迟,是玩家设置而带来的额外延迟。需要开启sv_lagcompensateself为1来对额外延迟进行补偿。很可惜,由于这个参数被强制锁定在0,导致玩家不能补偿设置而带来的额外延迟。所以正常情况下cl_interp_ratio这条参数,设置越大越好,我在玩cs起源时,都是设置成5,csgo最多只能设置成2,官方限制该参数上限为2的理由是:对游戏公平造成影响。然后官方还不满足,又将sv_lagcompensateself锁定为0来进一步限制cl_interp_ratio的作用发挥。
说说区别,我是单点流,因为我鼠标坏了,有时候按住不开枪,被迫变成单点流,大概0.5秒1发子弹,喜欢对着敌人下体点,目标大好瞄准。顶着美国250ping的延迟下,在使用cl_interp 0 ,cl_interp_ratio 1的情况下经常能做到4发子弹点死一个人,然后我血量剩半。在使用cl_interp 0 ,cl_interp_ratio 2的情况下经常在点了敌人4枪时我就被打死了,伤害显示对方只中了2枪,很有可能就是因为玩家设置所带来的额外延迟导致后看到人及后开枪。
另外:网络上有玩家称设置cl_interp 1 ,cl_interp_ratio 2,模型是重合的,打的也非常准。至于对比cl_interp 0 ,cl_interp_ratio 1那个更好用,我没试验过,看个人吧。
cl_interpolate 1开启,0关闭。关闭后敌人的运动就会变的像幻灯片,不连贯。本质上就是把客户端的模拟预测插帧功能给关闭了,看到的画面都是服务器发过来的原始照片。建议开启。
rate 请求服务器每秒钟发送多少比特的数据给客户端。经研究发现该参数只在局域网联机对战时起作用,互联网模式下不起作用!局域网联机对战时由于网络非常棒,建议设置为最大值786432。
在互联网模式下,请求服务器每秒钟发送多少比特的数据给客户端呢?有没有相关参数可以设置呢?没有,但是在cs1.6中到是有这么一个参数:sv_lan_rate 20000,cs起源也有这个参数,唯独csgo没有。我在csgo参数列表中找了很久,就是找不到,说白了就是在互联网联机模式下,csgo客户端所获得的数据量的多少完全是由服务器决定的,客户端没有设置选项(也许是我武断了,我会在去找找,因为每次随着研究的深入还能发现一些细节上的错误)。确定找过了,依旧找不到。为什么我可以很确定地说rate参数在互联网官匹模式下完全失效,因为无论我怎么设置rate值,最大或最小,在输入net_showsplit 1这个参数后,从控制台观测结果来看,客户端从服务器得到的数据量的变化可以说是几乎没有变化。
sv_enable_deltapacking 类似于显卡处理游戏画面时开启双重缓冲或三重缓冲功能。当显卡正在输出当前画面时,会提前准备好下1帧到2帧的画面,这能增加游戏的流畅性,提高fps。同理,放在csgo中你可以这么去理解,当服务器发送当前tick给你的客户端时,会提前准备好发送下1个到2个tick给你的客户端,这能降低ping值,增加游戏的流畅性。看上去是不是很不错?实际上是个天坑。因为所谓的提前准备好的1个到2个tick是服务器预测出来的!0关闭,1开启。一定要关闭!开启这个参数后,你会经常碰到这种情况,当你对着你的敌人扫射了半天,他没死,反而是你死了,然后当你看他的视角重放时,你会发现,从见面开始,你就已经被打死了,根本没来的急开一枪就死了。解释起来就是蝴蝶效应,我在未来,你在过去,你打死了过去的我,我在未来干的事情都没有发生过。
sv_parallel_send 这里我想先试图解释一下“假身外挂”,什么是“假身外挂”?看过相关视频的网友就会明白,这个挂通过某种方式让你打不中他,哪怕你是自瞄,他静静的站在那不动,你也打不中他。不是大陀螺!那又是另外一种原理。那么这个“假身外挂”是如何做到欺骗服务器的呢?首先欺骗服务器这样的操作是难以办到的,假设我开一个“假身外挂”,我会把我自身的运动状态等相关信息发送给服务器,就算通过“假身外挂”上传假的信息给服务器,但是只要服务器认定这是真的,那么它就是真的,不可能欺骗的了服务器。服务器再把这些信息发送给其他玩家,其他玩家只要打中了,不管怎么样我都会掉血。所以不可能存在“假身外挂”这种挂。但是它真的存在!?所以我大胆的推测,所谓的“假身外挂”使用者的客户端会同时发送2份数据出去,一份给服务器,一份给其他玩家。两份数据中有一份是假数据。这就和我接下来要讲的参数有关了。
对于sv_parallel_send这个参数的官方解释是:是否允许客户端并行接收服务器和其他客户端同时发送的数据。0关闭,1开启。我认为当设置该参数为1时,我的客户端会同时接收(并行接收)来自服务器以及其他客户端发送的信息,哪一份数据的延时更小,loss更少,就优先使用哪一份数据绘制画面。这样做的目的是为了缓解服务器的压力,同时也能降低玩家的延迟,还能使得画面更加平滑流畅,缺点是耗费更多的cpu资源。当设置该参数为0时,我的客户端只接收服务器发送过来的数据,其他客户端发送过来的数据一概不认。根据这个思路,我分析假身挂的原理是这样的:开挂者利用外挂修改客户端发往服务器的数据,人为的使延迟和loss增高,同时开挂者的客户端也会向其他玩家的客户端发送未修改过的原始数据。因为修改过发往服务器的数据延迟高,loss多,再经过服务器转发给其他玩家时会耗费更多的时间,所以其他玩家的客户端会优先选择低延迟、低loss由开挂者客户端直接发送的数据,而不选择经服务器转发的高延迟、高loss的数据。但是两份数据哪一份才是实体只由服务器说了算,高延迟、高loss的那份数据被服务器认证过,反而算作玩家真实位置,而低延迟、低loss的那份数据未被服务器认证过,与被认证过的数据存在较大的延迟偏差,导致受害者玩家看到虚假画面,难以打中目标真身。建议设置为0,可以对假身挂使用者起到一定程度的限制。如果房间内没有假身挂使用者,建议设置为1,可以使画面更加顺滑。
sv_parallel_packentities 这个参数的官方解释是:是否允许客户端并行接收服务器和其他客户端同时发送的实体数据。0关闭,1开启。建议设置为0,可以对假身挂使用者起到一定程度的限制。如果房间内没有假身挂使用者,建议设置为1,可以使画面更加顺滑。
sv_parallel_sendsnapshot 这个参数的官方解释是:是否允许客户端并行接收服务器和其他客户端同时发送的连续照片。0关闭,1开启。建议设置为0,可以对假身挂使用者起到一定程度的限制。如果房间内没有假身挂使用者,建议设置为1,可以使画面更加顺滑。
玩美服偶尔碰到过几次假身外挂使用者,很搞笑的是他对我好几次都能打中他,甚至一枪爆头感到非常好奇,甚至好几次故意出现在我面前不开火就是为了让我能打他。他蹲着不动让我打,或者移动中让我打。修改防假身外挂参数后,假身外挂蹲着不动那就是靶子一样。移动中比较难打,因为他看上去就是那种走路一卡一卡的掉帧玩家,俗称卡B,估计是把假身功能拉满了让我测试,认真点瞄准还是能打死的。
cl_predict 是否执行客户端预测。0关闭,1开启。最佳值应该是1。为什么我说是应该呢?因为在cs1.6以及cs起源中这个参数都是要开启来保证玩家的最佳体验,但是在csgo官匹服务器中却强制关闭了该功能(锁定为0)。也许是csgo的游戏引擎足够强大已经不需要这种老旧的功能了吧?或者是因为游戏引擎中有其他优化办法能替代这种功能?不得而知了。而平台和社区服务器未对该参数进行限制,部分玩家称在这些服务器开启该参数后,感觉游戏都变的丝滑流畅更有代入感了。该参数我设置为1(cl_predict 1),官匹服务器要强制锁定为0那是官匹的事,至少在进入其他平台服务器时,不用我去单独修改它。
cl_predictweapons 是否执行客户端武器状态的瞬间预测,如开火、换弹、切换武器等一系列动作。0关闭,1开启。最佳设置值为1。
sv_force_transmit_players 强制服务器或其他玩家的客户端向你传输游戏角色的实体数据。0关闭,1开启。实体数据的传输会耗费大量的带宽,对网络延迟的要求也非常苛刻。所以在互联网模式下还是不要想了。互联网模式下强制开启会造成实体数据大量丢失,而在此基础上绘制出来的游戏画面更是严重滞后,哪怕把延迟补偿功能拉到最大值也救不了。但是在局域网模式时可以试一试。前面说过你设置的rate值只会在局域网联机对战时起作用,在互联网模式下不起作用。在互联网模式下,csgo客户端所获得的数据量的多少完全是由服务器决定的,客户端没有设置选项。看看csgo的rate最大可以设置为多少?786432比特!看看cs1.6或者是和csgo区别不大的cs起源,rate值分别为最大值20000比特和默认值30000比特。到了csgo,好家伙,数据流量上限值直接多了25倍啊!达到了惊人的786432比特!为什么csgo的rate上限值会这么巨大?游戏时真的有全部用到吗?很显然,这是为了传输实体数据才设置这么巨大的上限值的。所以对于sv_force_transmit_players这个参数,互联网模式下建议关闭,设置为0,局域网模式下可以试试开启。同时把rate值拉到最大786432比特。
sv_force_transmit_ents 强制服务器或其他玩家的客户端向你传输除了游戏角色以外的其他物体的实体数据,比如可以被子弹打飞的物体、可以被炸弹炸飞的物体、鸡、尸体、火焰、爆炸、血迹等等。0关闭,1开启。对于sv_force_transmit_ents这个参数,互联网模式下建议关闭,设置为0,局域网模式下可以试试开启。同时把rate值拉到最大786432比特。
sv_clockcorrectionmsecs (在cs1.6中参数cl_fixtimerate有着和它同样的作用。)这个参数也是我能在美服顶着250ping虐菜的关键。一般情况下,客户端会立即把接收到的数据转换成画面。sv_clockcorrectionmsecs这个参数的存在,让情况有所改变。假设我把它设置为400毫秒,会导致我的客户端滞后个400毫秒才开始转换画面。故意制造人为延迟?为什么?只因为各个玩家网络延迟的不同,导致他们并不会在同一个时刻上玩游戏,有的高ping玩家开枪打你的信息因为延迟,还没到你这边。你就已经把收集的信息转变成画面了,你会漏掉很多细节。例举2个很多人都遇到过的实例:
1. 枪林弹雨中我冲向掩体,躲了进去,暗自庆幸捡回了一条小命,忽然我身体被拉回到了掩体外,死了!什么情况?因为有个高ping玩家,他开枪射杀了半秒前的我,那时我正在跑向掩体。因为延迟补偿的原因,服务器判定为成功击杀,并重新向我发送了变化后的数据。是不是感觉被回溯了?是不是有点不爽?
2. 我背对着一个敌人从高处跳下,并向前跑动了一段距离躲进了掩体,心里寻思着:很好,没有人打我,满血无伤,忽然间我的身体被拉回到了半空中,死了!Why?空中打鸟!太过分了!回溯!
在例举的这2个实例中,我们不难发现,敌人在攻击我时,我是完全不知道的!因为敌人延迟高,他那边在攻击过去的我。而我这边显示我已经跑到安全位置。是不是有点像《终结者》这部电影?杀死过去的约翰·康纳,未来的约翰·康纳也会消失。如何避免这种情况?
假设我让我的客户端延迟一段时间,等到把所有玩家发过来的信息全都收集齐后,再把这些信息转换为游戏画面,多出来的延迟使用延迟补偿功能来弥补,是不是可以减少被回溯的可能呢?不仅可以减少被回溯的可能,反而使其他玩家会被我回溯,相当于合法回溯。这就是sv_clockcorrectionmsecs这个参数的真正作用了。设置该参数值为多少最佳呢?假设房间内有一堆玩家,找延迟最高(不包括你自己)的那位:玩家A,延迟200毫秒。再看自己的延迟,延迟50毫秒。把2者相加就是该参数的最佳设置值,保险起见,在此基础上再加上个50毫秒。因为网络延迟有时候会忽高忽低,而且其他人都是默认设置30ms,尽量给它设高点。
我在美服250ping的情况下把它设置为0过,然后那些敌人移动就像是瞬移一样,转角忽然瞬移一个敌人出来把我打死,根本反应不过来。设置成350,情况好多了,敌人走路正常了,画面平滑了不掉帧了。通过设置该参数,我顶着250延迟玩美服,经常能碰到一些搞笑画面。比如:我和敌人对枪,我被打死后过了半秒,敌人忽然被不明来路的子弹打中,吓得他左顾右盼,就是不知道谁打的他。其实是我死之前打的他,只不过延迟比较高,他把我打死后,才反馈给他中弹信息。还有一次,我看见一个敌人正从平台上往下跳,我就顺手点了几枪,他都落地后跑出有5米远了,画面突然一变,他被瞬间拉回到了空中,挂了。气的这个老外打字:fk noob backtrack!我打字:sorry,i am 300ping。老外:300ping!really?
正确设置sv_clockcorrectionmsecs,让高ping玩家不在能回溯你,除非有人开回溯挂才能回溯你。这里我想到了一个题外话,csgo的假身外挂和回溯外挂是不是csgo的开发人员制作的?为什么刚好和这些参数有关系?非常可疑哦。
cl_clockdrift_max_ms 允许客户端与服务器之间时钟漂移的最大值,默认值150毫秒。默认值150毫秒将会对延迟补偿功能以及客户端自带的回溯功能造成不良影响,因为你的延迟很可能大于150ms,或者你设置的回溯时间大于150ms。建议把设置改成1000毫秒。设置成1000毫秒并不会真的使延迟增加,只是允许时钟漂移最多能达到1000ms,上限值好像就是1000ms,至少要和延迟补偿功能的最高时长1秒钟一致。
cl_clockdrift_max_ms_threadmode 在线程模式下【(threadmode)不懂什么叫线程模式,可能是指局域网模式,与之对应的有一个online-mode,即互联网模式】,允许客户端与服务器之间时钟漂移的最大值,默认值0毫秒。cl_clockdrift_max_ms_threadmode这个参数的系统默认值0毫秒将会对延迟补偿功能以及客户端自带的回溯功能造成不良影响,因为你的延迟一定大于0ms,或者你设置的回溯时间也是大于0ms的。建议把设置改成1000毫秒。设置成1000毫秒并不会真的使延迟增加,只是允许时钟漂移最多能达到1000ms,上限值好像就是1000ms,至少要和延迟补偿功能的最高时长1秒钟一致。
sv_reservation_tickrate_adjustment 无法用言语解释,只能描述看到的画面会有何不同。假设我延时比较高,用awp瞄准了运动中的敌人头部开枪,并且服务器判定为爆头,设置该参数为0时,会看到敌人身体忽然被瞬间拉回到中弹位置,倒地死亡;设置该参数为1时,会看到敌人继续跑动一段距离后,身后飚血,倒地死亡。左思右想,反正服务器已经判定敌人中弹身亡,多跑动一段距离才倒地和拉回中弹位置倒地对最终结果都没有影响,表面上看这个参数存在的意义不大,但是csgo不像cf或csol那样,你打死一个敌人后会瞬间弹出个提示音或提示图标提示你敌人已经被击杀。也就是说如果运动状态下敌人死亡后尸体会惯性向前移动一段距离,会造成玩家的错误判断,他还没死,继续追枪,浪费子弹。但是如果尸体瞬间拉回中弹死亡位置,虽然看上去很突然,但是相当于给了你一个类似提示音或提示图标的击杀反馈,你也会立即停止追枪,减少子弹耗损,更有高手已经将枪口指向其他目标了。所以建议0。
sv_reservation_timeout 和上面的参数有关,最小值5ms,最大值180ms。当上面那个参数设置为1时,设置该参数为100,你的网络延迟低于100时,你看到运动中的敌人被爆头都是瞬间被拉回到中弹位置倒地死亡,你的网络延迟高于100ms,你看到运动中的敌人被爆头都是身后飚血后继续跑动一段距离倒地死亡。该参数存在的意义不大,建议设置为180,
sv_maxunlag 延时补偿的时长。默认值0.2秒,最大值为1秒。当然要设置成最大。设置成最大没有坏处,只有好处。这个参数就是限制亚洲人跨区去欧服或美服的关键参数之一。很多人抱怨csgo延迟超过200毫秒就没法玩了,并且还称游戏这么设定的原因就是为了防止亚洲科技玩家去虐待欧美绿色玩家。
sv_maxusrcmdprocessticks 为了防止玩家在过去的,离现在非常久远的时间刻度上玩游戏,以获得不光彩的竞争优势,客户端会自动丢弃过去的,距离现在非常久远的时间刻度上的tick。如果某个tick所在的时间刻度距最新接收到的tick所在的时间刻度超过该设置值,它将会被丢弃。默认值16,建议设置为999999。
sv_max_dropped_packets_to_process 为了防止玩家在过去的,离现在非常久远的时间刻度上玩游戏,以获得不光彩的竞争优势,当接收到的数据包超过一个定值时,客户端就会自动丢弃最先前接收到的数据包,以保持暂存的数据包不超过该定值。默认值10,建议设置为999999。
net_graph 用来查看ping、fps、loss、choke、var等数据。0关闭,1开启。被官匹服务器限制了,只允许使用0和1,大厅界面可以使用2。
sv_alternateticks 使用谷歌直接翻译为:替代tick,进一步可以理解成用模拟的tickrate把原始的tickrate给替代掉。估计指的是客户端刚接收到原始的tick后,转换成画面需要耗费几毫秒甚至十几毫秒的时间,主要是电脑性能所决定的,这会造成一种画面迟滞感。设置该参数为0时,假设客户端将原始tick转换成画面需要耗时30ms,那么客户端会预测出30ms以后的画面,并直接显示30ms以后的画面,这样就降低了画面迟滞感。设置该参数为1时,只有在原始tick为偶数时,才会起预测作用,奇数则不起作用。也就是间隔一个tick预测才会生效,类似于汽车刹车ABS抱死系统。这样可以防止客户端对画面进行过度预测,同时可以确保画面延迟感有所降低。设置该参数为2时,完全禁止该功能,画面会比较卡,但是客户端显示画面是与服务器端的真实画面完全一致。在澳洲服实测表明,关闭该功能会比开启该功能打的更准,特别是对移动中的敌人,开启该功能后瞄头打容易空枪,关闭该功能后敌人运动画面看上去虽然会卡一点,但是不容易空枪。有没有可能又是因为这个参数sv_lagcompensateself 被强制锁定在0,导致游戏不能对因设置带来的额外延迟进行补偿,才导致的空枪。该参数默认值为0,建议设置sv_alternateticks 2。
sv_forcepreload 开启服务器预载,进入游戏时能加快地图的载入,减少等待过程。实际作用不大。0关闭,1开启。
cl_forcepreload 开启客户端预载,进入游戏时能加快地图的载入,减少等待过程。实际作用不大。0关闭,1开启。
cl_resend 连接中断时,客户端向服务器请求重新连接的次数。实际作用不大。设置为5次吧。
viewmodel_fov 调节第一人称的视野范围大小,最小可以设置为54,最大可以设置为68。大范围能让人视野更加开阔,小范围能让人注意力更加集中。都是1080的显示器吧?建议设置为68。
r_drawmodelstatsoverlay 设置为1时,只对可见物体进行渲染。设置为0时,全部渲染。建议设置为0。因为有几次我玩csgo时,在延迟非常高的情况下,我贴着墙壁干拉出去,你知道我看到了什么吗?敌人的模型甚至都没有加载出来,而是过了0.1秒才凭空出现。这样是非常影响的。当我把r_drawmodelstatsoverlay建议设置为0后,好像就没有出现过类似情况了。
mp_footsteps_serverside 设置0时,对敌人的脚步声音启用客户端预测。设置1时,只能使用服务器端的。但是这条参数更多的让我怀疑,并不是对声音的预测,而是动作的预测。因为csgo让我非常不适应的一点就是:人物的动作像是在漂移,太空步,有点像cf。回想cs1.6或者我修改过参数的csol,人物走路的动作看上去是那么的自然。这个怎么说呢。一个搏击选手能通过对手的瞬间运动状态来预判对手未来的动作,一个cs玩家也能通过敌人的脚步运动状态,瞬间预判出敌人未来的走向。但是在csgo中,我预判不出敌人未来的走向,敌人的移动显得是那么的不自然,前后左右移动毫无预兆,飘忽不定。录像放慢了看,我发现敌人的脚在地上漂移,敌人开始移动前,没有模拟出脚步用力登地的动作。所以我设置该参数为0,抱着试一试的心态,也许是错觉,我觉得我好像能预判敌人的动作了,至少看上去敌人移动显得比较自然,无论是左右横跳还是大跳还是急停。
为了节省大家的时间,我把我目前在使用的优化参数全都放在了最下面,有需要的可以直接拷贝使用。
使用方法:首先找到csgo中的config文件,复制一份并改名为a,打开文件a,将下列参数复制好后粘贴在最下面(64tick和128tick别搞错了),为了保险起见,在最下面再粘贴一次。把文件a放在config文件所在目录内。每次进入游戏大厅时,客户端都会自行加载默认的config文件。这时打开控制台输入exec a,手动加载文件a,就加载成功了。不行多输入几次exec a,多加载几次。
特别注意:只有这条参数sv_clockcorrection_msecs 只能进入房间开始游戏后,才能手动设置。sv_clockcorrection_msecs=房间内除你之外延迟最高的玩家的延迟+你的延迟+50毫秒。毕竟,没有人能在开始游戏前就知道自己和他人的延迟是多少。
首先是64tick:
cl_updaterate "64"
cl_cmdrate "64"
cl_lagcompensation "1"
sv_lagcompensationforcerestore "1"
sv_lagcompensateself "1"
fps_max "300"
fps_max_menu "300"
net_threaded_socket_recovery_time "15.625"
net_threaded_socketrecoveryrate "2400"
net_threaded_socket_burst_cap "1200"
net_splitrate "2"
cl_interp "0.015625"
cl_interp_ratio "1"
cl_interpolate "1"
sv_enable_deltapacking "0"
sv_parallel_send "0"
sv_parallel_packentities "0"
sv_parallel_sendsnapshot "0"
cl_predict "1"
cl_predictweapons "1"
sv_force_transmit_players "0"
sv_force_transmit_ents "0"
sv_clockcorrectionmsecs "30"
cl_clockdrift_max_ms "1000"
cl_clockdrift_max_ms_threadmode "1000"
sv_reservation_tickrate_adjustment "0"
sv_reservation_timeout "180"
sv_maxunlag "1"
sv_maxusrcmdprocessticks "999999"
sv_max_dropped_packets_to_process "999999"
net_graph "1"
sv_alternateticks "2"
sv_forcepreload "0"
cl_forcepreload "0"
cl_resend "5"
viewmodel_fov "68"
r_drawmodelstatsoverlay "0"
mp_footsteps_serverside "0"
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
分割线♥♥♥♥♥♥♥分割线♥♥♥♥♥♥♥♥分割线
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
然后是128tick:
cl_updaterate "128"
cl_cmdrate "128"
cl_lagcompensation "1"
sv_lagcompensationforcerestore "1"
sv_lagcompensateself "1"
fps_max "300"
fps_max_menu "300"
net_threaded_socket_recovery_time "7.8125"
net_threaded_socketrecoveryrate "1200"
net_threaded_socket_burst_cap "1200"
net_splitrate "1"
cl_interp "0.0078125"
cl_interp_ratio "1"
cl_interpolate "1"
sv_enable_deltapacking "0"
sv_parallel_send "0"
sv_parallel_packentities "0"
sv_parallel_sendsnapshot "0"
cl_predict "1"
cl_predictweapons "1"
sv_force_transmit_players "0"
sv_force_transmit_ents "0"
sv_clockcorrectionmsecs "30"
cl_clockdrift_max_ms "1000"
cl_clockdrift_max_ms_threadmode "1000"
sv_reservation_tickrate_adjustment "0"
sv_reservation_timeout "180"
sv_maxunlag "1"
sv_maxusrcmdprocessticks "999999"
sv_max_dropped_packets_to_process "999999"
net_graph "1"
sv_alternateticks "2"
sv_forcepreload "0"
cl_forcepreload "0"
cl_resend "5"
viewmodel_fov "68"
r_drawmodelstatsoverlay "0"
mp_footsteps_serverside "0"