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

Так я и пишу вам, что есть ситуации, когда поиск по геодате не успевает найти хороший путь. Вы мне конкретно пишите
А я вам говорю, что у меня не поиск пути занимает 16мс, а ограничитель стоит на 16мс для одного из видов поиска. Поиск пути по паснодам максимально оптимизирован на скорость и снижения потребления ресурсов, т.к в этом случае баланс между качеством пути и его фактической стоимостью в CPU времени оптимальный и он покрывает 99% кейсов когда игроку нужно прибежать из точки А в точку Б.
 
Последнее редактирование:
То что я вижу так это весь путь будет занимать от 0 до 16 мс. Правильно? Но почему нужно пересчитывать дополнительные пути? Можно например найти один, и сгладить его. Путь будет короче, да и весь процесс намного быстрее.

То что я написал выше о моих и ваших результатах под 16 мс, так это примерные пути которые я видел в ваших видео. Так вот, если у вас можно быстро найти хоть какой-то путь за 2 мс, то можно потратить эти самые 2 мс на сглаживание самого короткого пути. Ну будете искать например семь раз вместо восьми. Выберетe путь покороче и сгладьте его, и будет он намного оптимален.
 
Не всегда есть возможность сгладить путь между двумя произвольными узлами графа, т.к между этими узлами может не быть прямого прохода.

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

А в целом: Поиск пути, хотя бы с 60% реализации как в примерах в этой теме, видел несколько раз (за много лет).
На всех проектах, почти не где его нету, не рабочий для персонажей, или просто ломит на прямую через все квадраты гео))
Ну и гео много где, чисто франкинштейн (как пример: 7 этаж ТОИ, на многих Ессенс серверах, который имеет дырку через которую можно упасть/залететь на 6-й, но квадрат считает что мы на 7-м так и далее.), типа как проходимые стены в инстах, замках, полях.
 
Потому, что такие движки никогда не залетали в шару. В большинстве случаев на серверах стоит либо подлатанный движок Diamond и Drin, либо какие-то вариации лыжного движка(mobius, l2jorg), либо ацис. Все остальное это приватные разработки. Более того, довольно большое количество людей, которые пишут код для эмуляторов l2 абсолютно не понимают что происходит внутри геодвижка и как на это повлиять. Про написание фулл комплекта геодвиг+поиск пути + мувинг я вообще молчу.
 
Я не про шары, я чисто про крупные сервера, у них нету и 60% (те которые на рынку по 5+ лет,у них все ровно, и то не всегда их кастом прекрасен, хватает и там дыр и приколов - привет скрайд))
 
А я как раз про шару. Нет отправной точки, с которой можно на среднем уровне скилла подлатать сносный геодвиг и получить что-то неплохое. Т.е все доступные для типичного кодера образцы геодвижков не дотягивают даже до среднего уровня. Отсюда и проблемы, что вроде как бы надо бы переписать движок, но там изначально все сделано не ок и его по хорошему надо писать с нуля, забив на фиксы существующих реализаций.

Это касается как качества построения путей, так и потребления ресурсов.
 
Оффтоп:
Понимаю, имею на примере 1 крупный проект Ессенса, который несколько лет, так и не решался сделать этого.
Потому как: долго, трудоемко, да и кто это оценит (максимум 10-15%), да еще и бабла хотелось бы, схавают (и хавали годами) и в таком виде, а то что при пвп 300+ на 300+ (да да, и такое было на классик серах), сервер трагично падал или "много интересного происходило", не важно, рестарт и далее поехали)).
Но кажись прибыль позволила что то да сделать с этим, все скатилось к "трусам баюма" а не качеству и "логичному функционалу", в итоге: урон через стены, прыжок на голову "из не откуда" - потому что так пофикшеный движок переносит персонажей в проблемных квадратах, почти из любого квадрата в мире (при условии, что есть бага на взятие в таргет на расстоянии на пол карты).
Крч, пусть процветает ваш запил.
 
Для тех кто желает попробовать что-то новое, можете проверить как работает обновленная L2 прокси, часть проекта Lineage2TS. Прокси может быть использована как для скрытия IP адреса игровых серверов, так и для локально настроенного клиента (на localhost), который теперь может соединяться не локальными игровыми серверами через интернет (или по локальной сети). Можно даже проверить свой клиентский траффик командой в чате ".proxy-stats".

Здесь можно почитать про установку прокси с помощью докера:
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация


For those that would like to try something new, there is now docker image for proxy, part of Lineage2TS project. Basic usage would be to either hide IP address of your login/game server or perhaps be able to play on remote game server without changing config on your L2 client (say your client is setup to expect game server on localhost, start proxy pointing to remote game server and your L2 client will not know the difference!). Proxy works with Lineage2TS servers or L2J HF5 servers. It even has voice commands (the one you type in chat, without being admin or not). For example once you have entered game, you can type ".proxy-stats" and in your L2 client you will see chat messages about how long have you been playing or how much traffic in KiB you have used!

Docker instructions available here:
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация


And don't forget that you only need to specify remote login server IP or hostname via environment variable in docker cli as "PS.server.LoginServerHost=<host or IP>" Compared to other solutions, such as having an HAProxy or Nginx routing packets to your L2 servers, there is minimal setup using Lineage2TS proxy (no need to configure IP addresses or particular proxy modes on both login/game servers vs HAProxy/Nginx). Literally all you need is remote login server IP and proxy will work all the magic!

And to add a bit more interesting things. Lineage2TS docker images now use much less space (all using alpine images). With login/game server image just under 198MB (that is with all the geodata and necessary L2 world data). Proxy image is just shy of 59MB. Very easy to deploy and shutdown using docker.

Lineage2TS Proxy теперь может работать с серверами Interlude, как и HighFive. Тестировалось все как на сервере Lineage2TS, так и L2J HighFive, так и Acis. Нужно просто прописать IP адрес логин сервера и прокси все сама поймет и сделает. Инструкции по докеру (также можно использовать podman) находяться по ссылке:
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация


Жду отзывов!

Please checkout Lineage2TS proxy. It now supports Interlude and HighFive server/clients. No additional configuration is needed, proxy will automatically work with either client/server protocol. The only thing you need to provide to proxy is IP address of login server and proxy will take care of the rest. Here is document that describes how to run proxy using docker (or podman, if desired, any OCI platform will use similar settings) :
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация


Хочется добавить в дополнение что проект уже использует автомачиеское тестирование сервера Lineage2TS с использованием cucumber-js . Написанно 395 тестов которые тестируют различные механики сервера, от создания персонажей всех классов и полов, до крафтинга (common и dwarven), покупки вещей через магазины, проверка работы warehouse, Dimensional Merchant предметов и телепортов у npc. Все проверяется автоматически с использованием 24 одновременных клиентов (то есть каждый тест програмный клиент должен войти в игру самостоятельно, зачастую создавая новый персонаж) за около семи минут (это более 160 минут если бы это все делал один клиент а не множество). Тестирование и сами значения что я привел выже можно увидеть здесь :
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
 
Я так понимаю в proxy решает логику какие оп коды использовать если запрос к interlude или к hf? С с датапаком как решается вопрос?

Какой best practics для создания мульти хроник сервера? На будущее думаю как сделать переход с C1 на C2
 
Отвечу по порядку вопросов.

1. Да. Interlude и HF клиенты используют одинаковый подход для соедиения с логин сервером. Тут ничего не изменилось. А вот когда клиент для игрового сервера подсоединяется к прокси, он посылает пакет с ревизией протокола клиента (скажем так версия клиента), прокси перехватывает это значение в зависимости от оп-кода (то есть изначально он настроен слушать на определенные оп коды и ждать пакет ревизии клиента, после получения пакета прокси больше его не ждет). И дальше это значение используется постоянно в нескольких пакетах для установки ключей или же данных соединения (шифрование устанавливается как между клиентом и прокси, так и прокси и игровым сервером для того что-бы можно было пересылать дополнительные пакеты в обои стороны).

2. Датапак не ипользуется для прокси. На игровом сервере датапак состоит из базы данных SQLite со множественными таблицами. Если нужно изменить или сохранить датапак, это можно либо самому сгенерировать его через cli проект, либо при использовании докера установить параметры директорий файлов. У меня вопросов как таковых нет, все работает быстро и эффективно. Как я раньше и говорил очень быстро по сравнению с серверами на Яве - весь сервер загружается за меньше чем пять секунд.

3. Нужно просто переносить все пакеты новых хроник. А потом смотреть как эти пакеты интегрировать. Будут новые пакеты, но и старые тоже будут изменены что будет влиять на интеграцию кода от нижних хроник. Само ядро сервера не будет значительно измененно так как системы например инвентаря или же квестов будут работать как и раньше, но дополнительные данные из измененных пакетов должны будут где-то сохранятся. Ну и в конце концов нужно достать данныe для датапака файлов так как будут обновления как и для npc так и скиллов.
 
Идея с прокси мне нравится но не затрудняет ли она разработку?
У меня была идея создать папку extends и там хранить пакеты /C1/, /C2/ и управлять ими через конфиг при запуске.

Есть желание делать разработку и под другие хроники но без усложнений. Чтобы пилить один проект а не под C1 отдельно по С2 отдельно и т.д.
 
Прокси перехватывает пакеты по простой причине что нужно переписать IP адрес игрового сервера который нам посылается через логин сервер. Сложно ли это? Немного, так как сложность состоит в понимании как игровой клиент соединяется с обоими серверами. Например у прокси есть четыре клиента: клиент -> прокси логин, прокси логин -> логин сервер, клиент -> прокси игорового сервера, прокси -> к иговому серверу. Это четыре понятия как пакеты должны передаваться в обе стороны. Я понимаю что вопрос частично риторический, так как пo простому если сделать, без перехвата пакетов, то у вас будет тот же самый NGINX или HAProxy, только не такой быстрый. Хочется добавить что прокси на данный момент не имеет аналогов. Это просто не идет в сравнение как с HAProxy/NGINX так и других прокси написанных на Яве. Например можно написать свои комманды чатa (voice command) для прокси, что-бы например автоматизировать некоторые вещи или пакеты для игрового сервера. Настройки также позволяют блокировку IP адресов как индивидуальных так и сабнета. Логирование всеx сообщений можно сохранять через OTEL протокол. Ну и в конце концов, прокси передает IP адрес клиента через первый пакет соединения как к логин серверу так и на игровой сервер (могу детально показать как и что, оба IPv4 и IPv6 поддерживаются прокси). То что в принципе делается через нормальный proxy protocol v1 или v2 на обычных прокси HAProxy. Да, нужно итегрировать поддержку на свой сервер, но это нужно делать ужe в любом случае.

Насчет пакетов можно посмотреть как все реализированно на L2JMobius где у ниx есть таблица пакетов и их оп-кодов. Не сложно. Но проблема будет не в том что-бы какой-то клиент поддерживать, а как клиент работает с сервером. Например когда я пытался интегрировать поддержку прокси для C4 сервера, то оказалось что у такого старово сервера используется другое шифрование. Это так, к слову о том что не все клиенты работают одинаково. Некоторые будут ждать дополнительных пакетов от сервера хроник повыше. И это нужно учитывать при разработке логики когда пакеты отсылаются. Есть пример на пакет InventoryUpdate, где он может применяться на HighFive но он не всегда может использоваться по сравнению с хрониками повыше. А такой пакет например не существует ниже Interlude. И как такие пакеты тепер использовать? Нужно учти что в зависимости от клиента некоторые системы игрока могут вообще не использоваться, или использоваться в достаточно новом виде.
 
Мне вот интересно, ты пишешь используешь SQLite

И скажем кто-то захочет платежную систему либо голосовалку, запилить а с сторонннего сервиса к твоей бд как запрос уйдет?)

Потому что к SQLite со стороннего сервера тупо не подключишься ))) опять же танцы с бубном

Советую Используй PostgreSQL, в связке с Prisma ORM или TypeORM
Если сервак пилишь на Node js
 
Во первых нужно определить задачу ну и потом можно выбрать технологию.

Но, отвечу как я бы решил такую проблему. На даннный момент существует по крайнем мере два решения:
- если нужно напрямую записать что-либо в главную базу данных, то можно это сделать через прямой доступ к файлу SQLite контейнера (не буду описывать как этот файл можно вывести через конейнер, но это достаточно просто через конфигурацию докера). Это при том что доступ будет именно через файловую систему на диске сервера
- использовать RPC соединение к игровому серверу. Это наиболее предпочтительный вариант. Почему? Изменениe данных в БД проблематично, так как нужно будет строить цепочку обновления данных на самом игровом сервере. Написали что-либо в базу данных, а тепер нужно ждать пока игровой сервер сам прочитает, поймет! что нужно делать, и как-то реагировать. Так вопрос в том, почему не соединиться с сами игровым сервером напрямую и дать ему задачу, в обход базы данныx? Только в том случае если у нас НЕТ игрового сервера, а только осталась база данных, которая представляет по сути хранение данных. Вы таким образом можете использовать другие файловые технологии по типу чти и датапак используется. Сервер прочтет их что-то с ними сделает.

Можно конечно использовать базу данных на Mysql/MariaDB. Нет проблем в этом. Просто нужно написать SQL для поддержки сервера. На сервере Lineage2TS это все можно очень просто сделать, даже напрямую скопируя SQL код от SQLite. Но, почему же я этого не сделал? По очень простой причине. Прямой нужнды в этом нет так как есть другие пути доставки информации к серверу.
 
Я дал тебе совет по выбору СУБД
Но решать тебе )) никто не будет разрабатывать доп платежки либо фичи с подключением с RPC

Народ привык создавать юзеров
И для сайту отдавать юзера с правами
 
Как я и выше описал, не нужно зацикливаться на том что Ява делала много-много лет. Хотите нормальную по вашим словам БД? Можно все устроить. Но есть другие решения.

Я против каких-либо ORM. По простой причине что они достаточно проблематичны, так как очень уж много делают и непонятно как и что там оптимизировать. Я использую SQL код напрямую.

Зачем мне это? Это нужно вам. Ваш ведь совет. И как я сказал раньше будут брать советы от людей которые во первых не зацикливаются на старых методах и технологияx. А во вторых не приходят и ожидают что такие советы ценны. Нет, не ценны.
 

Ты рофлишь? Используй дальше SQLite я уверен когда вы его в тестовом режиме запустите все равно перейдете на PostgreSQL, MySQL подобные субд с юзерами а не локальным хранилищем))

Потому что элементарные запросы к бд чтобы вытянуть с бд нужно еще настраивать rpc соединение.)) Или rest api делать ))

Не принуждаю, но уверенно скажу что вы поменяете СУБД ))
 
Давайте определим о чем мы ведем беседу. Я не против того что нужно будет поддерживать другие БД. Сейчас поддерживается SQLite как главная база данных. Поддержка SQLite без особых библиотек вот-вот уже почти готовa в Nodejs.

Если вы про то что вы хотите сопоставить соединение БД и RPC на игровом сервере, это нужно детально смотреть сколько и какие запросы будут. Это совершеннo другая проблема чем просто имитировать соединение к БД. На Яве это использовалось лишь потому чтo никто, нигдe не захотел по другому сделать. Вот и все. Это застой. Но людям как вы и напомнили это все комфортно.

Kenrix написал(а):
Не принуждаю, но уверенно скажу что вы поменяете СУБД ))
Нажмите, чтобы раскрыть...
Вы просто хотите каким-то образом быть правы или у вас есть другие факты которые могут подтвердить такое будущее?
 
Реакции: kick
Войдите или зарегистрируйтесь для ответа.
Меню
Вход
Регистрация
Данный сайт использует cookie. Вы должны принять их для продолжения использования. Узнать больше…