Таблица лидеров

Доброго времени суток Форумчане. Выставляю на продажу Мультиязычный Патч под Interlude. Так же могу сделать МультиПатч под любые другие хроники! По желанию добавлю любые модификации P.s: По всем вопросам в скайп: iPerfect_dev Добавлена смена языка при входе на сервер. Что есть: Правила сервера, информация классов при создании, настройки, весь игровой текст. 1.Изменение языка через опции. 2.Перевод Правил сервера, Информация классов, Все системные сообщения. 3.2 Вида озвучивания в игре (Рус/Англ) 4.Добавлена 4-я панель для умений (по надобности могу добавить еще) 5.Добавлена возможность давать пати через Таргет. 6.Добавлена возможность предлагать торговлю через Таргет. 7.Добавлена возможностью быстрого "ПМ" через Таргет. 8.Добавлена возможностью сортировки инвентаря. 9.Сделан фикс отоброжение Клан/Альянс (значков/имен). 10.Сделан фикс отоброжение значков расскладки клавиатуры в чате. 11.Добавлено включение отоброжение FPS в игре. 12.Исправлен корретный перенос слов при смене языка. 13.Исправлено корректное отоброжение адены. 14.Патч ежедневно дорабатывается (могу внести изменения по просьбе покупателя) 15.В патче нету лишних dll и какой либо криптовки (кодировки) файлов 16.Добавлен полный Блок. 17.Добавлена опция блокировки опыта. 18.Добавлена смена языка при входе на сервер. 19.Добавлен автоассист (с обновлением каждые пол секунды) . 20.Добавлены бинды на рабочую панель умений . 21.Добавлено автовключение Arcana Power . P.S: Покупателям предоставляются файлы без каких либо кодировок.

Это понятно, ибо эвристика. Я говорю про саму реализацию avoidance динамических актеров, чтобы движущиеся актеры не сталкивались и рекалькулировали свой путь, для избежания столкновений. Очевидно, что это реализуется в рантайме:) Обычно такие задачи решаются отложенным пересчетом пути актера и динамическим изменением веса клетки, по которым, другие актеры двигаются (в случаях дискретной сетки). В более хороших и правильных реализациях используются BVH деревья (причем обычно достаточно балансного AABB дерева), чтобы реализовать приемлемый avoidance. Кстати говоря, второй подход также используется в физических движках, но это уже тема для иного разговора. Потому-что на моей памяти, во всех l2j-ях эврестическая стоимость клетки имеет вид: D(sqrt(x*x + y*y + (z*z) / modifier)) - или нечто похожее. Впрочем, даже выставляя "честную" эвристику по Z-оси, результат задастую выходит не таким, какой ожидается, из-за того, что вес клеток по "правильному" пути намного выше, чем вес до, условно, неверного пути. Сюда же можно добавить и то, что во всех l2j-ях реализация поиска пути работает по алгоритму "первый лучший". Не согласен. Рассинхронизация возникает только потому-что игра сетевая, а сеть имеет задержку. К тому же, сюда стоит еще добавить, что методы передвижения актеров на сервере и клиенте разные, из-за чего результаты получаются различными. В добавок, стоит добавить, то что на клиенте расчет движения осуществляется с помощью чисел с плавающей точкой, только этого достаточно, чтобы получать различные результаты на различных машинах. Я уже не говорю о том, что на сервере везде используются натуральные числа, которые еще из-за аппроксимации из/в дискретные координаты, ну совсем уж, не похожи на клиентский результат. Минутка шуток: администратор локалхоста недоумевает, как связаны координаты присылаемые клиентом серверу с пингом, потому-что у него нулевой пинг. А если серьезно, то они непосредственно связаны тем, что: 1. Сервер по расчетам движения всегда впереди клиента, потому-что пакет MoveToLocation не доставляется моментально на клиент. 2. Клиент при отправке запроса ValidateLocation, отправляет координаты, которые актуальны на текущий момент. Пока пакет обработается в очереди, пока отправится, дойдет до сервера, сервер его обработает... Пройдет значительное время, чтобы процессинг на сервере сказал: "нифига, эти координаты неверны". А отсутствие снапшотов не дает заглянуть в прошлое и сверить правильность координат на момент времени отправки клиентом пакета. Именно поэтому я предположил, что может использоваться экстраполяция координат для их проверки, чтобы довести эти клиентские координаты до "текущей точки времени" и проверить, очевидно, их правильность. 3. Если актер движется и сервер меняет ему путь, то, очевидно, в пакете MoveToLocation должны быть указаны "начальные" координаты и "конечные". К "конечным" нет никаких вопросов, однако, начальные координаты следует экстраполировать по трип-тайму, тобишь, времени пакета в пути, либо, в ином случае, клиенту начинает быть довольно плохо. Определение слоев, да, есть такая проблема, но я не о ней говорю на данный момент, потому-что это исправляется легко и быстро, да и обсуждать это как-то не очень интересно:) Попробуйте на клиенте подойти очень близко к преграде, а после этого сконвертируйте координаты в дискретные. Вы будете неприятно удивлены, что в части кейсов, дискретные координаты будут указывать на "пустоту", тобишь, на внутренности, например, статик меша. Причем, это происходит из-за самой алгоритмики перевода реальных координат в дискретные. Соответственно, перевод таких дискретных координат в реальные, даст точку внутри статик-меша, там где клетка гео-даты вообще отсутствует. Возможно Вы просто не замечали таких кейсов, но когда я еще занимался этими всеми l2j-ями, причем на довольно нагруженных проектах (от 1 200 онлайна до 2 000), такие проблемы всплывали, однако, не сразу. Спасибо за ответ. Я, если честно, даже не надеялся на ответ. Всегда приятно обсудить интересные технические задачи и способы их решения:) На счет терминов: BVH дерево - дерево хранящее внутри себя набор геометрических фигур. AABB дерево - дерево хранящее внутри себя "коробки" актеров. Если простыми словами, то "коробка" - прямоугольник (либо же куб, в случае хранения трехмерных коробок), который включает в себя полный размер актера. AABB - "коробка", см. AABB дерево. Avoidance - механизм уклонения (обхода) от динамических актеров. Балансное дерево - дерево, которое имеет сбалансированное количество количество веток и листов на них, на каждом уровне глубины/высоты.

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