high five Brawery - High Five

[Rozhek 7]

Наконец решил восполнить большое упущение и разместить тут темку. Сборка нацелена на копирование птс механик и эмулирование аспектов птс сервера.

Хроники: High Five Part5
Основной функционал:
Переработанные движки GeoEngine, GeoMoving, PathFind
максимальное сходство с птс сервером. точность и плавность перемещения соответствуют птс серверу. минимизированы проблемы десинхрона координат. отсутствуют проблемы с движениями в воде, застреваниями
Новый AI движок
аи мобов парсятся из птс скриптов(ai.obj). необходимые параметры нпц\спавна\скиллов парсятся из птс файлов. 95% мобов работают на этом аи, остальные 5%(рб и спец. скриптовые мобы) временно собраны из из птс скриптов вручную
Статы
статы игроков\мобов\скиллов\спавна\трансформы\аугментация и др. парсятся из птс файлов и используются в механизмах сервера
Квесты
все квесты собраны из птс скриптов. исправлены, протестированы и функциональны
Система виталити
формулы расхода, роста. бафа невита. банки виталити
Инстанс зоны и локации
пайлаки, камалоки, лабиринты. зал иллюзий. sod,soi,soa,hellbound,citadel,tuly,naia
Эпик РБ
статы. ai. скрипты спавна и взаимодействия с игроком
AI питомцев
Механика работы скиллов

Спойлер

докаст скиллов
перенакладывание баффов\дебаффов.
формулы расчета дмг, скорости атаки, скорости отката стрельбы из лука\арбалета, формулы наложения эффектов и их отмены
расчет позиции скиллов перемещения
видимость массовых скиллов(тунельные, массовые, массовые по цели, fusion)

Олимпиада
геодвижок исправляет повсеместные проблемы с геодатой. волны по птс. периоды получения\просмотра результатов\участия по птс
Осады и ТВ
Эмуляция птс поведения персонажа
взаимодействие с мертвыми целями. -порядок и правила использования действий(как передвижение, использование скиллов, выбрасывание предметов, юз сосок и пр.)

Дополнительные механизмы

Спойлер

-хербы в полях безмолвия\шепчущие
-кубки в мосе
-баф в соа\дв
-с виталити в дв
-полеты на грации
-лужи в хс

Оптимизация пакетной рассылки
Исправление кучи мелких багов
Формула расчета дропа

Дополнительный функционал:
Новая евентовая система. 
7 евентов массовых евентов в инстанс зонах. один абсолютно уникальный.
Системы GvG (автоматическая и турнирная)
с внешним видом EventMatch и расширенными возможностями по настройке
Скины
предметная система скинов(типа вставки камней внешнего вида как на оффе) сетов\оружия вместе с паком предметов
Примерочная
Функция autocp (за премиум\сертификат)
Уникальная панель настроек (cfg)
Pvp community board
Премиум баффер
Групповая вставка аттрибута
Система вознаграждения
за пвп, в евентах, за захват замков, геройство, убийство мобов
Объединение талисманов
Периоды выдачи геройства, запуска осад и тв
Cтатический респ эпик боссов
Быстрый релог для очистки кэша
Защита от внутриигрового спама
Модификатор статов
Боты

Поддержка
пока что поддержка сборки полностью бесплатная
критические баги, при появлении, правятся в моменте
остальные баги, правятся в порядке очереди(кто успел поработать со мной, думаю смогут подтвердить насколько оперативно все фиксится)
доработки(с общим функционалом) выполняются бесплатно в порядке очереди\сложности
доработки(с уникальным\обособленным функционалом)обсуждаются отдельно и оплачиваются по дог-сти(оплата фиксированаая за чел\часы, оценки более чем адекватные)

Дополнительные модули
имеется расширенный xmlrpc API для общения с сайтом
имеется поддержка защит smartguard, strix
в комплекте геодата подготовленная под серверный геодвижок
антибру и проксислайдер для логинсервера

Тестовый сервер: тык (внимание, патч с допами 400Мб)

Покупка
Цена 12.000
skype: jenyajkee

Изменено 20 марта, 2019 пользователем Rozhek

[Matey 229]

Продам исходники от этой сборки за 10к

[Link 72]

36 минут назад, Matey сказал:

Продам исходники от этой сборки за 10к

Не ну ты Г....Ноооо полное, создай отдельную тему и напиши, что продаёшь и зачем.

[Rozhek 7]

53 минуты назад, Matey сказал:

Продам исходники от этой сборки за 10к

смешная шутка)

п.с. форумчане - не ведитесь, к исходникам ни у кого доступа не было

Изменено 20 марта, 2019 пользователем Rozhek

[Khrome 276]

Голый жтс + кастом. Кроме импортов - что изменилось? Ворклог нормальный приложите.

[Matey 229]

15 минут назад, Khrome сказал:

Голый жтс + кастом. Кроме импортов - что изменилось? Ворклог нормальный приложите.

думаю этот калека даже импортов не менял ))

2-3 фикса и в дамках ))

[Rozhek 7]

6 часов назад, Khrome сказал:

Голый жтс + кастом. Кроме импортов - что изменилось? Ворклог нормальный приложите.

Вы заходили на тест? Раздел функционал в описании разве похож на жтс? 

Ворклог с 2014 года сюда не влезет. Но я постараюсь, сделаю какой то скомпонованный вид и приложу

и версию патча поменьше тоже

Изменено 21 марта, 2019 пользователем Rozhek

[Aslan 131]

давайте уже в шару кидайте, не получилося, не фортануло

[Khrome 276]

10 часов назад, Rozhek сказал:

Вы заходили на тест? Раздел функционал в описании разве похож на жтс? 

Ворклог с 2014 года сюда не влезет. Но я постараюсь, сделаю какой то скомпонованный вид и приложу

и версию патча поменьше тоже

1 в 1, в фулл версии жтса ( не шаре) это все есть

[Rozhek 7]

Я конечно понимаю, что в текущих реалиях пост от участника с 10 сообщениями не вызывает доверия.

И вы не обязаны выискивать информацию обо мне и этой сборке на других форумах.

Но я все же ожидал более аргументированных комментариев,  не говоря уже об оскорблениях

Спойлер

Геодвижок:

[x]Реорганизация гео-движка. Перемещение осуществляется по всем точкам мира, а не только центрам гео-клеток. off-like
[x]Исправление расчета конечной позиции при движении и атаке. Расчет точно в точку назначения. off-like
[x]Исправление построения пути. Повороты в пути должен быть симметричны относительно начала и конца пути. off-like
[x]Фикс. Исправлено положение z при нахождение в воде.
[x]Фикс. Исправлена проблема провала под дно.
[x]Фикс. Убрать затуп при выходе из воды

Монстры:

[x]Переписан AI движок мобов. Маги бьют только магией при наличии мп, файтерам изменены шансы выбора используемого скилла off-like
[x]Доработан AI heal, buff мобов. А также баф соц. группы off-like
[x]Исправление реюз скиллов мобов off-like
[x]Реализованы кубки в мосе. off-like
[x]Коррекция скриптов инстанс и эпик РБ. Добавлены недостающие скиллы. Реализация off-like
[x]Исправление драгон хантеров. Должны спавнить дракосов.
[x]Правильный ai круга. off-like
[x]Добавлены бегающие дракончики и гемдрагоны в дв.
[x]Исправлен AI жуков в фоге
[x]Исправлен AI баюма. Ангелы бьют баюма, если не заагрены игроками. off-like
[x]Фикс. Миньоны не могут быть чемпионами
[x]Увеличена дистанция телепортации мобов. На улице, под землей, в инстах. Добавлен конфиг off-like
[x]Переделан механизм расчета мульти дропа из одной группы. Исправляет выпадение одинаковых вещей.
[x]Фикс. СА после 10 лвл качается без квеста. off-like
[x]Фикс. У закена должен стоять невидимый нпц. Должен получать дмг. off-like
[x]Исправлены лабы. Матка спавнится рандомно, мобы в лабе спавнятся пока матка не убита. off-like
[x]Добавлена возможность рефлекта скиллов эпик РБ
[x]Фикс. Мобы должны "спотыкаться" об догоняемого. off-like
[x]Фикс. Мобы не должны агриться вне зоны спавна в состоянии ожидания. После релога хейт должен сбрасываться. off-like
[x]Фикс. Добавлены скиллы Кнориксам.
[x]Фикс. Миньоны не должны исчезать после смерти лидера. off-like
[x]Фикс. Исправлены роуты трекеров в дв и кнориксов off-like
[x]Фикс. Гварды в лоа вешают паралич. off-like
[x]Фикс. Бафф в соа должен вешаться в 0 сек off-like
[x]Реализованы AI 3х рб. Drake lord телепортирует на место своего спавна, Behemoth кидает bleed, Dragon Beast создает копии и спавнит охрану. off-like
[x]Фикс. Мобы отстают от атакуемого и возвращаются домой пешком. Телепорт на место спавна через 10 минут если не могут дойти.
[x]Фикс. Монстры в в слипе или руте не должны сбрасывать хейт.
[x]Исправление ai мобов-файтеров. Мобы не должны кастовать 2 одинаковых скилла подряд, у файтеров скиллы должны быть с ненулевым откатом.
[x]Добавлены точки спавна мобов в ДВ
[x]Добавлена система фиксированного респа эпиков
[x]Добавлена дебафы мобов с таймером в shift-click.
[x]Фикс. Из эпик зон не должно выкидывать пол часа(тарас, валик, белефа, баюм). off-like
[x]Исправление AI петов. Heading во время перемещения. Разная дистанция срабатывания follow - зависит от ситуации. off-like
[x]Исправлено AI РБ Фреи. Гварды спавнятся только на постаментах. Респ гвардов зависит от убитых игроков.
[x]Испралено AI РБ Halisha, Клакиес. Добавлены недостающие скиллы, изменены шансы использования скиллов.
[x]Исправлена локация SoA. Добавлены мобам недостающие скиллы, увеличен шанс прохождения дебаффов.
[x]Исправлен расчет heading мобов-патрулей
[x]Фикс. Black dagger wing кастует только когда ее бьют вблизи, иначе в инактиве.
[x]Фикс. Миньоны мобов на большом рендже не должны давать хейт
[x]Фикс. При невозможности построить путь. Монстры не должны телепортироваться через стены, а только наверх.

Доработки:

[x]Добавлены евенты с буржуек
[x]Добавлены карты для евентов на 3-4-5 команд участников
[x]Перерисовка альт б
[x]Добавление аукциона в альт-б.
[x]Переработка и перерисовка cfg
[x]Сервис объединения таликов
[x]Новый евент: захват баз
[x]Добавлен конфиг на расход виталити от экспа
[x]Добавлен прокси слайдер с возможностью пинга недоступных
[x]Оптимизация механизмов работы скинов, выборки объектов
[x]Добавлены новые витамин питомцы
[x]Добавлена система скинов. Плащи, костюмы, оружия.
[x]Реализованы пакеты Eventmatch. (Турнирная система с PTS сервера)
[x]Реализована система GvG с тонкой настройкой и просмотром в режиме eventmatch. Ограничения на использование предметов, скиллов, кол-во бресов на пати
[x]Реализована функция сброса кэша(быстрого рестарта) с автопредложением раз в час.
[x]Добавлены кейсы и ключи. Открываются - как свиток заточки
[x]Добавлена функция auto CP|MP|HP за па или спец. сертификат
[x]Добавлено оповещение о сопернике на олимпе
[x]Реализован RateLimiter для логин сервера
[x]Реализованы рандомные награды за пвп и евенты. Выведено в конфиг.
[x]Реализована возможность спавна мобов в LoA\SoA в некоторые дни\часы.
[x]Реализована возможность осад и тв раз в неделю
[x]Реализована возможность запуска олимпа раз в определенные дни недели, выдачи геройства раз в 1 или 2 недели
[x]Добавлен конфиг на отключение Оли 3х3, классовые
[x]Реализация xmlrpc общения с сайтом
[x]Реализация групповой вставки атт
[x]Поправлены статы кастомных плащей
[x]Добавлена защита от спама в игре. Сообщение и письмо уходит, но не приходит получателю.
[x]Добавлен конфиг отключения ЗИ
[x]Добавлена команда //push. Поможет при ботханте
[x]Добавлен конфиг для мин лвл участника файтклаба

Прочие исправления:

[x]Фикс овербафа суперскиллов(прана\зеалот\ etc.) off-like
[x]Скорректирован таймаут\ренджаут на докаст скиллов при выходе из зоны действия off-like
[x]Однотипный дебаф разных скиллов должен накладываться поверх, в том числе один и тот же скилл может ложиться поверх самого себя, отменяя предыдущий. Кроме рута, слипа, паралича
[x]Добавлен спойл баффа виталити и хербов мп в дв.
[x]ShadowStep. Должна быть задержка в пол секунды после анимации перед телепортом. off-like
[x]Квест на баюма, красить: шанс от удара(около 20 минут), большой шанс от убийства, 5 минут. off-like
[x]Аура флеш теперь сбивает таргет мобам. Атака мобов должна сбиваться на 0.2 сек).
[x]Исправлен откат стрельбы арб. off-like
[x]Фикс. Во время каста можно выкидывать предметы. off-like
[x]Исправлен скрипт автоизучения скиллов. Убран двойной цикл, теперь не подвисает.
[x]Фикс. В мёртвого персонажа должны кастоваться бафы хилы ресы клинсы и тд. Клинсы снимают дебафы. off-like
[x]Фикс. Рт падает от крита шансово, шанс как у стана
[x]Исправлен баг с проходом к белефу через воду.
[x]Фикс. Если абилка дагера заточена на пвп - то не отражается контратакой off-like
[x]Исправлена награда за квест Вингс оф сенд - зависит от квест рейта
[x]Исправлены отражения. Можно выходить из пати, можно перезаходить без пати в свое отражение. off-like
[x]Исправлен вносимый хейт с аур магов.
[x]Исправление расчета нанесения урона массухой. Проверка видимости гео должна быть от таргета, а не кастующего. off-like
[x]Фикс. Конфиг сброса отката скиллов от изменения заточки.
[x]Фикс автоатака в мёртвого = следовать. off-like
[x] Фикс. Телепорт от чандры соло и фул пати. off-like
[x] Исправлена работа скилла арбы Decoy. Не должны проходить на фое, на инвиз должен.
[x] Фикс. Фейм за убийство на всю пати в рендже распределения. off-like
[x] Фикс. ShadowStep может не пройти в бафф евейжна от скиллов. off-like
[x] Фикс. Суммон в активном режиме при получении урона, бегает вокруг хозяина. off-like
[x] Фикс. В hot springs 2 бафа в лужах: один кладет бафф бошки, другой снимает.
[x] Лаг соски при смене пушки должен быть такой же как при снятии - одевании
[x] Реализованы хербы в полях и в болоте : herb terminator, slayer, immortal, guide. off-like
[x] Фикс. На тв квест за убийство должны давать всей пати независимо от расстояния между мемберами. off-like
[x] Оптимизация пакетной рассылки в зоне с большим кол-вом игроков. Исправило провисания фпс на масс замесах. Добавлен конфиг.
[x] Фикс. Рес может приходить поверх реса off-like
[x] Фикс. Статистика нового периода Олимпа обновляется сразу после окончания предыдущего. off-like
[x] Фикс. Лимит крит дмг только для игроков
[x] Исправлены статы некоторых питомцев off-like
[x] Фикс. При смене саба, залете на олимп соски отключаются off-like
[x] Фикс. Делей у баффов петов off-like
[x] Фикс. Бафф невита не должен учитывать рейт экспы. Сделан отдельный конфиг на рейт накопления\расхода.
[x]Исправлен механизм работы AntiBrute. Больше логин сервер не умирает хотя бы от слабых атак на L7
[x] Доработан EventMatch. Работает автоматически, при запуске админом требует минимум действий
[x] Исправлена боевая зона в колизее
[x] Фикс. При ударе пета хозяином пет подходит вплотную к нему off-like
[x] Фикс frost\fire\water armor, 10% шанс, скорректирован кулдаун, юз только в радиусе 400 off-like
[x] Фикс Insane Crusher. Канцел работает независимо от прохождения дебаффа. off-like
[x]Реализация лага бега при автоатаке. Лаг при зажатии автоатаки. off-like
[x]Уменьшен рейндж веера. off-like
[x]Добавлены виз. эффекты мобам-чемпионам
[x]Фикс. Суммон должен на голову суммонится off-like
[x]Фикс. Защита от антихейта
[x]Фикс. Отсутствовал магазин с коммон Д шмотом у некоторых нпц
[x]Исправлен баг с получением джуда на основу
[x]Исправлена работа трансформ с экипированным луком. рендж атаки\вампирик\рефлект\файтер вилл\ bow resist
[x]Фикс. Невит бафф - должен накидываться на разное время в зависимости от имеющихся очков.

Спойлер

[x]Примерочная
[x]Плащи\костюмы\шляпы
[x]Рейтование квестов
[x]Конфиг для хербов
[x]Конфиг для чемпионов
[x]Правки квестов
[x]Удаляем бекдоры
[x]Правка русских хтмлок
[x]Правка аи хеллбаунда
[x]Правка логирования авторизации
[x]Правки ACP
[x]Групповая вставка аттрибута
[x]Оповещение соперника на олимпе
[x]Быстрый релог
[x]Фикс string bundle
[x]Комбинирование талисманов
[x]Правки квестов
[x]CustomMessage для зон
[x]Фикс бага баффов - при накладывании кастующему сообщается об успешно наложенном бафе))
[x]Фикс бага с отсутствующим скиллом сбора камней в летающей трансформе
[x]Кнопки в баффере вместо комбобокс
[x]Фикс полетов в трансформе, на корабле
[x]Кастомные настройки
[x]Награда за пвп
[x]Фикс система одежды
[x]Vip Buffer
[x]Фиксы квестов
[x]Фиксы спавна в дв
[x]Косметика onShift
[x]Deprecate старые евенты
[x]Переделка конфигов бафера-евентов
[x]ItemBroker
[x]Спам-фильтр
[x]Конфиг на отключение ЗИ
[x]Фикс квестов, таймеров
[x]Боты
[x]Фикс камаель сое
[x]Фикс менеджера банов
[x]Баг рефлекта-пк, флаг вешался после рефлекта
[x]Баг скиллов на трупы, труп не исчезал
[x]Фикс сбора денег при проверке невозможности получить профу
[x]XmlRpc server
[x]htmlки квестов
[x]Вырезана старая евентовая система и евенты
[x]Добавлена возможность получение героя в last man standing
[x]Добавлены костюмы и примерочная в community board
[x]Сервис аугментации
[x]Добавлен Strix
[x]Удалена jts защита
[x]Фиксы пайлак
[x]Фиксы Камалок
[x]Фиксы скиллов\ фантомов
[x]Баг оли баффера
[x]Баг карт файтклаба
[x]Верная работа хербов и конфиг хайрейта
[x]Баги гео (расчет видимости, расчет прохода в воде)
[x]Баг адептов из-за птс параметров
[x]Баг pathfind(про подъеме, обходе углов)
[x]Баг экспы части мобов. берем с параметров
[x]Небольшая оптимизация бега с клавиатуры
[x]Еще оптимизация бега
[x]Фикс проверки трансформации в ограниченном пространстве
[x]Баг заменой кубиков

И это сгруппированные исправления, а не декомпозированные. Плюс некоторые работы мелкие, некоторые просто не зафиксированы, крупных работ по декомпиляции аи движка, отладке, разработке тоже тут нет.
В жтс есть хорошо написанный парсер, исправлены некоторые проблемы овера\либо свои же. ВСЕГО этого в жтс нет, и тем более нет гео и нпц движка(поддерживающего ai.obj), которые являются отличительной особенностью моей разработки

[donero 19]

В 21.03.2019 в 19:03, Khrome сказал:

1 в 1, в фулл версии жтса ( не шаре) это все есть

Имею данную сборь, ушло все далеко от jts и в лучшую сторону.

Конечно есть над чем работать, но на рынке ява считаю отличным продуктом.

И есть не шара jts.Мб чуть позже дополню к шаре скриптов.

Изменено 23 марта, 2019 пользователем donero

[Rozhek 7]

Патч для тех, кто идет смотреть не на плащи(23Мб): тык

[Rozhek 7]

Вся последняя неделя была посвящена работам по геодвижку и геомувингу. Огромное количесво отладки и есть результаты: диагностировал все возможные проблемы десинхрона в условиях слабого соединения и\или слабой серверной машины , удалось найти и поправить неприятную опечатку, еще немного оптимизировал функции построения пути.

Если вы еще думаете какую сборку выбрать для своего сервера, попробуйте удивить игроков не уникальной концепцией или клиентом классика, а хорошей геодатой)

[teilz 14]

жаль нет мультипроф функционала)

[PointerRage 132]

В 31.03.2019 в 10:55, Rozhek сказал:

Если вы еще думаете какую сборку выбрать для своего сервера, попробуйте удивить игроков не уникальной концепцией или клиентом классика, а хорошей геодатой)

Рантайм изменения веса клеток для патчфинда есть? Это для процессинга avoidance, тобишь, обход других актеров во время поиска пути. Или сделано, как обычно, костылем?:)

Если есть, то как разрешили задачу многопоточного доступа на модификацию веса клетки? Потому-что в этих ваших l2j-ях по другому невозможно, из-за того что общего тика сервера вообще нету.

Что с перестроением уже найденных путей при изменении веса клеток? Или может быть запилен avoidance по столкновениям? В таком случае какой вид деревьев использовали и опять же, как решили задачу с многопоточным доступом модификации BVH дерева?

Поиск пути по прежнему выдает говно в случаях с трехмерными плоскостями? (Как пример лестница у кристала в замках)

Как делаете синхронизацию координат сервер-клиент в условиях авторитарного сервера, да еще и без снапшотов (общих тиков, то у сервера нет, чтобы их возможно было делать)?

Как экстраполируете координаты клиента, в условиях того, что получение пинга, это вообще отдельный пакет?

 

Касательно этого момента:

Цитата

[x]Реорганизация гео-движка. Перемещение осуществляется по всем точкам мира, а не только центрам гео-клеток. off-like

Я понял, что имелось ввиду и что это за фикс. Но скажу к слову: в ретейле, непосредственно, векторное изменение координат идет по дискретным точкам, тобишь по гео-точкам. Результаты игнорирования этого можно посмотреть в любом l2j эмуляторе, со всякими ошибками координат около преград, из-за чего трассировщик высоты ломается и выдает неверный слой геодаты в многоуровневых локациях.

 

Хотели нормальных вопросов и дискаса - получите;)

Изменено 19 апреля, 2019 пользователем PointerRage

[Rozhek 7]

В 19.04.2019 в 22:41, PointerRage сказал:

Рантайм изменения веса клеток для патчфинда есть? Это для процессинга avoidance, тобишь, обход других актеров во время поиска пути. Или сделано, как обычно, костылем?:)

Если есть, то как разрешили задачу многопоточного доступа на модификацию веса клетки? Потому-что в этих ваших l2j-ях по другому невозможно, из-за того что общего тика сервера вообще нету.

Что с перестроением уже найденных путей при изменении веса клеток? Или может быть запилен avoidance по столкновениям? В таком случае какой вид деревьев использовали и опять же, как решили задачу с многопоточным доступом модификации BVH дерева?

Зачем вообще рантайм менять вес клеток, еще и с многопоточным доступом. Вес не статичный, пути не хранятся, расчет достаточно быстрый на любой современной машине, чтобы отрабатывать каждый запрос в отдельном потоке за несколько мс. Пакеты медленней доставляются, чем происходит подсчет пути. Это избыточно.

Сам алгоритм расчета веса клеток на l2j-ях слабый, расчет производится по т.Пифагора для прямых\диагональных перемещений, а для всех клеток где по соседству есть препятствие - просто статичный большой вес. Этого не достаточно.

В 19.04.2019 в 22:41, PointerRage сказал:

Поиск пути по прежнему выдает говно в случаях с трехмерными плоскостями? (Как пример лестница у кристала в замках)

Поиск пути работает в соответствии со своим алгоритмом, с параметрами задающими вес клеткам). Если разница в высоте между лесенками позволяет присваивать вес клетке, предполагающий перемещение, то почему он должен выдасть гавно. Другое дело каким образом строится и воспроизводится мувинг по узлам построенного пути и учитывает ли он эти особенности)

В 19.04.2019 в 22:41, PointerRage сказал:

Как делаете синхронизацию координат сервер-клиент в условиях авторитарного сервера, да еще и без снапшотов (общих тиков, то у сервера нет, чтобы их возможно было делать)?

Тут стоить начать с того что в клиенте векторное движение, на сервере декартовое. Точность сопадения координат в общем случае характеризуется точностью результата функции аппроксимации, т.е. в идеальном случае рассинхронизация не должна возникать из-за неверных математичеких расчетах. Поэтому необходимости синхронизации по тикам нет, а для всех остальных случаев в клиенте уже предусмотрен механизм оповещения сервера при рассинхроне(ValidateLocation). Проблемы в отсутствии аппроксимации, а синхронизация по тикам это про другие игры.

В 19.04.2019 в 22:41, PointerRage сказал:

Как экстраполируете координаты клиента, в условиях того, что получение пинга, это вообще отдельный пакет?

Вы точно правильно употребляете термины?) Поясните подробнее, что имелось ввиду. Как связан пинг и координаты клиента я не совсем понял.

В 19.04.2019 в 22:41, PointerRage сказал:

Я понял, что имелось ввиду и что это за фикс. Но скажу к слову: в ретейле, непосредственно, векторное изменение координат идет по дискретным точкам, тобишь по гео-точкам. Результаты игнорирования этого можно посмотреть в любом l2j эмуляторе, со всякими ошибками координат около преград, из-за чего трассировщик высоты ломается и выдает неверный слой геодаты в многоуровневых локациях.

Первая часть - все верно.

Вторая часть - не совсем так. Точнее, это происходит не из-за отличия способа изменения координат, а из-за неправильных расчетов координат и самих слоев. На l2j эмуляторах неправильно определяются слои геодаты, когда актор находится между ними. При правильном алгоритме определения слоя, проблем собственно и нет.

 

Спасибо большое за вопросы) Вижу вы изучаете тематику, много терминов связанных с общей и частными теориями работы с графами. Лучше их все пояснять, чтобы не гуглить) В заключении скажу, что большинство проблем с перемещением вызвано неправильными механизмами поклеточного построения дистанции по правильным узлам пути(ведь сами алгоритмы поиска давно придуманы непрограммистами и они одинаковые везде и не только в играх), отсутствии более точной функции аппроксимации координат, ну и тотальные и повсеместные опечатки программистов конечно же

 

[PointerRage 132]

6 часов назад, Rozhek сказал:

Зачем вообще рантайм менять вес клеток, еще и с многопоточным доступом. Вес не статичный, пути не хранятся, расчет достаточно быстрый на любой современной машине, чтобы отрабатывать каждый запрос в отдельном потоке за несколько мс. Пакеты медленней доставляются, чем происходит подсчет пути. Это избыточно.

Это понятно, ибо эвристика. Я говорю про саму реализацию avoidance динамических актеров, чтобы движущиеся актеры не сталкивались и рекалькулировали свой путь, для избежания столкновений. Очевидно, что это реализуется в рантайме:) 

Обычно такие задачи решаются отложенным пересчетом пути актера и динамическим изменением веса клетки, по которым, другие актеры двигаются (в случаях дискретной сетки). В более хороших и правильных реализациях используются BVH деревья (причем обычно достаточно балансного AABB дерева), чтобы реализовать приемлемый avoidance. Кстати говоря, второй подход также используется в физических движках, но это уже тема для иного разговора.

 

6 часов назад, Rozhek сказал:

Поиск пути работает в соответствии со своим алгоритмом, с параметрами задающими вес клеткам). Если разница в высоте между лесенками позволяет присваивать вес клетке, предполагающий перемещение, то почему он должен выдасть гавно. Другое дело каким образом строится и воспроизводится мувинг по узлам построенного пути и учитывает ли он эти особенности)

Потому-что на моей памяти, во всех l2j-ях эврестическая стоимость клетки имеет вид: D(sqrt(x*x + y*y + (z*z) / modifier)) - или нечто похожее. Впрочем, даже выставляя "честную" эвристику по Z-оси, результат задастую выходит не таким, какой ожидается, из-за того, что вес клеток по "правильному" пути намного выше, чем вес до, условно, неверного пути. Сюда же можно добавить и то, что во всех l2j-ях реализация поиска пути работает по алгоритму "первый лучший".

 

6 часов назад, Rozhek сказал:

Тут стоить начать с того что в клиенте векторное движение, на сервере декартовое. Точность сопадения координат в общем случае характеризуется точностью результата функции аппроксимации, т.е. в идеальном случае рассинхронизация не должна возникать из-за неверных математичеких расчетах. Поэтому необходимости синхронизации по тикам нет, а для всех остальных случаев в клиенте уже предусмотрен механизм оповещения сервера при рассинхроне(ValidateLocation). Проблемы в отсутствии аппроксимации, а синхронизация по тикам это про другие игры.

Не согласен. Рассинхронизация возникает только потому-что игра сетевая, а сеть имеет задержку. К тому же, сюда стоит еще добавить, что методы передвижения актеров на сервере и клиенте разные, из-за чего результаты получаются различными. В добавок, стоит добавить, то что на клиенте расчет движения осуществляется с помощью чисел с плавающей точкой, только этого достаточно, чтобы получать различные результаты на различных машинах. Я уже не говорю о том, что на сервере везде используются натуральные числа, которые еще из-за аппроксимации из/в дискретные координаты, ну совсем уж, не похожи на клиентский результат.

 

6 часов назад, Rozhek сказал:

Вы точно правильно употребляете термины?) Поясните подробнее, что имелось ввиду. Как связан пинг и координаты клиента я не совсем понял.

Минутка шуток: администратор локалхоста недоумевает, как связаны координаты присылаемые клиентом серверу с пингом, потому-что у него нулевой пинг.

А если серьезно, то они непосредственно связаны тем, что:

1. Сервер по расчетам движения всегда впереди клиента, потому-что пакет MoveToLocation не доставляется моментально на клиент.

2. Клиент при отправке запроса ValidateLocation, отправляет координаты, которые актуальны на текущий момент. Пока пакет обработается в очереди, пока отправится, дойдет до сервера, сервер его обработает... Пройдет значительное время, чтобы процессинг на сервере сказал: "нифига, эти координаты неверны". А отсутствие снапшотов не дает заглянуть в прошлое и сверить правильность координат на момент времени отправки клиентом пакета. Именно поэтому я предположил, что может использоваться экстраполяция координат для их проверки, чтобы довести эти клиентские координаты до "текущей точки времени" и проверить, очевидно, их правильность.

3. Если актер движется и сервер меняет ему путь, то, очевидно, в пакете MoveToLocation должны быть указаны "начальные" координаты и "конечные". К "конечным" нет никаких вопросов, однако, начальные координаты следует экстраполировать по трип-тайму, тобишь, времени пакета в пути, либо, в ином случае, клиенту начинает быть довольно плохо.

 

6 часов назад, Rozhek сказал:

Вторая часть - не совсем так. Точнее, это происходит не из-за отличия способа изменения координат, а из-за неправильных расчетов координат и самих слоев. На l2j эмуляторах неправильно определяются слои геодаты, когда актор находится между ними. При правильном алгоритме определения слоя, проблем собственно и нет.

Определение слоев, да, есть такая проблема, но я не о ней говорю на данный момент, потому-что это исправляется легко и быстро, да и обсуждать это как-то не очень интересно:)

Попробуйте на клиенте подойти очень близко к преграде, а после этого сконвертируйте координаты в дискретные. Вы будете неприятно удивлены, что в части кейсов, дискретные координаты будут указывать на "пустоту", тобишь, на внутренности, например, статик меша. Причем, это происходит из-за самой алгоритмики перевода реальных координат в дискретные. Соответственно, перевод таких дискретных координат в реальные, даст точку внутри статик-меша, там где клетка гео-даты вообще отсутствует.

Возможно Вы просто не замечали таких кейсов, но когда я еще занимался этими всеми l2j-ями, причем на довольно нагруженных проектах (от 1 200 онлайна до 2 000), такие проблемы всплывали, однако, не сразу. 

 

6 часов назад, Rozhek сказал:

Спасибо большое за вопросы) Вижу вы изучаете тематику, много терминов связанных с общей и частными теориями работы с графами. Лучше их все пояснять, чтобы не гуглить) В заключении скажу, что большинство проблем с перемещением вызвано неправильными механизмами поклеточного построения дистанции по правильным узлам пути(ведь сами алгоритмы поиска давно придуманы непрограммистами и они одинаковые везде и не только в играх), отсутствии более точной функции аппроксимации координат, ну и тотальные и повсеместные опечатки программистов конечно же

Спасибо за ответ. Я, если честно, даже не надеялся на ответ. Всегда приятно обсудить интересные технические задачи и способы их решения:)

На счет терминов:

BVH дерево - дерево хранящее внутри себя набор геометрических фигур.

AABB дерево - дерево хранящее внутри себя "коробки" актеров. Если простыми словами, то "коробка" - прямоугольник (либо же куб, в случае хранения трехмерных коробок), который включает в себя полный размер актера.

AABB - "коробка", см. AABB  дерево.

Avoidance - механизм уклонения (обхода) от динамических актеров.

Балансное дерево - дерево, которое имеет сбалансированное количество количество веток и листов на них, на каждом уровне глубины/высоты.

Изменено 21 апреля, 2019 пользователем PointerRage

[Rozhek 7]

5 часов назад, PointerRage сказал:

Это понятно, ибо эвристика. Я говорю про саму реализацию avoidance динамических актеров, чтобы движущиеся актеры не сталкивались и рекалькулировали свой путь, для избежания столкновений. Очевидно, что это реализуется в рантайме:) 

Обычно такие задачи решаются отложенным пересчетом пути актера и динамическим изменением веса клетки, по которым, другие актеры двигаются (в случаях дискретной сетки). В более хороших и правильных реализациях используются BVH деревья (причем обычно достаточно балансного AABB дерева), чтобы реализовать приемлемый avoidance. Кстати говоря, второй подход также используется в физических движках, но это уже тема для иного разговора.

Понял, что имелось ввиду, но такая задача в принципе не стоит. Такого функционала нет на офф сервере, и я об этом даже и не думал. Наверное в современных играх этот вопрос стоит достаточно остро.

5 часов назад, PointerRage сказал:

Потому-что на моей памяти, во всех l2j-ях эврестическая стоимость клетки имеет вид: D(sqrt(x*x + y*y + (z*z) / modifier)) - или нечто похожее. Впрочем, даже выставляя "честную" эвристику по Z-оси, результат задастую выходит не таким, какой ожидается, из-за того, что вес клеток по "правильному" пути намного выше, чем вес до, условно, неверного пути. Сюда же можно добавить и то, что во всех l2j-ях реализация поиска пути работает по алгоритму "первый лучший".

Все так(в формуле только не координаты, а их разница). И функция все таки считает примерный естимейт, для того что бы быстрее путь найти, но не ограничивает сам поиск. И наверное, ее можно улучшить) Реальное ограничение на подъем по лестнице накладывается в расчете стоимости веса текущей клетки от старта. Там шлепается сразу вес*3, а если в соседней клетке есть подъем *2. А вот евристическая функция при подъеме по лестнице помогает определить что разница в z координате уменьшилась, и поднимает проверку этой клетки и ее соседей в очереди.

Насчет алгоритма: пробовал A* - работает очень медленно, IDA* - кажется будет что то ломать. Вообще текущий именно алгоритм поиска каких то проблем не вызывал, зато функцию очистки этого пути от лишних узлов переделал с последовательной проверки на синхронную с двух концов.

5 часов назад, PointerRage сказал:

1. Сервер по расчетам движения всегда впереди клиента, потому-что пакет MoveToLocation не доставляется моментально на клиент.

2. Клиент при отправке запроса ValidateLocation, отправляет координаты, которые актуальны на текущий момент. Пока пакет обработается в очереди, пока отправится, дойдет до сервера, сервер его обработает... Пройдет значительное время, чтобы процессинг на сервере сказал: "нифига, эти координаты неверны". А отсутствие снапшотов не дает заглянуть в прошлое и сверить правильность координат на момент времени отправки клиентом пакета. Именно поэтому я предположил, что может использоваться экстраполяция координат для их проверки, чтобы довести эти клиентские координаты до "текущей точки времени" и проверить, очевидно, их правильность.

3. Если актер движется и сервер меняет ему путь, то, очевидно, в пакете MoveToLocation должны быть указаны "начальные" координаты и "конечные". К "конечным" нет никаких вопросов, однако, начальные координаты следует экстраполировать по трип-тайму, тобишь, времени пакета в пути, либо, в ином случае, клиенту начинает быть довольно плохо.

Опять же все так. Но) В клиенте есть удобный механизм, который сводит микрорассинхронизации на лету(ускоряя или замедляя). Остальной разницей возникающей в период 20-200мс можно принебречь - ведь эта разница не аккумулируется при движении: сервер считает позицию раньше клиента -> сервер получает новый запрос от клиента на смену координат -> пока сервер считает новую координату и отправляет пакет -> персонаж догоняет позицию и рассинхрона не происходит /если есть минимальные расхождения позиция подхватывается на лету  (тут даже до ValidateLocation не доходит, он начинает его слать от разницы в 50-100 координат что ли). 

Почему так не работает у всех, ведь вроде же все так же. Из-за того, что во время бега координата на сервере стоит то справа-сзади от линии движения, то слева-впереди по пол секунды(в центрах гео координат). При получении запроса на изменение пути, расчет начинается от середины той геоклетки(кроме того на всех l2jях банальный баг и первый тик бега считается путь от 0 точки до нее же) -> клиент замедляет скорость, потому что начальная координата ждет, потом ускоряет скорость потому что координата быстро уходит по центрам геоклеток -> потом поступает запрос на смену пути -> серверная координата уже на 30 координат впереди-справа от текущей точки, а клиент бежит не к ней а к конечной локации-> цикл начинается заного, но уже с расхождениями координат.

5 часов назад, PointerRage сказал:

Определение слоев, да, есть такая проблема, но я не о ней говорю на данный момент, потому-что это исправляется легко и быстро, да и обсуждать это как-то не очень интересно:)

Попробуйте на клиенте подойти очень близко к преграде, а после этого сконвертируйте координаты в дискретные. Вы будете неприятно удивлены, что в части кейсов, дискретные координаты будут указывать на "пустоту", тобишь, на внутренности, например, статик меша. Причем, это происходит из-за самой алгоритмики перевода реальных координат в дискретные. Соответственно, перевод таких дискретных координат в реальные, даст точку внутри статик-меша, там где клетка гео-даты вообще отсутствует.

Возможно Вы просто не замечали таких кейсов, но когда я еще занимался этими всеми l2j-ями, причем на довольно нагруженных проектах (от 1 200 онлайна до 2 000), такие проблемы всплывали, однако, не сразу. 

Я примерно понимаю, в чем может быть проблема. Я тоже не по серверным точкам путь строю, а смещаю точку геоклетки внутри нее самой к вектору движения(т.е. использую дробную часть), геоклетка состоит из 16 точек и при неправильной конвертации можно попасть в соседнюю геоклетку. Правда не понимаю, откуда проблеме быть если конвертация работает правильно)

Изменено 21 апреля, 2019 пользователем Rozhek

[Rozhek 7]

Тестовый сервер переехал в новый ДЦ

- полный_патч (с допами 400Мб)

- урезаный_патч

[PointerRage 132]

В 21.04.2019 в 23:56, Rozhek сказал:

Понял, что имелось ввиду, но такая задача в принципе не стоит. Такого функционала нет на офф сервере, и я об этом даже и не думал. Наверное в современных играх этот вопрос стоит достаточно остро.

Одно время данный функционал был на официальном сервере, однако, позже его убрали по неизвестным причинам. Впрочем, его отголоски до сих пор можно заметить, допустим: использовать большую трансформацию и перегородить вход куда-либо. Это до сих пор актуально на текущей версии NA-сервера. В HF-версиях, клиент может послать пакет CannotMoveAnymore (или как-то так), но сервер в силах и без этого пакета все правильно обработать и забраковать путь.

Раньше в ретейле использовалось не BVH-дерево, а дискретный метод (специальная хеш-таблица) для определения столкновений. Но в таком подходе минусов целая коробка и маленький контейнер.

 

В 21.04.2019 в 23:56, Rozhek сказал:

Насчет алгоритма: пробовал A* - работает очень медленно, IDA* - кажется будет что то ломать. Вообще текущий именно алгоритм поиска каких то проблем не вызывал, зато функцию очистки этого пути от лишних узлов переделал с последовательной проверки на синхронную с двух концов.

Я раньше эксперементировал с различными алгоритмами поиска пути, в контексте lineage 2: руки, двусторонний поиск, различные вариации жадных алгоритмов и различные направленные версии. В общем, лично я, остановился на направленном A*. А потом вообще плюнул на все это и выкинул геодату, и просто вгрузил все коллайдеры с карт. Прогнал их через оптимизатор вершин и получился вполне нормальный граф, по которому можно искать путь (причем в большинстве случаев он легковеснее той же геодаты), как плюс, можно делать нормальные "физические" рейкасты (на самом деле, они реально нормальные, а не то говно, которое трассируется через геодату) для проверки видимости. В теории, можно вообще психануть и написать BSP для тех же рейкастов, но производительность BVH меня вполне устраивает.

 

В 21.04.2019 в 23:56, Rozhek сказал:

Почему так не работает у всех, ведь вроде же все так же. Из-за того, что во время бега координата на сервере стоит то справа-сзади от линии движения, то слева-впереди по пол секунды(в центрах гео координат). При получении запроса на изменение пути, расчет начинается от середины той геоклетки(кроме того на всех l2jях банальный баг и первый тик бега считается путь от 0 точки до нее же) -> клиент замедляет скорость, потому что начальная координата ждет, потом ускоряет скорость потому что координата быстро уходит по центрам геоклеток -> потом поступает запрос на смену пути -> серверная координата уже на 30 координат впереди-справа от текущей точки, а клиент бежит не к ней а к конечной локации-> цикл начинается заного, но уже с расхождениями координат.

Там считается время движения до нулевой точки, чтобы компенсировать линейное увеличение скорости движения персонажа при беге, которое отлично видно в начале движения. Это не правильно, я согласен. Но чтобы сделать правильно - необходимы тики, в ином случае, на маленьких дистанция рассинхронизация будет вполне заметна, а если таким методом двигаться почти беспрерывно, то разница координат может достигать в несколько сотен точек.

 

В 21.04.2019 в 23:56, Rozhek сказал:

Опять же все так. Но) В клиенте есть удобный механизм, который сводит микрорассинхронизации на лету(ускоряя или замедляя). Остальной разницей возникающей в период 20-200мс можно принебречь - ведь эта разница не аккумулируется при движении: сервер считает позицию раньше клиента -> сервер получает новый запрос от клиента на смену координат -> пока сервер считает новую координату и отправляет пакет -> персонаж догоняет позицию и рассинхрона не происходит /если есть минимальные расхождения позиция подхватывается на лету  (тут даже до ValidateLocation не доходит, он начинает его слать от разницы в 50-100 координат что ли). 

Ага, знаю такой механизм, это синхронизация клиентской экстраполяции. Но, если честно, мне было лень ее разбирать на клиенте, поэтому я на это успешно забил:)

На счет "забить на 20-200мс" - мне не кажется это хорошей идеей, так как при увеличении нагрузки на сервер, время самого серверного процессинга будет увеличиваться без роста сетевой задержки, из-за чего итоговая задержка запроса может быть намного выше 200мс и это следует учитывать. Нечто вроде: delay = trip time + processing time.

 

Извиняюсь за столь долгий ответ, впредь постараюсь отвечать быстрее:)

Изменено 27 апреля, 2019 пользователем PointerRage

[Rozhek 7]

17 часов назад, PointerRage сказал:

Одно время данный функционал был на официальном сервере, однако, позже его убрали по неизвестным причинам. Впрочем, его отголоски до сих пор можно заметить, допустим: использовать большую трансформацию и перегородить вход куда-либо. Это до сих пор актуально на текущей версии NA-сервера. В HF-версиях, клиент может послать пакет CannotMoveAnymore (или как-то так), но сервер в силах и без этого пакета все правильно обработать и забраковать путь.

 Раньше в ретейле использовалось не BVH-дерево, а дискретный метод (специальная хеш-таблица) для определения столкновений. Но в таком подходе минусов целая коробка и маленький контейнер.

Если честно нигде ни на каком сервере не видел, чтобы путь строился в обход коллизии. Проверка проходимости через коллизии - да, но построение пути в зависимости от них - нет. Тем более в динамике с их пересечением) Представьте как бы игроки двигались, например, на валакасе - мало того что вокруг куча игроков, которых нужно оббегать, так еще и гигантский босс, которого оббежать с его скоростью невозможно - выглядело бы все это не очень адекватно.

 

18 часов назад, PointerRage сказал:

Там считается время движения до нулевой точки, чтобы компенсировать линейное увеличение скорости движения персонажа при беге, которое отлично видно в начале движения. Это не правильно, я согласен. Но чтобы сделать правильно - необходимы тики, в ином случае, на маленьких дистанция рассинхронизация будет вполне заметна, а если таким методом двигаться почти беспрерывно, то разница координат может достигать в несколько сотен точек.

Не понял, как движение в точку отличную от конечной(и ближе и дальше) может компенсировать анимацию начала движения. Что значит сделать это правильно? По моему это не то что правильно - это бездумно, решать проблему повышением тикрейта и синхронизацией с клиентом игры, разве нет?) На l2j серверах есть тики которые которые выставляют позицию по ходу движения(опять же не точно, а в центры геокоординат) - и эти тики и вызывают рассинхронизацию и попытки клиента интерполировать позицию внутри вектора движения, когда он получает пакет о новом передвижении и текущие координаты отличаются от серверных.

Еще раз говорю, если уметь считать координаты точно в любой нужный момент времени, то проблема рассинхронизации исчезает. Это мой best practice. Сетевой лаг или тикрейт в совокупности составляют около 20-30% проблемы и те решаются просто хорошей сетью.

Когда решена основная проблема, можно повышать тикрейт расчета позиции. Но не тики синхронизации координат с клиентом) Они в л2 не нужны.

 

18 часов назад, PointerRage сказал:

На счет "забить на 20-200мс" - мне не кажется это хорошей идеей, так как при увеличении нагрузки на сервер, время самого серверного процессинга будет увеличиваться без роста сетевой задержки, из-за чего итоговая задержка запроса может быть намного выше 200мс и это следует учитывать. Нечто вроде: delay = trip time + processing time.

Но этот показатель все равно будет статичным, клиент будет статично отставать от сервера и при получении новых пакетов с той же примерно задержкой будет успевать догонять координаты сервера. Кстати 200мс - с точки зрения любых игр уже выходит за рамки комфортной игры, а в л2 это отставание клиента от сервера при средней скорости бега всего на 30-40 координат, которые при стабильном пинге превращаются всего в 1-2 координаты рассинхрона. Реальное плохая ситуация это когда пинг прыгает, например, разброс пинга в +-100мс при той же средней скорости(брал 170 коорд в сек) может вызывать рассинхронизацию до 20 координат в точке смены направления движения и это уже будет заметно.

[PointerRage 132]

53 минуты назад, Rozhek сказал:

Если честно нигде ни на каком сервере не видел, чтобы путь строился в обход коллизии. Проверка проходимости через коллизии - да, но построение пути в зависимости от них - нет. Тем более в динамике с их пересечением)

Никто и не говорил о динамике с пересечением, так как данную задачу почти невозможно решить (адекватно по производительности), если агентов много и у них различные скорости. Поэтому и существует динамический avoidance основанный на сенсорике. Кстати говоря, примерно так монстры и не стакаются на ретейле.  Впрочем, по большей части, это уже разговор о других играх.

 

25 минут назад, Rozhek сказал:

Представьте как бы игроки двигались, например, на валакасе - мало того что вокруг куча игроков, которых нужно оббегать, так еще и гигантский босс, которого оббежать с его скоростью невозможно - выглядело бы все это не очень адекватно.

В более ранних версиях игроки не были проходимы;)

 

28 минут назад, Rozhek сказал:

Не понял, как движение в точку отличную от конечной(и ближе и дальше) может компенсировать анимацию начала движения. Что значит сделать это правильно? По моему это не то что правильно - это бездумно, решать проблему повышением тикрейта и синхронизацией с клиентом игры, разве нет?) На l2j серверах есть тики которые которые выставляют позицию по ходу движения(опять же не точно, а в центры геокоординат) - и эти тики и вызывают рассинхронизацию и попытки клиента интерполировать позицию внутри вектора движения, когда он получает пакет о новом передвижении и текущие координаты отличаются от серверных.

Дело не в анимации, она далеко не root motion, чтобы она играла какую-то роль, а именно в изменении скорости движения. Сделать "это правильно" - применить линейную интерполяцию на каждый тик движения, в зависимости от времени. Впрочем, подойдет и любой метод получения координат, который будет экстраполировать/интерполировать координаты, в зависимости от времени. В ином случае, с текущей трединговой моделью, расчет попросту будет неверным.

А кто говорил про решение проблемы увеличением тикрейта? У меня вообще на одном сервере (не lineage 2, к счастью) тикрейт самого сервера (а это, на секундочку, вообще все серверные геймплейные операции, куда входит и движение) выставлен в 15 раз в секунду, что очень и очень низко, особенно, смотря на некоторые сервера, которые имеют тикрейт в 60 фреймов.

 

40 минут назад, Rozhek сказал:

 Еще раз говорю, если уметь считать координаты точно в любой нужный момент времени, то проблема рассинхронизации исчезает. Это мой best practice. Сетевой лаг или тикрейт в совокупности составляют около 20-30% проблемы и те решаются просто хорошей сетью.

С этого и следовало начинать! Вы считаете координаты по запросу. Вопросов в этом плане больше не имею:)

 

51 минуту назад, Rozhek сказал:

Но этот показатель все равно будет статичным, клиент будет статично отставать от сервера и при получении новых пакетов с той же примерно задержкой будет успевать догонять координаты сервера. Кстати 200мс - с точки зрения любых игр уже выходит за рамки комфортной игры, а в л2 это отставание клиента от сервера при средней скорости бега всего на 30-40 координат, которые при стабильном пинге превращаются всего в 1-2 координаты рассинхрона. Реальное плохая ситуация это когда пинг прыгает, например, разброс пинга в +-100мс при той же средней скорости(брал 170 коорд в сек) может вызывать рассинхронизацию до 20 координат в точке смены направления движения и это уже будет заметно.

Касательно скачков пинга - эта проблема, к сожалению, есть везде и у меня нет идей, как это можно решить. Кроме варианта зашития, в сам заголовок пакета, времени отправки, для расчета трип тайма на каждый пакет.

[Deazer 76]

В 20.03.2019 в 21:56, Rozhek сказал:

Новый AI движок
аи мобов парсятся из птс скриптов(ai.obj). необходимые параметры нпц\спавна\скиллов парсятся из птс файлов. 95% мобов работают на этом аи, остальные 5%(рб и спец. скриптовые мобы) временно собраны из из птс скриптов вручную

Можно пример привести, что именно распарс с AI.obj идет, а не как с квестами которые вы пересобирали из ai.obj

Вы написали свою VM или как это происходит, если не сложно очень был бы рад услышать ваш ответ.

 

UPD: Вопросов более нет

Ни о каких формулах речи и нет, все АИ стандартные. Это шляпа.

 

Пацаны взяли просто JTS и что-то там допилили и тот кто описывал выше видимо вообще не знает что он в тиме или же его не плохо так контузило.

 

Если у кого будут вопросы - могу выложить фул переписку. Там так не плохо ударенный об угол человек и это не о форме общения, а в целом о понимании и то что у него на сервере.

Изменено 1 мая, 2019 пользователем Deazer

[Rozhek 7]

Коротко:

Сначала я объяснял почему нет тех аи куда он тыкался, посмотрел на его пруфы - вспомнил что аи сейчас нет на тесте. Комментатора ничего из этого не интересовало, он продолжал свои дешевые выпады игнорируя ответы. Устал, попытался закончить разговор, вышел из себя, забил хер. 

Манера общения за гранью реальности, там же примерно желание самоутвердиться. Крайне не советую вести с ним какой либо диалог.

По итогу: Сборку пересобрал с АИ, залил - можно тестить. Теперь все на месте.

 

И не надо грозиться перепиской, я твою клоунаду сам с удовольствием предоставлю для общего чтива:

- Д: Сервер не работает!

- Я: Нет, работает

- Д: Квесты не работают!

- Я: Да нет же, работают

-Д: АИ стандартные

-Я: Мм, да, я ошибся и выложил не тот архив. Завтра выложу правильный, приходите тестировать

-Д: Нет! Просто у тебя их нет!

-Я: Но..

-Д: Нету! Их нету! Их не может быть1 Нету, нету, нету, нету.

-Я: (скриншот с аи)

-Д: Что это!? ИХ нету! И вообще все формулы кривые..

Изменено 1 мая, 2019 пользователем Rozhek

[TURGOR 33]

он тебя забанит на форуме.