All Activity

This stream auto-updates     

  1. Yesterday
  2. Rozhek

    Brawery - High Five

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

    Не запускается GameServer

    так делал ? -Xms512m -Xmx1024m сборка какая ? может ей не 8 ява нужна
  4. Narked_UA

    Не запускается GameServer

    Ява стоит 8, оперативки 2гб но я менял в батнике мин и макс всеравно не стартует.
  5. Rovskoi

    Не запускается GameServer

    java x32 не может сожрать больше 4гб, меняйте джаву или ставьте xmx на 3gb
  6. lZeusl

    Не запускается GameServer

    Ява стоит ? путь прописан ? оперативы сколько ?
  7. Доброго времени суток, подскажите пожалуйста в чем проблема...
  8. Купил патч и еще некоторые наработки. Остался доволен, всем советую!
  9. PointerRage

    Brawery - High Five

    Это понятно, ибо эвристика. Я говорю про саму реализацию 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 - механизм уклонения (обхода) от динамических актеров. Балансное дерево - дерево, которое имеет сбалансированное количество количество веток и листов на них, на каждом уровне глубины/высоты.
  10. Хороший специалист, рекомендую!
  11. Rozhek

    Brawery - High Five

    Зачем вообще рантайм менять вес клеток, еще и с многопоточным доступом. Вес не статичный, пути не хранятся, расчет достаточно быстрый на любой современной машине, чтобы отрабатывать каждый запрос в отдельном потоке за несколько мс. Пакеты медленней доставляются, чем происходит подсчет пути. Это избыточно. Сам алгоритм расчета веса клеток на l2j-ях слабый, расчет производится по т.Пифагора для прямых\диагональных перемещений, а для всех клеток где по соседству есть препятствие - просто статичный большой вес. Этого не достаточно. Поиск пути работает в соответствии со своим алгоритмом, с параметрами задающими вес клеткам). Если разница в высоте между лесенками позволяет присваивать вес клетке, предполагающий перемещение, то почему он должен выдасть гавно. Другое дело каким образом строится и воспроизводится мувинг по узлам построенного пути и учитывает ли он эти особенности) Тут стоить начать с того что в клиенте векторное движение, на сервере декартовое. Точность сопадения координат в общем случае характеризуется точностью результата функции аппроксимации, т.е. в идеальном случае рассинхронизация не должна возникать из-за неверных математичеких расчетах. Поэтому необходимости синхронизации по тикам нет, а для всех остальных случаев в клиенте уже предусмотрен механизм оповещения сервера при рассинхроне(ValidateLocation). Проблемы в отсутствии аппроксимации, а синхронизация по тикам это про другие игры. Вы точно правильно употребляете термины?) Поясните подробнее, что имелось ввиду. Как связан пинг и координаты клиента я не совсем понял. Первая часть - все верно. Вторая часть - не совсем так. Точнее, это происходит не из-за отличия способа изменения координат, а из-за неправильных расчетов координат и самих слоев. На l2j эмуляторах неправильно определяются слои геодаты, когда актор находится между ними. При правильном алгоритме определения слоя, проблем собственно и нет. Спасибо большое за вопросы) Вижу вы изучаете тематику, много терминов связанных с общей и частными теориями работы с графами. Лучше их все пояснять, чтобы не гуглить) В заключении скажу, что большинство проблем с перемещением вызвано неправильными механизмами поклеточного построения дистанции по правильным узлам пути(ведь сами алгоритмы поиска давно придуманы непрограммистами и они одинаковые везде и не только в играх), отсутствии более точной функции аппроксимации координат, ну и тотальные и повсеместные опечатки программистов конечно же
  12. Цена за анонсы?
  13. Продажа полных наборов оружия Antharas, Valakas, Lindvior, Fafurion. LINEAGE II. Любые хроники Antharas Valakas Lindvior Fafurion Все вопросы только в Skype. Всю информацию Вы можете найти у меня в профиле.
  14. Last week
  15. Нужно наполнение форума/добавления сервера в анонсы без кнопок пишите в Лс ваши контактные данные
  16. ◄√i®uS►

    Услуги ◄√i®us►

  17. amigomc777

    FreeKassa ~> настройка ~>помощь

    Добавил в конфигах менять ничего не нужно ?
  18. donero

    FreeKassa ~> настройка ~>помощь

    items_delayed добавьте эту таблицу,и измените
  19. sm86

    Lineage II: Fafurion

    //admin И нужно чару в базе поставить acceslevel 100, в таблице characters
  20. Hello. I have issue with moving with summons. They bad following character and bad attacking. Also teleporting back sometimes.. PM with your skype contacts JUST IF YOU SKILLED and have knowledge about it. +/- 100Eur for fix ! example whats happening +/- here:
  21. Прошу помощи по настройке FreeKassa для сборки PW все кто пытался не смог помочь, или кидали 3 чела , кто поможет накину $ skype winbets11 Необходимо сделать что бы донат монеты приходили Online .
  22. Есть где то нормальный мануал по настройке ВДС ? Или нужен тот кто настроит через ТВ, цену в скайп.
  23. Avenger

    Ошибка GS

    спс помогло.
  24. Evolution

    Ошибка GS

    id поменяй 50000 на 32500 и меньше
  25. Avenger

    Ошибка GS

    Как исправить эту шляпу?
  26. Se1dhe

    Ошибка GS

    Ожидается шорт, а ты передашь не его
  27. Avenger

    Ошибка GS

    Всем привет нужна ваша помощь! Решил сделать новые рецепты на сервере. Вроде всё делаю правильно, но рецепт не хочет учится. Во время загрузки GS такая: java.lang.NumberFormatException: Value out of range. Value:"50000" Radix:10 at java.lang.Short.parseShort(Short.java:119) at java.lang.Short.parseShort(Short.java:143) at core.gameserver.data.xml.holder.RecipeHolder.loadFromXML(RecipeHolder.java:134) at core.gameserver.data.xml.holder.RecipeHolder.<init>(RecipeHolder.java:39) at core.gameserver.data.xml.holder.RecipeHolder.getInstance(RecipeHolder.java:50) at core.gameserver.data.xml.Parsers.parseAll(Parsers.java:73) at core.gameserver.GameServer.<init>(GameServer.java:184) at core.gameserver.GameServer.main(GameServer.java:400)
  1. Load more activity