3) Да - больше инпутов, больше и объем данных. Но зависимость тут не совсем линейная так как мы отправляем и другие данные + заголовки UDP-пакетов тоже занимают место.
Если сообщения при стрельбе сейчас идентичны тикрейтовым и там есть что то избыточное, их можно порезать до необходимого минимума, хотя, думаю, уже сделано.
Кстати о других данных, может ли BattlEye грузить аплоад канал во время матча? Вообще, с удовольствием бы посмотрел целиком, что на компьютере генерирует лишний аплоад (видимо именно с ним у меня проблемы), но не знаю подходящего софта.
Кроме того, по пингам и winMTR ничерта не видно, что происходит, задержался ли аплоад или даунлоад, где, на сколько и тд. Если посоветуете хорошую софтинку для вышеописанного анализа сети, буду премного благодарен.
4) 500 мс.
Мышку откатывало чаще, насколько могу судить по памяти на глаз.
Допустим потерялось 2 сообщения в моменты времени 50мс и в 250мс, в 550 мс было решено делать ресинк, и сразу после ресинка (или в его процессе) обнаружилась потеря сообщения 250мс. Может ли быть второй, некорректный, ресинк из-за этого?
Если я правильно понимаю, ресинки принципиально не должны происходить чаще, чем 500+время_на_ресинк мс.
И вроде в дни стабильно плохого коннекта я примерно это и вижу.
А что у вас за соединение можете сказать? 3g-модем?
Да, использую режим 3g (4g здесь ловит хуже). В дни, когда связь объективно плохая, из за погоды например, вопросов никаких нет.
То, о чём я писал, происходило в дни с хорошим коннектом именно в нескольких боях, или после длительной игры, и выглядело несколько иначе, чем когда стабильно плохой коннект.
Можете после выхода 0.50 прислать мне на почту журнал вашего матча? Попробую выяснить что приводит к этой ситуации.
Сделаю. Если повторится ситуация с частыми микрооткатами мыши, даже 0.50 не дождусь :)
Другое дело, что играть пока не тянет.
Всё думаю о преимуществах отправки абсолютного положения камеры вместо относительного.
Мне кажется, одни плюсы, при потере будет известна правильная позиция камеры после первого же прошедшего сообщения, в примере выше, про 50 и 250мс, при ресинке позиция камеры на клиенте и сервере уже автоматически будут совпадать, тк в сообщении 500 мс она корректна, нужно только будет подвинуть тело, и если потерь за эти 500 мс было мало, то и смещение в пространстве будет меньше. Значительно меньше, я бы сказал на порядок меньше, чем сейчас.
Попробую еще пример привести:
Персонаж бежит вперёд (W), и поворачивался вправо на 90% в течении 500 мс
Сообщение в 0 мс было потеряно, остальные прошли. В 500мс ресинк.
Текущая реализация:
Потеря 9% в первом сообщении, и все 500 мс персонаж на 9% смотрит (и как следствие, бежит) не туда.
Итого все 500 мс персонаж на сервере бежит не в том направлении, куда на клиенте
Предлагаемая реализация:
Потеря 9% в первом сообщении, дальше угол выставляется корректным, и с 50 мс персонаж бежит туда же, куда и бежал на клиенте. В результате в 10 раз меньше времени направление движения различны на клиенте и сервере, с вытекающим различием в разбросе положений на момент ресинка.
Кроме того, при таком подходе задержку до ресинка можно сделать значительно меньше, и это даст больше плюсов, чем минусов. Меньше откатов смертей и прочих ужасов. Ресинк станет из кошмара чем то рядовым и слегка неприятным.
По позиции персонажа я понимаю, почему абсолютную нельзя использовать, читеры, плавающие через стены и спидхаки, но с камерой, мне кажется, читерам ничего это не даст. У нас же нет ситуаций в игре, чтобы окружающая среда запрещала поворот на какой-либо градус. В читах ничего не стоит рассчитать смещение камеры вместо абсолютной позиции, ведь доступ к текущей позиции у него уже будет, если он так далеко зашел, или же ему сдвига будет и так достаточно, чтобы навестись, если он экран анализирует.
Вопросы:
Есть ли сейчас понятия "частичного ресинка" и "полного ресинка", если да, в чем разница?
Как именно работает ресинк? Я представляю себе отправку позиции и направления камеры всех персонажей с сервера к одному из клиентов, и установку их на нём.