Rozhek

Ставлю на GC

Хотел апнуть, а тут насрано. Придется что то написать: - никого не интересует как реализовано, главное что реализовано. Стройка ради стройки - не правильное мышление. - формула отката так и не раскрыта, ведь вся начинка внутри rate, и собственно почему у меня не правильная так и не было пруфа.

Я могу специально для вас использовать такой термин какой вам будет удобно. Я до сих пор не понимаю суть претензий. Факт того что аи мобов работают на птс скриптах - есть. Реверс выполняется своим декомпилятором через Stack, в зависимости от разной последовательности функций вставляется разный ява код. Это определение слова парсинг - выполнение синтаксического анализа. Мало просто декомпилировать - нужно правильно сформировать дерево наследования классов, переменных и функций. Это тоже парс. А потом с учетом этого наследования через рефлексию подставляются нужные переменные, спарсенные из pts_data. Что вы себе там напридумывали я не знаю. Почему у меня это должно работать как вы себе напридумывали я тоже не знаю. У меня работает так, у вас видимо никак. Предлагаю прекращать позориться, выпытывать как что работает, и заняться своим кодом. А я тратить еще больше времени на пустые разговоры не намерен.

Коротко: Сначала я объяснял почему нет тех аи куда он тыкался, посмотрел на его пруфы - вспомнил что аи сейчас нет на тесте. Комментатора ничего из этого не интересовало, он продолжал свои дешевые выпады игнорируя ответы. Устал, попытался закончить разговор, вышел из себя, забил хер. Манера общения за гранью реальности, там же примерно желание самоутвердиться. Крайне не советую вести с ним какой либо диалог. По итогу: Сборку пересобрал с АИ, залил - можно тестить. Теперь все на месте. И не надо грозиться перепиской, я твою клоунаду сам с удовольствием предоставлю для общего чтива: - Д: Сервер не работает! - Я: Нет, работает - Д: Квесты не работают! - Я: Да нет же, работают -Д: АИ стандартные -Я: Мм, да, я ошибся и выложил не тот архив. Завтра выложу правильный, приходите тестировать -Д: Нет! Просто у тебя их нет! -Я: Но.. -Д: Нету! Их нету! Их не может быть1 Нету, нету, нету, нету. -Я: (скриншот с аи) -Д: Что это!? ИХ нету! И вообще все формулы кривые..

Вы платите деньги, а потом недовольные просите помощи на бесплатных форумах. Что с вами не так )

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

На персонаже стоит какая то краска кривая, сервер видимо не может ее найти. Либо вы что то делали с красками и поломали файлик с ними в датапаке. п.с. Ошибка в геймсервере а не логин. У вас даже прямо в ошибке написано in_game

Если честно нигде ни на каком сервере не видел, чтобы путь строился в обход коллизии. Проверка проходимости через коллизии - да, но построение пути в зависимости от них - нет. Тем более в динамике с их пересечением) Представьте как бы игроки двигались, например, на валакасе - мало того что вокруг куча игроков, которых нужно оббегать, так еще и гигантский босс, которого оббежать с его скоростью невозможно - выглядело бы все это не очень адекватно. Не понял, как движение в точку отличную от конечной(и ближе и дальше) может компенсировать анимацию начала движения. Что значит сделать это правильно? По моему это не то что правильно - это бездумно, решать проблему повышением тикрейта и синхронизацией с клиентом игры, разве нет?) На l2j серверах есть тики которые которые выставляют позицию по ходу движения(опять же не точно, а в центры геокоординат) - и эти тики и вызывают рассинхронизацию и попытки клиента интерполировать позицию внутри вектора движения, когда он получает пакет о новом передвижении и текущие координаты отличаются от серверных. Еще раз говорю, если уметь считать координаты точно в любой нужный момент времени, то проблема рассинхронизации исчезает. Это мой best practice. Сетевой лаг или тикрейт в совокупности составляют около 20-30% проблемы и те решаются просто хорошей сетью. Когда решена основная проблема, можно повышать тикрейт расчета позиции. Но не тики синхронизации координат с клиентом) Они в л2 не нужны. Но этот показатель все равно будет статичным, клиент будет статично отставать от сервера и при получении новых пакетов с той же примерно задержкой будет успевать догонять координаты сервера. Кстати 200мс - с точки зрения любых игр уже выходит за рамки комфортной игры, а в л2 это отставание клиента от сервера при средней скорости бега всего на 30-40 координат, которые при стабильном пинге превращаются всего в 1-2 координаты рассинхрона. Реальное плохая ситуация это когда пинг прыгает, например, разброс пинга в +-100мс при той же средней скорости(брал 170 коорд в сек) может вызывать рассинхронизацию до 20 координат в точке смены направления движения и это уже будет заметно.

Описание с сайта опенов, если будете покупать, уточняйте про перепривязку

Тестовый сервер переехал в новый ДЦ - полный_патч (с допами 400Мб) - урезаный_патч

Понял, что имелось ввиду, но такая задача в принципе не стоит. Такого функционала нет на офф сервере, и я об этом даже и не думал. Наверное в современных играх этот вопрос стоит достаточно остро. Все так(в формуле только не координаты, а их разница). И функция все таки считает примерный естимейт, для того что бы быстрее путь найти, но не ограничивает сам поиск. И наверное, ее можно улучшить) Реальное ограничение на подъем по лестнице накладывается в расчете стоимости веса текущей клетки от старта. Там шлепается сразу вес*3, а если в соседней клетке есть подъем *2. А вот евристическая функция при подъеме по лестнице помогает определить что разница в z координате уменьшилась, и поднимает проверку этой клетки и ее соседей в очереди. Насчет алгоритма: пробовал A* - работает очень медленно, IDA* - кажется будет что то ломать. Вообще текущий именно алгоритм поиска каких то проблем не вызывал, зато функцию очистки этого пути от лишних узлов переделал с последовательной проверки на синхронную с двух концов. Опять же все так. Но) В клиенте есть удобный механизм, который сводит микрорассинхронизации на лету(ускоряя или замедляя). Остальной разницей возникающей в период 20-200мс можно принебречь - ведь эта разница не аккумулируется при движении: сервер считает позицию раньше клиента -> сервер получает новый запрос от клиента на смену координат -> пока сервер считает новую координату и отправляет пакет -> персонаж догоняет позицию и рассинхрона не происходит /если есть минимальные расхождения позиция подхватывается на лету (тут даже до ValidateLocation не доходит, он начинает его слать от разницы в 50-100 координат что ли). Почему так не работает у всех, ведь вроде же все так же. Из-за того, что во время бега координата на сервере стоит то справа-сзади от линии движения, то слева-впереди по пол секунды(в центрах гео координат). При получении запроса на изменение пути, расчет начинается от середины той геоклетки(кроме того на всех l2jях банальный баг и первый тик бега считается путь от 0 точки до нее же) -> клиент замедляет скорость, потому что начальная координата ждет, потом ускоряет скорость потому что координата быстро уходит по центрам геоклеток -> потом поступает запрос на смену пути -> серверная координата уже на 30 координат впереди-справа от текущей точки, а клиент бежит не к ней а к конечной локации-> цикл начинается заного, но уже с расхождениями координат. Я примерно понимаю, в чем может быть проблема. Я тоже не по серверным точкам путь строю, а смещаю точку геоклетки внутри нее самой к вектору движения(т.е. использую дробную часть), геоклетка состоит из 16 точек и при неправильной конвертации можно попасть в соседнюю геоклетку. Правда не понимаю, откуда проблеме быть если конвертация работает правильно)

Зачем вообще рантайм менять вес клеток, еще и с многопоточным доступом. Вес не статичный, пути не хранятся, расчет достаточно быстрый на любой современной машине, чтобы отрабатывать каждый запрос в отдельном потоке за несколько мс. Пакеты медленней доставляются, чем происходит подсчет пути. Это избыточно. Сам алгоритм расчета веса клеток на l2j-ях слабый, расчет производится по т.Пифагора для прямых\диагональных перемещений, а для всех клеток где по соседству есть препятствие - просто статичный большой вес. Этого не достаточно. Поиск пути работает в соответствии со своим алгоритмом, с параметрами задающими вес клеткам). Если разница в высоте между лесенками позволяет присваивать вес клетке, предполагающий перемещение, то почему он должен выдасть гавно. Другое дело каким образом строится и воспроизводится мувинг по узлам построенного пути и учитывает ли он эти особенности) Тут стоить начать с того что в клиенте векторное движение, на сервере декартовое. Точность сопадения координат в общем случае характеризуется точностью результата функции аппроксимации, т.е. в идеальном случае рассинхронизация не должна возникать из-за неверных математичеких расчетах. Поэтому необходимости синхронизации по тикам нет, а для всех остальных случаев в клиенте уже предусмотрен механизм оповещения сервера при рассинхроне(ValidateLocation). Проблемы в отсутствии аппроксимации, а синхронизация по тикам это про другие игры. Вы точно правильно употребляете термины?) Поясните подробнее, что имелось ввиду. Как связан пинг и координаты клиента я не совсем понял. Первая часть - все верно. Вторая часть - не совсем так. Точнее, это происходит не из-за отличия способа изменения координат, а из-за неправильных расчетов координат и самих слоев. На l2j эмуляторах неправильно определяются слои геодаты, когда актор находится между ними. При правильном алгоритме определения слоя, проблем собственно и нет. Спасибо большое за вопросы) Вижу вы изучаете тематику, много терминов связанных с общей и частными теориями работы с графами. Лучше их все пояснять, чтобы не гуглить) В заключении скажу, что большинство проблем с перемещением вызвано неправильными механизмами поклеточного построения дистанции по правильным узлам пути(ведь сами алгоритмы поиска давно придуманы непрограммистами и они одинаковые везде и не только в играх), отсутствии более точной функции аппроксимации координат, ну и тотальные и повсеместные опечатки программистов конечно же

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

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

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