PointerRage

Resident
  • Content Count

    109
  • Joined

  • Last visited

  • Days Won

    6
  • Feedback

    0%

PointerRage last won the day on April 20

PointerRage had the most liked content!

Community Reputation

123

7 Followers

About PointerRage

  • Rank
    Постелил коврик

Информация

  • Пол
    Не определился
  • Город
    Virtual Reality
  • Интересы
    Java, C/C++, C#

Контакты

Recent Profile Visitors

3393 profile views
  1. 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 - механизм уклонения (обхода) от динамических актеров. Балансное дерево - дерево, которое имеет сбалансированное количество количество веток и листов на них, на каждом уровне глубины/высоты.
  2. PointerRage

    Brawery - High Five

    Рантайм изменения веса клеток для патчфинда есть? Это для процессинга avoidance, тобишь, обход других актеров во время поиска пути. Или сделано, как обычно, костылем?:) Если есть, то как разрешили задачу многопоточного доступа на модификацию веса клетки? Потому-что в этих ваших l2j-ях по другому невозможно, из-за того что общего тика сервера вообще нету. Что с перестроением уже найденных путей при изменении веса клеток? Или может быть запилен avoidance по столкновениям? В таком случае какой вид деревьев использовали и опять же, как решили задачу с многопоточным доступом модификации BVH дерева? Поиск пути по прежнему выдает говно в случаях с трехмерными плоскостями? (Как пример лестница у кристала в замках) Как делаете синхронизацию координат сервер-клиент в условиях авторитарного сервера, да еще и без снапшотов (общих тиков, то у сервера нет, чтобы их возможно было делать)? Как экстраполируете координаты клиента, в условиях того, что получение пинга, это вообще отдельный пакет? Касательно этого момента: Я понял, что имелось ввиду и что это за фикс. Но скажу к слову: в ретейле, непосредственно, векторное изменение координат идет по дискретным точкам, тобишь по гео-точкам. Результаты игнорирования этого можно посмотреть в любом l2j эмуляторе, со всякими ошибками координат около преград, из-за чего трассировщик высоты ломается и выдает неверный слой геодаты в многоуровневых локациях. Хотели нормальных вопросов и дискаса - получите;)
  3. PointerRage

    JTS по сборке

    Конечно есть. Вон сколько спецификаций написано для различных дебагеров. Удачной отладки.
  4. PointerRage

    JTS по сборке

    Специальная защита от людей, которые не могут в код, для шаровой версии.
  5. PointerRage

    unreal script

    Конкатенация строки. Смотреть в экспортах/импортах скомпилированного скрипта. Если какой-нибудь интерлюд, то в nwindow.dll.
  6. PointerRage

    Проблема со входом.

    Берете IDA, смотрите где вызывается функция connect, проходите выше по стеку и ищите где собирается sockaddr структура и патчите номер порта для нее. Возможно придется пройти выше по стеку, если в функцию передается порт аргументом. Все это делается легко и просто даже без отладчика. Можете еще попробовать это говно, которое я писал миллион лет назад, только нужно будет вручную добавить выходную DLL в импорт engine.dll/core.dll/любойдругойDLLл2.
  7. Все можно. Да хоть миллион лет могут пилить. Законы рынка еще никто не отменял и нужно быть совсем отбитым, чтобы в это не врубаться. Обьясняю на пальцах. Просто тут суть, как у неуловимого Джо. Он же неуловим потому-что нахрен никому не нужен, так и тут. Ретейл механики на джаве неуловимы потому-что нахрен никому не нужны. За исключением, может, 1.5 человек, которые и сами не знают, как это должно работать, и не будут знать, потому-что реверсить ретейл слишком "сложна". А знаете почему крупнякам не нужны эмуляторы, которые жмут ретейловские механики? Потому-что есть ретеил. Нахрена тратить кучу денег на их реализацию в джаве? Просто деньги, не более того, достаточно уметь считать.
  8. PointerRage

    Телепорт к живому РБ

    Не мешай, тут люди грин рубят на уникально-легендарных возвращениях легенд.
  9. PointerRage

    Нужна помощь с гео (LostWorld)

    Если отключать увеличенный вес точек, которые граничат с непроходимыми элементами графа, то можно получить интересный кейс с диагональными точками, которые могут участвовать в конечном пути: ooToo oTxxx oTxxx Где о - открытая точка, x - непроходимая точка, а T - точка, которая попадет в результат поиска. В контексте обсуждаемой говноигры, это даст зацеп за угол и ломание экстраполяции движения на клиенте, и как следствие - кровавые слезы администратора сервера. Данный кейс надо учитывать и добавлять диагональным точкам граничащим с непроходимыми точками дополнительный вес. Также, для сглаживания пути, могу порекомендовать этот алгоритм (следует применять после примитивной очистки средней точки из тех точек лежащих на одной оси, потому-что таким образом будет меньше проходов "тяжелой" очистки). И да, если серьезно, то вес точки -- это одно, а эвристика -- другое. Не следует путать теплое с мягким.
  10. PointerRage

    теория поиска пути

    Обычный A* по евклидовому расстоянию + модификатор высоты. Везде применяется стандартная практика - поиск по графу. В жтс, как и везде, для построения графа используются данные из геодаты по проходимости точек.
  11. ITT врыв от бывшего разработчика этого говна. fork2/fork3 был основан на второй люцере. Думаю, что Вы уж точно должны знать, где он стоит и по сей день. Больше я не видел производных работ от второй люцеры, поэтому, видимо, почти один:) Ну и ковырять без прода - гиблое дело, впрочем, так везде. Рекомендую забить на это говно и просто использовать некоторые механики оттуда [в плане легковесных библиотек для построения кода], которые были дописаны и улучшены в fork2/fork3, найти их можно тут (улучшенные гитавовские слушатели [с поддержкой многопоточного уведомления и предикатами], шедулер а-ля спринг, стартап система). Некоторые из этих библиотек используется другими лыадвыа командами, в некоторых эмуляторах серверов (привет BDO-Emu ), а некоторые и вообще в проектах, которые не связаны с пейратством. Внезапно, он работает. Хотя кое-где есть довольно таки критические баги. Ну и огромное количество легаси кода с 2006 года тоже дает о себе знать. Забивать бульдозером маленький гвоздь, да? Я смотрю, что это последнее время становится популярным, впрочем, также, как и использование новомодных языков. Давайте по честному: зачем Вам спринг в игровом сервере? Спринг отлично подходит, если Вам нужно за день написать какой-то веб-сервис с мордой, который получает данные по типу REST из какой-нибудь Уругваи. Вот для этого он создан и в таких задачах его применение - идеально. В остальных случаях, он будет избыточен и можно легко и просто выкинуть 98% этого всего говна, что там есть. Также, как если и писать нормальный веб-сервис не за день, а за месяц, на нормальном EE 7.0 с беком имплементации от какого-нибудь TomEE или IBM WebSphere. Вот что требуется в игровом сервере? Депедли инжекты? Autowire из бута легко заменить на Guice. Репозитории из спринг орм, в виде, "ляп-ляп интерфейс и в прод" -- легко заменяются абстрактным CRUD репозиторием. Что еще? А больше в игровом сервере и не нужно. Ну, окей, вывести REST апишку: это можно сделать и с помощью встроенного уэб-сервера в джаве (его вроде бы не удаляли из стандартной библиотеки, верно?).
  12. PointerRage

    Dell Inspiron 13 5378[PointerRage]

    Продано. Тред можно закрывать.
  13. PointerRage

    Java 9

    Извините, но Вы говна объелись? Какое нахрен системное программирование на джаве? А про веб -- просто смешно. Вы хоть одним глазком посмотрите на энтерпрайз, где и используется в большинстве случаев джава, а только потом говорите. PHP видишь ли у них тут погоняет вебом. Хотя спорить не буду, для страничек-бложеков васи пупкина -- рулит Если интересно где же она, та самая джава, то откройте любой банк и у каждого второго будет бекэнд на джаве. Плюс почти все банк-клиенты для юридических лиц - запилены на джаве. Я уже не говорю про другие секторы, кроме банковского. По сабжу: релиз говно, он нужен по большей части для разбиения самого RT на части, что даст плюсы всяким там андроид-девам, плюс начальные реализации нескольких интересных проектов, которые будут доступны в полную силу лишь в J10/J11, плюс улучшения для других JVM-языков (что сделано не на уровне языка, а на уровне самой JVM и байткода) типа котлина, скалы, груви и так далее. Остальные улучшения, типа стек-валкинга - смотрятся очень бедно и, в принципе, они не имеют никакого влияния.
  14. PointerRage

    Dell Inspiron 13 5378[PointerRage]

    В модификации, которую предлагаю я, на всех сайтах цена от 52 000 до 65 000.
  15. Просмотр файла JTS Source 2015 Исходный код JTS 2015 года. Такой же, который был и в квесте. Добавил PointerRage Добавлено 30.12.2017 Категория Исходники серверов Автор JTS Team Хроники High Five