Я думаю это происходит когда спавн игрока маппер вешает в воздухе, и он сначала опускается оригином до поверхности земли, а потом так и остается. У меня такое было в RazoR, когда я решил, что просчитывать физику каждый кадр это непозволительная роскошь.
marikcool походу про другой глюк говорит, когда игрок внешне (своей моделькой) оказывается вверху/внизу, вообщем смещается по Y оси и возвращается в свое нормальное положение когда изменит свое местоположение в этой же оси (подпрыгнет, присядет, поднимется, спустится).
В CS 1.6 такое бывает очень часто, помню что на www.amxx.ru было обсуждение проблемы, кто-то говорил, что проблема в потере некоторых пакетов с координатами от сервера к клиенту (UDP ведь).
тестил в лане, там потерь нет, вообщем игрок может провалиться до пояса там где я его спавню либо появиться в 0,0,0 , и может так находиться секунд 5-10.
ищу пример как хукнуть pfnClientCmd из client.dll, c целью заблочить ряд команд в движке.
вопрос про клиентские стволы, при посылке анимации есть параметр skiplocal который проверяет g_engfuncs.pfnCanSkipPlayer, то есть он не шлет анимацию игроку(владельцу), т.к на клиенке она сама играет?
marikcool писал: ищу пример как хукнуть pfnClientCmd из client.dll, c целью заблочить ряд команд в движке.
Ничего ты в движке не заблочишь, как ни крутись.
Цитата:
marikcool писал: вопрос про клиентские стволы, при посылке анимации есть параметр skiplocal который проверяет g_engfuncs.pfnCanSkipPlayer, то есть он не шлет анимацию игроку(владельцу), т.к на клиенке она сама играет?
Там корочи такая тема. Функция g_engfuncs.pfnCanSkipPlayer проверяет, является ли текущий игрок локальным и включена ли у него опция cl_lw.
Ну, можно в ксаше посмотреть.
Если включена - то анимация не шлется вообще - сервер надеется, что клиент её проиграет без его участия. На мой взгляд польза от этих клиентских оружий воще сильно сомнительная, потому что для её реализации данных на клиент засылается в 4 раза больше, нежели когда она выключена. К тому же информация о расходе патронов ЧСХ опять берется с сервера. То есть при сильном лаге можно долго стрелять и даже оставлять декали, а патроны расходоваться не будут.
я счас сделал полностью клиентский ствол, но только стрельба засылается сервером, получилось что декали там где надо , ну и левая стрельба во время лага не работает.
да если патроны с сервера берутся, вроде как через ammox сообщение, полезность клиентских стволов уменьшается) вообще зачем тогда синхронизировать патроны всех игроков включая свои, где реально у меня вышло полезность от этого только в одном месте с перезарядкой оружия чекнуть количество патронов.
идеально я думаю если все будет происходить на сервере, на клиенте только вся анимация стрельба/активация/идл/хостер/релоад без каких либо подсчетов и обработка декалей на сервере.
Добавлено 30-10-2011 в 18:49:
Цитата:
Дядя Миша писал: Ничего ты в движке не заблочишь, как ни крутись.
хочу сделать визуальное отображение нескольки оружий на игроке,
что выгодней атач или setbody?
второе легче в реализации, какие преимущества между ними? не считая того что в первом случае модель игрока ненадо переделывать каждый раз.
в тупой халфе - неудивительно. А я тебе про ксаш говорил. Убьешся, но не заблочишь. Правда это и не требуется, есть же сорцы. И можно всё сделать без извратов.
SZ_GetSpace: overflow on netchan->message
порядка 30-35 сообщений прокатывает, 50 уже нет.
попробую зафигарить в мотд контры метр текста, посмотреть прогрузит или нет.
есть ли в природе чистый вычищенный от всего client и mp dll ?, из логики оставлено только появление на инфо плаер спавне и базовое перемещение.
давно помню мне скидывали такой qwprogs.dat подчищенный от всего, хотел бы аналогичный для халфа.
marikcool писал: SZ_GetSpace: overflow on netchan->message
ну там буффер на 70 килобайт ориентировочно.
туда должно влезть:
1. персональные мессаги для конкретного игрока (MSG_ONE)
2. текущая дельта для всех энтить (для каждого игрока имеет разный размер, зависит от местоположения, состояния дельты, итд)
3. текущая дельта о состоянии игроков относительно текущего.
4. текущая дельта о состоянии оружия для предиктинга
5. текущая дельта о состоянии текущего игрока
6. зеро-компрессия для эвентов
7. все надежные мессаги для всех игроков (MSG_ALL), обычно остановка звуков, содержимое буффера signon при спавне.
8. если останется место - ненадежные мессаги (звуки, пользовательские MSG_BROADCAST).
Таким образом передавая 30-50 сообщений подряд, относительно контекста. в котором находится игрок (а так же значения rate) у нас остается определенное кол-во свободного места. Ну и если его не хватает, то понятное дело вылет.
Правда в хл, насколько я понял есть фрагментация пакетов, но, она срабатывает далеко не для каждой мессаги.
Вот в ку3 как было? там финальная мессага проверяется на размер сетевого буффера, который обычно равен размеру сетевого пакета (что-то около 1024 байта). И тогда сообщение бьется на пакеты и доставляется кусочками. А в халфе, вроде как разбиение на пакеты идет принудительно, только в потенциально узких местах.
в контровском мотд 1 байт с булевым значением для того чтобы ждать остальные куски либо трансфер завершен, с ограничеием буфера в 60 байт, зачем впринципе это делать если пакеты бьются сами? скорее всего в халфе они все таки не бьются автоматически по ~1024 байта.
да и скорее там еще меньше, диалап MTU 576 байт.
может когда буфер полный, остальное досылается в следущий тик сервера и тд пока все не отошлется.
26-10-2011 17:00
