Hit Fixer
Чтобы не было читеров и подмены информации о попаданиях и повреждениях, вся информация подобного рода подсчитывается сервером. Из-за того, что между ним и клиентом существует задержка в передачи информации, используют 3 основных механизма коректировки. Компенсация задержки, интерполяция и экстраполяция.
GSDefaultLatencyCompensation 0.100000
Вы посылаете пакет на сервер о том, что выстрелили игроку, бегущему за угол прямо перед самым углом, в хэд. Сервак получил от этого игрока (бегущего за угол) информацию о его положении раньше вашей, т.к. у него лучше пинг. Однако, благодаря компенсации "лагов", сервак берёт из текущего положения спрятавшегося за углом чела, вычитает время компенсации и определяет где он был в прошлом, в момент вашего выстрела. Таким образом сервак откатывает реальное положение бедалаги за углом и засчитывает уме хиты. Т.е. игрок с плохим пингом, при правильной настройке компенсации получается попадает в того у кого пинг лучше. Это вызывает парадокс для игрока с хорошим пингом, который спрятался за угол и он в шоке от того, что его убили, а для игрока с плохим пингом всё вроде бы и в норме - он убил гопника ещё до угла. Отсюда вывод - это значение должно быть равно вашему пингу.
Работу этого параметра явно видно из ролика, где бегущие параллельно игроки среляют друг в друга слегка сзади и убивают. Это значит, что они снимали этот ролик на серваке, где имеют пинг меньший 100, а это значит, что исходя из дефолтного конфига сервак делает откат модели игрока в прошлое на 100мс но! в реале надо было сделать откат не так сильно, а допустим на 60мс (при пинге 60) - вот и получается что игрок стрелять должен чуть назад.Добавлено (07.09.2011, 15:50)
---------------------------------------------
GSExtrapolateFrame 0
Значение либо 0 либо 1.
1 - включить учёт экстраполяции, а 0 - забить на неё.
GSExtrapolationTime 1200
Это метод борьбы с потерями пакетов.
Допустим, вы при игре лаганули и ваш комп недополучил пакетик с координатами врагов и их моделями на карте. Тогда включается механизм экстраполяции и ваш клиент пытается достроить положение врага методом предсказания его перемещений, основываясь на последних пакетах полученных с сервака (координаты, скорость, вектор движения и тд). Думаю, многие замечали, как при зависании коннекта машинка вылетает за область дороги и взлетает в небеса. Когда те или иные объекты, основываясь на своём предыдущем движении, начинают двигаться по той траектории, куда они двигались раньше (клиент при этом, даже не подозревает, что танк не может летать =). Значение данного параметра говорит о том, что в теченииопределенного периода времени в мс, ваша машина будет предсказывать будущее положение объектов на карте. Ставить много, равносильно тому, что ваш компьютер, при больших лагах в конекте, предскажет вам, что ваш враг улетел на танке в облака. Маленькое значение не вызовет таких глюков, но тогда будут лаги, связанные с потерей пакетов и картинка на вашей машине уже будет обновлятся только после получения инфы с сервака т.е. рывками.
Добавлено (07.09.2011, 15:52)
---------------------------------------------
GSInterpolationTime 100
Компы, как правило держат фпс на высоком уровне ( к примеру 50фпс что соответствует 50 обновлениям в секунду) и канал инета не поспевает за этим. Получается, что для фпс 50 надо иметь пинг в 50 обновлений в секунду т.е. 20мс. а если у меня видео легко держит 100фпс то пинг равен 1мс =). Отсюда следует, применение интерполяции, т.е. предсказание положения врагов для сглаживания картинки. Т.е. получается, что прежде чем вам видюха определит модель игрока, ваш комп 2 раза обратится к серваку и потом ваш проц просчитает промежуточное положение модели между двумя обращениями, которое ваша видюха собственно и отрендерит. Получается, что реально вы получили все данные о игроке в моент времени Х, потом получили данные в момент времени Х + дельта (дельта равная времени задержки через которое пришёл второй пакет). Потом, основываясь на этих данных, ваш проц предсказывает плавную траекторию модели игроков врага на серваке и их движение. Этот параметр должен быть как минимум равен вашему пингу или меньше той планки до которой может ваш пинг упасть. Ставить параметр ещё ниже не имеет смысла, т.к. ваш пинг не даст вам возможность сократить время между двумя пакетами (время интреполяции) менее чем на время прохождения
пакетов физически. В идеале, должно совпадать с вашим пингом и DefaultLatencyCompensation. Если пакет всё же теряется, то врубается компенсация данных потерянных, а именно механизм экстраполяции - предсказания содержимого потерянного пакета. После получения очередного пакета ошибки, предсказания будут
устранены сервером. Наверное замечали, как вроде бы вы прошли вперёд как вдруг, при лагах, вас сервак возвращает почти в ту же позицию, где вы и были. Все это происходит при резком подскоке пинга, сопровождается лагами и дёрганьями (каждый раз ваш клиент основываясь на корректировках серваком ваших неверных предсказаний правит положение моделей).
Добавлено (07.09.2011, 15:53)
---------------------------------------------
Мне не понятно, почему при дефолтном GSExtrapolateFrame 0 всё равно есть экстраполяция - те неверные предсказания объектов на карте при проблеме с коннектом. Возможно либо существуют ещё и другие скрытые механизмы в бф2 отвечающие за это, либо я не верно понял смысл этого параметра. Второе, что меня смущает это почему при подскоке пинга и лагах идёт корректировка именно вашей модели тоже и вы видете лаги и дёрганья - мне казалось что экстраполируются все модели, кроме ваших т.к. о вашей модели сервак узнаёт от вас и ваших командах отданых ему. Возможно, это связанно с тем, что сервак просто не может так резко переместить вашу модель вперёд ( к примеру вы шли вперёд в момент подскока пинга) и основываясь на последних данных от вас и новых данных, коректирует ваше положение в промежуточное между тем, что было до подскока пинга и тем что вы видели на вашей стороне клинета.
По этому можете убрать только траву. На таких картах как олеско это вам плюс. 
