Я так понял многие скиллистые бойцы используют твикер Usersettings.con
Можно назвать это читерством? Мое мнение, что нет. Все более или менее хорошие игроки в КОД4 используют не дефолтные настройки конфиги и это правильно. На то он и конфиг чтобы его настраивать. Если в программе заложена возможность настройки некоторых параметров, то почему ими не воспользоватся? Предлагаю вашему вниманию труд некого бойца под ником ALEX. Если будете себя хорошо вести дам ссылочку на полный пост Почитав пару статеек по поводу клиент-серверного общения в играх могу высказать своё мнение о этих настройках.
Чтобы не было читеров и подмены информации о попаданиях и повреждениях вся инфа подобного рода и весь игровой мир обсчитывает сервак. Из-за того что между ним и клиентом существует задержка в передачи инфы используют 3 основных механизма коректировки. Компенсация задержки, интерполяция и экстраполяция.
GSDefaultLatencyCompensation 0.100000
Вы посылаете пакет на сервак о том что выстрелили челу бегущему за угол прямо перед самым углом в хэд. Сервак получил от этого чела (бегущего за угол) инфу о его положении раньше вашей тк допустим у него лучше пинг. Однако благодаря компенсации "лагов" сервак берёт из текущего положения спрятвшегося за углом чела вычитает время компенсации и определяет где он был в прошлом в момент вашего выстрела. таким образом сервак откатывает реальное положение бедалаги за углом и засчитывает уме хиты. Те чел с плохим пингом при правильной настройки компенсации получается попадает в того у кого пинг лучше. это вызывает парадокс для чувака с хорошим пингом который спрятался за угол и он в шоке от того что его убили а для чела с плохим пингом всё вроде бы и в норме - он убил гопника ещё до угла. Отсюда вывод - это значение должно быть равно вашему пингу.
Работу этого параметра явно видно из ролика где чуваки бегущие параллельно среляюют друг в друга слегка ссзади и убивают. Это значит что он снимали этот ролик на серваке где имеют пинг меньший 100 а это значит что исходя из дефолтного конфига сервак делает откат модели игрока в прошлое на 100мс но! в реале надо было сделать откат не так сильно а допустим на 60мс (при пинге 60) - вот и получается что чел стрелять должен чуть назад.
GSExtrapolateFrame 0
значение либо 0 либо 1. 1 значит включить учёт экстраполяции а 0 значит забить на неё.
GSExtrapolationTime 1200
это метод борьбы с потерями пакетов. допустим вы при игре лаганули и ваш комп недополучил пакетик с координатами врагов и их моделями на карте. чтоже тогда врубается механизм экстраполяции и ваш клиент (ваша тачка) пытается достроить положение врага методом предсказания его перемещений основываясь на последних пакетах полученных с сервака (координаты, скорость , вектор движения и тд). думаю многие замечали как при зависании коннекта в игре машинка к приеру вылетает за область дороги и взлетает в небеса. когда те или иные объекты основываясь примерно на своём предыдущем движении начинают двигаться по той траектории куда они двигались раньше и клиент при этом даже не додумывает что танк не может летать =). значение данного параметра говорит о том в течении какого периода времени в мс ваша машина будет предсказывать будущее положение объектов на карте. ставить много это равносильно тому что ваш компрьютер в итоге при больших лагах в конекте предскажет вам что ваш враг улете на танке в облака. маленькое значение не вызовет таких глюков но тогда будут лаги связанные с потерей пакетов и картинка на вашей машине уже будет обновлятся только после получения инфы с сервака те рывками.
GSInterpolationTime 100
компы как правило держат фпс на высоком уровне ( к примеру 50фпс что соответствует 50 обновлениям в секунду) и канал инета не поспевает за этим. получается что для фпс 50 надо иметь пинг в 50 обнослений в секунду те 20мс. а если у меня видео легко держит 100фпс то пинг равен 1мс =). отсюда следует применение интерполяции, те предсказание положения врагов для сглаживания картинки. те получается что прежде чем вам видюха отрендерит модель игрока ваш комп 2 раза обратится к серваку и потом ваш проц просчитает промежуточное положение модели между двумя обращениями которое ваша видюха собственно и отрендерит. те получается что реально вы получили все данные о игроке в моент времени Х потом получили данные в момент времени Х + дельта равная времени задержки через которое пришёл второй пакет. потом основываясь на этих данных ваш проц предсказывает плавную траекторию модели игроков врага на серваке и их движение. те этот параметр должен быть как минимум равен вашему пингу или меньше той планки до которой может ваш пинг упасть. ставить параметр ещё ниже не смысла тк ваш пинг не даст вам возможность сократить время между двумя пакетами (время интреполяции) менее чем время на прохождение физичски пакетов. в идеале должно совпадать с вашим пингом и с DefaultLatencyCompensation. если пакет всё же теряется то врубается компенсация данных потерянных а именно механизм экстраполяции - предсказания содержимого потерянного пакета. после получения очередного пакета ошибки предсказания будут устранены сервером. наверно замечали как вроде бы вы прошли вперёд как вдруг при лагах вас сервак возвращает почти в ту же позици где вы и были. всё это происходит при резком подскоке пинга и сопровождается лагами и дёрганьями (каждый раз ваш клиент основываясь на корректировках серваком ваших неверных предсказаний правит положение моделей). Ещё думаю видел как вас удивают из промежуточного положения (чел ещё не лежит но уже и не стоит) хотя это как бы и не возможно.
всё это тока моё имхо и мои догадки так что на истину не претендует. особенно мне не понятно почему при дефолтном GSExtrapolateFrame 0
всё равно есть экстраполяция - те неверные предсказания объектов на карте при проблеме с коннектом. возможно либо существуют ещё и другие скрытые механизмы в бф2 отвечающие за это либо я не верно понял смысл этого параметра. второе что меня смущает это почему при подскоке пинга и лагах идёт корректировка именно вашей модели тоже и вы видете лаги и дёрганья - мне казалось что экстраполируются все модели кроме ваших тк о вашей модели сервак узнаёт от вас и ваших командах отданых ему. возможно это связанно с тем что сервак просто не может так резко переместить вашу модель вперёд ( крпимеру вы шли вперёд в моент подскока пинга) и основываясь на последних данных от вас и новых данных коректирует ваше положение в промежуточное между тем что было до подскока пинга и тем что вы видели на вашей стороне клинета.
кароче я хз чё ваще это такое =)
кто знает поправьте.
читал вот тут http://developer.valvesoftware.com/wiki/Lag_Compensation и вот тут - http://www.valve-erc.com/srcsdk/general/mu...networking.html