Добавлен VisibilityManager для управления окружением.
* Показать кто рядом
* Удалить кто уже далеко
* Показать кто рядом
* Удалить кто уже далеко
Написание сервера для lineage 2 chronicle 1 на node.js
- Автор темы space2pacman
- Дата начала
-
- Теги
- javascript node.js
* Стартовали работы по AI. (Обработка bypass, взятия квеста Fighter tutorial)
А он двигается по маршруту(с персонажами на борту) или пока статичен ?Добавил корабльПосмотреть вложение 87186
Статичен. Было интересно как работает пакет Vehicle.
В какой-нибудь версии релиза будет полная реализация корабля)
* Добавил первый квест на карту
* Работа по AI для Carl(Npc человек) и Keltir(Npc волк)
* Переработана архитектура AI (Базовые методы)
* Работа по AI для Carl(Npc человек) и Keltir(Npc волк)
* Переработана архитектура AI (Базовые методы)
Отлично работает )
Ждём технику ( кораблики )
Это в конце)) еще АИ магазинов, телепортов и многое по мелочи))) Магов делать, скилы, формулы
Идея создать 1000 ботов и раздать им скрипты дабы сделать сервер "живой"
Кто-то бегает, кто-то качается а кто-то торгует.
На данном этапе бот умеет фармить мобов и собирать дроп (видео постами раньше)
Кто-то бегает, кто-то качается а кто-то торгует.
На данном этапе бот умеет фармить мобов и собирать дроп (видео постами раньше)
* Добавил заряд души
* Таймер по регенерации HP, HP
* Смерть игрока
* Восстановление игрока после смерти
* Покупку предметов у NPC
* Waypoints для ботов (Кружат вокруг стеллы в талкине)
Техническое обновление
* Миграция с MongoDB => PostgreSQL
Монга была неудобна.
* Таймер по регенерации HP, HP
* Смерть игрока
* Восстановление игрока после смерти
* Покупку предметов у NPC
* Waypoints для ботов (Кружат вокруг стеллы в талкине)
Техническое обновление
* Миграция с MongoDB => PostgreSQL
Монга была неудобна.
А почему 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 в целом, если это используется в проекте
С другой стороны в PostgreSQL есть RETURNING полей (иногда удобно этим пользоваться особенно, когда есть поля с значениями DEFAULT), более продвинутые оконные функции и JSONB (если он нужен). По производительности в простых запросах они примерно одинаковые (как-то смотрел доклад с highload или конфу по Golang на сравнение производительности этих двух БД), в целом всё упирается в диск.
В идеале вообще не надо привязываться к БД, использовать ORM или писать свои Repository, а в бизнес логике использовать Interface'ы репозиториев, то есть в бизнес логику передавать реализованный Repository. Таким образом можно подложить Repository с любым реализованным типом БД: SQLite, MySQL, PostgreSQL или даже MongoDB, единственно надо учитывать возможности транзакций в различным БД и уровней ACID в целом, если это используется в проекте
Это все хорошо но на все надо время. Все же проект любительский и как хобби.
Кстати оформил нулевой релиз (версия 0.0.0) под Windows (тестирую автоматическую сборку с заливкой на хранилище)
Загрузить файлы и небольшой гайд тут
Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация
Нода для запуска не нужна. Exe'шники запакованы в 1 исполняемый файл, внутри которого есть нода.
space2pacman, согласен, такой подход требует дополнительной работы, а следовательно и времени, которого зачастую не так много как хотелось бы
Вы молодец, что продолжаете разрабатывать этот проект
Вы молодец, что продолжаете разрабатывать этот проект
ORM проблематична. С одной стороны у вас все работает, а с другой стороны вы не контролируете что ORM делает и какие ресурсы потребляет. Ну и библиотеки соединения с различными БД нужно добавлять в сборку и всетаки как-то это переключать/выбирать при запуске сервера. Да, отвязка от логики нужна, но это все можно сделать по простому, немного кустарным способом. Зато все запросы видны и как вы уже рассказали трансакции очень важны, особенно при обновлений многих данных за один запрос.
Кстати, SQLite тоже поддерживает JSON функции. Это конечно не JSONB как в Postgres , но работает почти также. Они обе достаточно похожи, так что код SQL можно переносить между ними достаточно легко (я не говорю о специфических ситуациях где Posgres уж очень использует продвинутые функции).
А какая разница в использовании после создания таблиц?
Как вы будете решать проблему датапака и изменения конфигурации? Я так понимаю что все эти файлы не будут содержаться в ехе-шнике. И как насчет такого подхода на различных видах линуксов?
Датапак и конфиг будет конечно же отдельно. Так же будут билды под linux. Поэтому и номер версии даже не 0.0.1 а 0.0.0))