Lineage2TS - HF сервер написанный на Typescript

Bankir написал(а):
Хз уместен ли вопрос (не все прочел).

А что на счет реализации "функционала/кода" по мимо, побегать в мире?
Все что связано с Skill, Zone - на каком уровне, или там реализация L2J - пока что?
Нажмите, чтобы раскрыть...
Работает все кроме клановых функций (не отполированно, но все-же) :
- стартовые локации и квесты (их больше 500, не считая клановых или территориальных)
- телепорты
- мобы дропают предметы, ну и спойлятся тоже
- бафы есть и работают (кубики тоже), скиллы рабочие
- различные малые механики сервера: аукционы, соревнование по ловле рыбы, лотерея, почта, dimensional merchant, крафтинг, enchant для предметов.

Есть системы которые недоработанные:
- семь печатей (не проверенный доступ к катакомбам/некрополисам, сама система все сохраняет и переходит в стадии прогрессии)
- dimensional rift (не работает пока)
- airship и корабли (не работают)
- кланы можно создавать и присоединяться, но все другое не проверенно

В сравнении с L2J есть системы которыx у них нет. Например спауны взяты из L2OFF, или же соревнование по ловле рыбы.
 

MrThirtyOddSix написал(а):
Работает все кроме клановых функций (не отполированно, но все-же) :
- стартовые локации и квесты (их больше 500, не считая клановых или территориальных)
- телепорты
- мобы дропают предметы, ну и спойлятся тоже
- бафы есть и работают (кубики тоже), скиллы рабочие
- различные малые механики сервера: аукционы, соревнование по ловле рыбы, лотерея, почта, dimensional merchant, крафтинг, enchant для предметов.

Есть системы которые недоработанные:
- семь печатей (не проверенный доступ к катакомбам/некрополисам, сама система все сохраняет и переходит в стадии прогрессии)
- dimensional rift (не работает пока)
- airship и корабли (не работают)
- кланы можно создавать и присоединяться, но все другое не проверенно

В сравнении с L2J есть системы которыx у них нет. Например спауны взяты из L2OFF, или же соревнование по ловле рыбы.
Нажмите, чтобы раскрыть...
Прекрасно.
Я вот что хотел сказать, в L2J много реализовано "как увидел, так и сделал" - много описаний не верные (если не разбирали ПТС для понимания).
Так что, если делаете не перспективу и "играбельность", смотрите в ПТС и адаптируйте или полностью наследуйте функционал (я понимаю что там (в ПТС) код повсюду и много завязок).

Тут еще суть всего что пишу, что бы в будущем код можно было на другие протоколы поднять/опустить, или добавлять кастом "вдохнуть что то новое".
В протоколах выше/новее - многое изменили.
 
Bankir написал(а):
Прекрасно.
Я вот что хотел сказать, в L2J много реализовано "как увидел, так и сделал" - много описаний не верные (если не разбирали ПТС для понимания).
Так что, если делаете не перспективу и "играбельность", смотрите в ПТС и адаптируйте или полностью наследуйте функционал (я понимаю что там (в ПТС) код повсюду и много завязок).

Тут еще суть всего что пишу, что бы в будущем код можно было на другие протоколы поднять/опустить, или добавлять кастом "вдохнуть что то новое".
В протоколах выше/новее - многое изменили.
Нажмите, чтобы раскрыть...
Полностью согласен. Я в основном ориентируюсь на PTS. Благо есть доступ к коду AI, да и файлы сервера можно найти. Но насчет "как увидел, так и сделал" тоже использую, так как есть (хотя и недостаточно) видео материал про то что просто нельзя найти другим путем (например передвижение персонажа, или других функций которые просто не описаны в самих данных сервера).

Из того что видел, как код так и сама структура сервера, многое в L2J было построенно таким образом что-бы не использовать данные L2OFF (немного странно звучит). Например умения (skill) уж очень по другому работают, как и сама структура вокруг KnownList на сервере представляет много новых проблем. А про датапак и разделение кода можно уж очень много рассуждать что и как. Но, всетаки нужно отдать должное что без L2J у нас не было бы каких либо серверов.

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

<здесь были яркие скриншоты>
Нажмите, чтобы раскрыть...
Хочу добавить о том что поиск пути происходит по геодате и сервер не использует pathnodes по типу PTS или L2J производных. Геодата была оптимизированна по размеру и сейчас составляет 55% от используемой от L2J (485MB против 889MB). Мне будет интересно сравнить с другими серверами на Яве какая будет производительность у них. Я пока сравнивал с Acis и из того что я видел на Lineage2TS производительность выше (занимает меньше времени) так и путь намного больше сглажен (на Acis выходит много точек на пути).
 
MrThirtyOddSix написал(а):
Из того что видел, как код так и сама структура сервера, многое в L2J было построенно таким образом что-бы не использовать данные L2OFF (немного странно звучит).
Нажмите, чтобы раскрыть...
Это они так пытались избежать юридических проблем с нцсофт.
Правда это все равно не помогло - в свое время их репу на гитхабе один фиг выпилили по жалобе нцсофт.
 
MrThirtyOddSix написал(а):
Мне будет интересно сравнить с другими серверами на Яве какая будет производительность у них
Нажмите, чтобы раскрыть...
Посмотреть вложение Запись 2025-03-22 181109 (video-converter.com).mp4
У меня лимит на поиск 32мс. За это время строится 16 путей(лимит на каждый 2 мс). Обычно время поиска пути не превышает 0.1мс. Вон на видео - самый длинный путь строился 1.96 мс.
 
Aristo написал(а):
и то, и то. 16 путей строятся по паснодам, 1 путь строится по геодате, после чего выбирается лучший по весу.
Посмотреть вложение 85620
Нажмите, чтобы раскрыть...
Зачем использовать оба? Pathnodes должны вроде быть быстрее. Вы тестировали на большие дистанции, ну больше 2000 в длинну? Вроде последний путь вышел длинным, но как-то не ясно сколько занял этот длинный путь. 16ms ?
 
MrThirtyOddSix написал(а):
Зачем использовать оба? Pathnodes должны вроде быть быстрее. Вы тестировали на большие дистанции, ну больше 2000 в длинну? Вроде последний путь вышел длинным, но как-то не ясно сколько занял этот длинный путь. 16ms ?
Нажмите, чтобы раскрыть...
Что в вашем понимании длинный путь? Назовите точку начала и точку конца - я запишу видео.
 
Aristo написал(а):
Что в вашем понимании длинный путь? Назовите точку начала и точку конца - я запишу видео.
Нажмите, чтобы раскрыть...
Как насчет Глудио? Где-то с центра городa то до окружных локаций. Длинный путь например через город. Мне интересно поведение алгоритма в более сложных ситуацияx чем в основом прямые линии.
 
MrThirtyOddSix написал(а):
Как насчет Глудио? Где-то с центра городa то до окружных локаций. Длинный путь например через город. Мне интересно поведение алгоритма в более сложных ситуацияx чем в основом прямые линии.
Нажмите, чтобы раскрыть...
Посмотреть вложение Запись 2025-03-22 184346 (video-converter.com).mp4

MrThirtyOddSix, вот еще пример сложных маршрутов.
Посмотреть вложение Запись 2025-03-22 184946 (video-converter.com).mp4
 
Aristo написал(а):
и то, и то. 16 путей строятся по паснодам, 1 путь строится по геодате, после чего выбирается лучший по весу.
Посмотреть вложение 85620
Нажмите, чтобы раскрыть...
П.с. у тебя не хватает куска ПисЗоны возле храма (потому что его не было ранее в птс, после обновы и расширения блока в проходе - добавили), не критично но все же)
XML: 
    <zone name="giran_town_peace13" type="PeaceZone" shape="NPoly" minZ="-3668" maxZ="-3268"> <!-- [22_22] -->
        <node X="82750" Y="148624" />
        <node X="82834" Y="149754" />
        <node X="83587" Y="150173" />
        <node X="83804" Y="150171" />
        <node X="83810" Y="150098" />
        <node X="83755" Y="150091" />
        <node X="83755" Y="150042" />
        <node X="85099" Y="150031" />
        <node X="85099" Y="150241" />
        <node X="86485" Y="150242" />
        <node X="86496" Y="148637" />
    </zone>

Bankir написал(а):
П.с. у тебя не хватает куска ПисЗоны возле храма (потому что его не было ранее в птс, после обновы и расширения блока в проходе - добавили), не критично но все же)
XML: 
    <zone name="giran_town_peace13" type="PeaceZone" shape="NPoly" minZ="-3668" maxZ="-3268"> <!-- [22_22] -->
        <node X="82750" Y="148624" />
        <node X="82834" Y="149754" />
        <node X="83587" Y="150173" />
        <node X="83804" Y="150171" />
        <node X="83810" Y="150098" />
        <node X="83755" Y="150091" />
        <node X="83755" Y="150042" />
        <node X="85099" Y="150031" />
        <node X="85099" Y="150241" />
        <node X="86485" Y="150242" />
        <node X="86496" Y="148637" />
    </zone>
Нажмите, чтобы раскрыть...

и что то с частью квадратов не то...
там где можно прямо пройти, обходит, квадраты старые или патнод?
 
Bankir написал(а):
и что то с частью квадратов не то...
там где можно прямо пройти, обходит, квадраты старые или патнод?
Нажмите, чтобы раскрыть...
Ну путь не всегда прокладывается прямо, т.к между двумя узлами графа может просто не быть прямого прохода. Если бы дистанция была короче, то путь найденый по ячейкам, был бы более прямым, и был бы более выгодный по весам. Но из-за того, что на большую дистанцию поиск по геоданным не успевает посчитаться за 2мс капа, то выбирается один из путей по паснодам, который не всегда на 100% оптимальный.

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

Движок просто спроектирован для работы в очень высоконагруженных условиях, где производительность ставится на первое место.
 
Последнее редактирование:
Aristo написал(а):
Ну путь не всегда прокладывается прямо, т.к между двумя узлами графа может просто не быть прямого прохода. Если бы дистанция была короче, то путь найденый по ячейкам, был бы более прямым, и был бы более выгодный по весам. Но из-за того, что на большую дистанцию поиск по геоданным не успевает посчитаться за 2мс капа, то выбирается один из путей по паснодам, который не всегда на 100% оптимальный.

Конкретно на скрине, пост обработка пути пропустила этот фрагмент возможно из-за каких-то проблем с прямой видимостью в этом месте. Скорее всего нет прямой связи между узлами.
Нажмите, чтобы раскрыть...
То есть как "не всегда прокладывается" ? Он либо прокладывается, либо нет. Что за алгоритм такой? И почему ограничивать все под 2 мс ? Я понимаю что охота много путей просчитать, но в итоге вы сам алгоритм тормозите под лимит 16 мс. Почему не сделать что-бы и путь был оптимальнее и короче? И почему нужно просчитывать столько производных путей если они сами по себе не оптимальны (много точек, много углов где персонаж может просто увидеть точку конца пути но идет где-то около нее)?
 
MrThirtyOddSix написал(а):
То есть как "не всегда прокладывается" ? Он либо прокладывается, либо нет. Что за алгоритм такой? И почему ограничивать все под 2 мс ? Я понимаю что охота много путей просчитать, но в итоге вы сам алгоритм тормозите под лимит 16 мс. Почему не сделать что-бы и путь был оптимальнее и короче? И почему нужно просчитывать столько производных путей если они сами по себе не оптимальны (много точек, много углов где персонаж может просто увидеть точку конца пути но идет где-то около нее)?
Нажмите, чтобы раскрыть...
Потому, что проложить идеальный маршрут на дистанцию произвольной длины, потратив на такой поиск значительные ресурсы CPU не всегда является хорошим решением. В ситуациях, когда путь ищется каждую секуду 3-4 тысячами игроков и 20-30 тысячами мобов, не всегда разумно выделять под работу алгоритма поиска пути 80% ресурсов CPU. Поэтому поиск пути по ячейкам строит более оптимальный путь с точки зрения качества, но более дорогой ценой, а поиск пути по паснодам строит менее оптимальный путь, но практически без ограничений по дальности и сложности местности. Поэтому, если поиск по ячейкам не успел найти путь за лимит времени 16 мс из 32 мс общего времени поиска, то он прерывается с подозрением, что фронтир поиска расширяется либо не туда, либо расстояние слишком большое. В таком случае итоговый путь будет выбираться из тех путей, которые успел найти движок с паснодами.
 
Aristo написал(а):
Потому, что проложить идеальный маршрут на дистанцию произвольной длины, потратив на такой поиск значительные ресурсы CPU не всегда является хорошим решением. В ситуациях, когда путь ищется каждую секуду 3-4 тысячами игроков и 20-30 тысячами мобов, не всегда разумно выделять под работу алгоритма поиска пути 80% ресурсов CPU. Поэтому поиск пути по ячейкам строит более оптимальный путь с точки зрения качества, но более дорогой ценой, а поиск пути по паснодам строит менее оптимальный путь, но практически без ограничений по дальности и сложности местности. Поэтому, если поиск по ячейкам не успел найти путь за лимит времени 16 мс из 32 мс общего времени поиска, то он прерывается с подозрением, что фронтир поиска расширяется либо не туда, либо расстояние слишком большое. В таком случае итоговый путь будет выбираться из тех путей, которые успел найти движок с паснодами.
Нажмите, чтобы раскрыть...
Так погодите, при чем сдесь огромное количество игроков или там мобов? У вас всe подстроенно под 16 мс поиска пути, ну и что-то там под 32 мс. Ладно. Но у меня на скриншотах ведь все просчитывается меньше 20 мс!!! И это при сглаженном пути. Я понимаю что у вас там пути как-то просчитываются много-много раз. Но я про то что зачем? У вас не 2 мс для пути а больше. И при том что все сглаживание можно сделать очень быстро ( у меня меньше одного мс на все это уходит, при том что тут уже многие тысячи точек а не как у вас ). Так вопрос в том, зачем говорить о каких-то мнимых тысячах игроков если то что у меня и у вас выходит под 16 мс ?
 
MrThirtyOddSix написал(а):
если то что у меня и у вас выходит под 16 мс ?
Нажмите, чтобы раскрыть...
Тоже 16 мс говорите? Уложитесь в 16 мс при таком клике? 1742692800427.webp
Посмотреть вложение Запись 2025-03-23 041720 (video-converter.com).mp4

У меня вот не получается... 1742692848276.webp


А вот при таком? 1742693339156.webp Посмотреть вложение Запись 2025-03-23 042816.mp4
1742693465291.webp
 
Последнее редактирование:
Aristo написал(а):
Тоже 16 мс говорите? Уложитесь в 16 мс при таком клике? Посмотреть вложение 85635
Посмотреть вложение 85634

У меня вот не получается... Посмотреть вложение 85636
Нажмите, чтобы раскрыть...
Я не про то кто быстрее. А про то что у вас достаточно времени сгладить путь. Я ведь работаю с геодатой а вы с pathnodes. Тут большая разница. Не надо сваливать тему на соревнование. До этого еще дойдет.
 
Войдите или зарегистрируйтесь для ответа.
Назад
Сверху