Написание сервера для lineage 2 chronicle 1 на node.js

Добавлен VisibilityManager для управления окружением.
* Показать кто рядом
* Удалить кто уже далеко

 

* Стартовали работы по AI. (Обработка bypass, взятия квеста Fighter tutorial)

 
А он двигается по маршруту(с персонажами на борту) или пока статичен ?
Статичен. Было интересно как работает пакет Vehicle.

В какой-нибудь версии релиза будет полная реализация корабля)
 
* Добавил первый квест на карту
* Работа по AI для Carl(Npc человек) и Keltir(Npc волк)
* Переработана архитектура AI (Базовые методы)
 
Идея создать 1000 ботов и раздать им скрипты дабы сделать сервер "живой"

Кто-то бегает, кто-то качается а кто-то торгует.

На данном этапе бот умеет фармить мобов и собирать дроп (видео постами раньше)

2025-06-09_18-49-20.webp
 
* Добавил заряд души
* Таймер по регенерации HP, HP
* Смерть игрока
* Восстановление игрока после смерти
* Покупку предметов у NPC
* Waypoints для ботов (Кружат вокруг стеллы в талкине)


Техническое обновление
* Миграция с MongoDB => PostgreSQL

Монга была неудобна.
 
Техническое обновление
* Миграция с MongoDB => PostgreSQL

Монга была неудобна.
А почему PostgreSQL ? Можно ведь MariaDB/MySQL. Ну либо там другую базу данных на SQL, их уж очень много. И кстати почему не MongoDB и почему она не удобна в сравнении с PosgreSQL?

Кстати к своему проекту я бы как-раз и приделал бы PosgreSQL, но это сейчас даже очень не критично. И только для поддержки множества серверов сразу. А как вы планируете использовать такую базу данных?
 
А почему PostgreSQL ? Можно ведь MariaDB/MySQL. Ну либо там другую базу данных на SQL, их уж очень много. И кстати почему не MongoDB и почему она не удобна в сравнении с PosgreSQL?

Кстати к своему проекту я бы как-раз и приделал бы PosgreSQL, но это сейчас даже очень не критично. И только для поддержки множества серверов сразу. А как вы планируете использовать такую базу данных?
PostgreSQL - провел исследование с зазором на будущее чтобы потому в очередной раз не мигрировать а использовать все доступные ресурсы БД. К тому же интересно изучать что-то новое. Так же БД на слуху часто была. MySQL используют и сами L2J но не хотелось повторятся.

Monga не подошла потому что я перешел к хранению данных в "плоские" таблицы. Без глубокой вложенности. Данные имеют всегда одинаковый размер по количеству ячеек.

Работа с инвентарем из JSON'a с Items
{ ownerId: 1, items: [ { item... } ] }

перешла в хранение многие к одному в табличный вариант.

Использование БД будет похожа на L2J где есть таблицы с персонажами, пользователями и прочим.
 
Как по мне MySQL чуть попроще, чем PostgreSQL, в плане создания архитектуры таблиц и настройки их связей, индексов, комментариев полей и прочего (почти всё можно указать в рамках создания таблицы), ещё MySQL можно создать поле updated_at и задать ему правило обновления при обновлении строк в запросе создания таблицы, а в Postgresql надо создавать триггер для этих целей и вешать на таблицу.

С другой стороны в PostgreSQL есть RETURNING полей (иногда удобно этим пользоваться особенно, когда есть поля с значениями DEFAULT), более продвинутые оконные функции и JSONB (если он нужен). По производительности в простых запросах они примерно одинаковые (как-то смотрел доклад с highload или конфу по Golang на сравнение производительности этих двух БД), в целом всё упирается в диск.

В идеале вообще не надо привязываться к БД, использовать ORM или писать свои Repository, а в бизнес логике использовать Interface'ы репозиториев, то есть в бизнес логику передавать реализованный Repository. Таким образом можно подложить Repository с любым реализованным типом БД: SQLite, MySQL, PostgreSQL или даже MongoDB, единственно надо учитывать возможности транзакций в различным БД и уровней ACID в целом, если это используется в проекте
 
Как по мне MySQL чуть попроще, чем PostgreSQL, в плане создания архитектуры таблиц и настройки их связей, индексов, комментариев полей и прочего (почти всё можно указать в рамках создания таблицы), ещё MySQL можно создать поле updated_at и задать ему правило обновления при обновлении строк в запросе создания таблицы, а в Postgresql надо создавать триггер для этих целей и вешать на таблицу.

С другой стороны в PostgreSQL есть RETURNING полей (иногда удобно этим пользоваться особенно, когда есть поля с значениями DEFAULT), более продвинутые оконные функции и JSONB (если он нужен). По производительности в простых запросах они примерно одинаковые (как-то смотрел доклад с highload или конфу по Golang на сравнение производительности этих двух БД), в целом всё упирается в диск.

В идеале вообще не надо привязываться к БД, использовать ORM или писать свои Repository, а в бизнес логике использовать Interface'ы репозиториев, то есть в бизнес логику передавать реализованный Repository. Таким образом можно подложить Repository с любым реализованным типом БД: SQLite, MySQL, PostgreSQL или даже MongoDB, единственно надо учитывать возможности транзакций в различным БД и уровней ACID в целом, если это используется в проекте
Это все хорошо но на все надо время. Все же проект любительский и как хобби.

Кстати оформил нулевой релиз (версия 0.0.0) под Windows (тестирую автоматическую сборку с заливкой на хранилище)
Загрузить файлы и небольшой гайд тут
Нода для запуска не нужна. Exe'шники запакованы в 1 исполняемый файл, внутри которого есть нода.
 
space2pacman, согласен, такой подход требует дополнительной работы, а следовательно и времени, которого зачастую не так много как хотелось бы :)
Вы молодец, что продолжаете разрабатывать этот проект
 
В идеале вообще не надо привязываться к БД, использовать ORM или писать свои Repository, а в бизнес логике использовать Interface'ы репозиториев, то есть в бизнес логику передавать реализованный Repository. Таким образом можно подложить Repository с любым реализованным типом БД: SQLite, MySQL, PostgreSQL или даже MongoDB, единственно надо учитывать возможности транзакций в различным БД и уровней ACID в целом, если это используется в проекте
ORM проблематична. С одной стороны у вас все работает, а с другой стороны вы не контролируете что ORM делает и какие ресурсы потребляет. Ну и библиотеки соединения с различными БД нужно добавлять в сборку и всетаки как-то это переключать/выбирать при запуске сервера. Да, отвязка от логики нужна, но это все можно сделать по простому, немного кустарным способом. Зато все запросы видны и как вы уже рассказали трансакции очень важны, особенно при обновлений многих данных за один запрос.

Кстати, SQLite тоже поддерживает JSON функции. Это конечно не JSONB как в Postgres , но работает почти также. Они обе достаточно похожи, так что код SQL можно переносить между ними достаточно легко (я не говорю о специфических ситуациях где Posgres уж очень использует продвинутые функции).

Как по мне MySQL чуть попроще, чем PostgreSQL, в плане создания архитектуры таблиц и настройки их связей, индексов, комментариев полей и прочего (почти всё можно указать в рамках создания таблицы), ещё MySQL можно создать поле updated_at и задать ему правило обновления при обновлении строк в запросе создания таблицы, а в Postgresql надо создавать триггер для этих целей и вешать на таблицу.
А какая разница в использовании после создания таблиц?
 
Это все хорошо но на все надо время. Все же проект любительский и как хобби.

Кстати оформил нулевой релиз (версия 0.0.0) под Windows (тестирую автоматическую сборку с заливкой на хранилище)
Загрузить файлы и небольшой гайд тут
Нода для запуска не нужна. Exe'шники запакованы в 1 исполняемый файл, внутри которого есть нода.
Как вы будете решать проблему датапака и изменения конфигурации? Я так понимаю что все эти файлы не будут содержаться в ехе-шнике. И как насчет такого подхода на различных видах линуксов?
 
Как вы будете решать проблему датапака и изменения конфигурации? Я так понимаю что все эти файлы не будут содержаться в ехе-шнике. И как насчет такого подхода на различных видах линуксов?
Датапак и конфиг будет конечно же отдельно. Так же будут билды под linux. Поэтому и номер версии даже не 0.0.1 а 0.0.0))
 
Назад
Сверху