Помогите с пакетом ShortCutInit

[nesss]

Хроники

1. Interlude

Исходники

Присутствуют

Сборка

Собственная

Всем привет, начал реализацию панели быстрого доступа, проблема вот в чем, при добавлении на панель действия, все хорошо работает, при добавлении предмета, все хорошо, потом делаю рестарт все отображается хорошо, потом еще раз делаю рестарт и предметы пропадают с панели, а действия все четко отображаются, в списке на сервере предметы есть, клиенту они отправляются без проблем, если на слот, на котором должен быть предмет, добавить новый предмет, предмет не добавляется, как будь-то слот занят.

Использую пакет вот так:

    @Override
    public void write() {

        final ShortCut shortCut = clientSocket.getAccount().getCharacter().getShortCut();
        final List<ShortCutTemplate> iconsActive = new ArrayList<>();

        for (ShortCutTemplate shortCutTemplate : shortCut.getIcons()) {

            if (shortCutTemplate.isActive()) iconsActive.add(shortCutTemplate);

        }

        writeByte(0x45);
        writeInt(iconsActive.size());

        for (ShortCutTemplate shortCutTemplate : iconsActive) {

            writeInt(shortCutTemplate.getType().getNumber());
            writeInt(shortCutTemplate.getSlot() + shortCutTemplate.getPage() * 12);

            switch (shortCutTemplate.getType()) {

                case ITEM -> {

                    writeInt(shortCutTemplate.getIdObject());
                    writeInt(shortCutTemplate.getCharacterType());
                    writeInt(-1);
                    writeInt(0x00);
                    writeInt(0x00);
                    writeInt(0x00);

                }
                case SKILL -> {

                    writeInt(shortCutTemplate.getIdObject());
                    writeInt(shortCutTemplate.getLevel());
                    writeInt(0x00);
                    writeInt(shortCutTemplate.getCharacterType());

                }
                default -> {

                    writeInt(shortCutTemplate.getIdObject());
                    writeInt(shortCutTemplate.getCharacterType());

                }

            }

        }

    }

 

[Aristo]

Учитывая что зачастую 99% "админов" серверов запускают их на дохленьких впсках, у которых ресурсов кот наплакал, такие оптимизации вполне разумны. Все что можно закэшировать для ускорения работы - стоит кэшировать.
А то зачастую смотришь в код какой нибудь сборки и прямо кровь из глаз - на каждый чих лезет в базу с запросами там, где можно раз прочесть и потом уже это хранить и отдавать из памяти...

З.Ы. Помнится я комиссионку в той сборке, что взял за основу после хф, переделывал - там тоже был положен большой и толстый на кэширование - каждое обращение, каждого игрока, к выставленным на продажу предметам - новый запрос в бд...
З.З.Ы. Еще таким часто страдают писатели бафферов и всего такого - зачастую тоже персональные схемы баффов и т.п. каждый раз пересчитываются из бд при обращении к бафферу

Это понятно, про кеширование данных чара, его схемы, комиссионку на период нахождения чара в игре - вопросов 0. Тут полное согласие и солидарность.
Я просто очень скептически отношусь к идее оставить твердые ссылки на какие-либо объекты, связанные с конкретным персонажем вне границ его времени онлайн(типа кеширования предметов при релоге). Вышел чар - GC все покрошил: чара, сабы, инвентарь с его итемами, эффекты, связанные объекты.

 

[nesss]

Ну вроде разобрался в чем проблема, проблема с идентификатором объекта в игровом мире. Я реализовал так, что при загрузке с БД к примеру предмета, ему присваивался новый идентификатор. Тут я сам немного не разобрался тогда с идентификаторами, и получается в клиент загружался итем скажем с id 100 при первом входе, после релога, в клиенте оказывается остается данный идентификатор до момента его удаления из клиента, скажем если я поломаю предмет, то он удалиться из клиента. При входе второй раз id изменялся на предмет и он его попросту не видел, а вот умения и действия оставались, так как идентификатор их зашиты в клиенте и они статичны. Как то так, сейчас переписываю систему идентификаторов объектов в мире. Посмотрел аналог, там сделано так:

То есть создается BitSet(100 000);

и AtomicInteger(0x7FFFFFFF - 0x10000000);

Потом выполняется выборка из БД всех объектов: персонажи, предметы // Да вот тут вопрос сразу, что считается объектом в игре? просто тут в примере даже ID клана записывают как объект.

Если есть ваша интересная реализация присвоения и хранения идентификатора объекту прошу поделиться ))) Копировать не буду, может что-то подчеркну себе для развития )

Ну скажем если есть страх, что игрок будет входить, заходить и делать нагрузку на серв, тем что будет с БД много доставать, можно сделать ограничение входа скажем не чаще 1 или 5 минут. А в случаи с кэшом, то можно скажем не удалять объект персонажа после выхода, а сохранять в список, где работает таск каждый час и удаляет из списка объект персонажа, если он там больше часа находится, тогда при входе заходе, совсем с бд не чего не будет загружаться, если второй раз входишь ))))

 

[Gaikotsu]

Так посмотри в том же овере IDFactory сделан. К чему создавать велосипеды?
Ну и такие идентификаторы для игровых всех объектов, которые используют оные, создаются разово при создании объекта и все, а не выделяется новый идентификатор каждый раз когда к примеру объект грузится из бд снова. Ибо в клиенте, да и в сервере куча всего работает именно базируясь на том что эти идентификаторы являются неизменными для конкретных объектов, а не меняются со временем.

Такие идентификаторы используются как минимум для предметов, персонажей, кланов, всех видов нпс (мобы, мирные, петы, суммоны и т.д.)

А в случаи с кэшом, то можно скажем не удалять объект персонажа после выхода, а сохранять в список, где работает таск каждый час и удаляет из списка объект персонажа, если он там больше часа находится, тогда при входе заходе, совсем с бд не чего не будет загружаться, если второй раз входишь ))))

С тем же Ehcache не придется крутить какие-то доп. таски для чистки кэша - у него есть изначально настройки на то же время жизни объектов в нем, на максимальное количество объектов в кэше (при переполнении будет выкидывать самые старые/малоиспользуемые объекты) и т.д.

 

[BladeRunner]

Так посмотри в том же овере IDFactory сделан. К чему создавать велосипеды?
Ну и такие идентификаторы для игровых всех объектов, которые используют оные, создаются разово при создании объекта и все, а не выделяется новый идентификатор каждый раз когда к примеру объект грузится из бд снова. Ибо в клиенте, да и в сервере куча всего работает именно базируясь на том что эти идентификаторы являются неизменными для конкретных объектов, а не меняются со временем.

Такие идентификаторы используются как минимум для предметов, персонажей, кланов, всех видов нпс (мобы, мирные, петы, суммоны и т.д.)

я правильно понял, что есть ID стандартный предмета в базе, определяющий его тип, и есть ID производственный каждого предмета этого типа? кроме , я так понимаю, стаковых вещей?

 

[Gaikotsu]

есть так сказать UID у большинства объектов в игре, так сказать уникальный идентификатор, по которому и обращаются к конкретному предмету, игроку, нпс и т.д.
т.е. не может быть к примеру двух отдельных предметов с одним и тем же UID, или двух игроков с одним UID.
в птс идут отдельные пулы этих UID для игроков, для предметов. т.е. к примеру может быть игрок и предмет с одинаковыми UID.
в яве же для удобства и упрощения для всего и вся используется один пул значений UID, генерируемый как раз такими вещами как например IDFactory в овере.

З.Ы. для стакуемых предметов вся стопка имеет один UID. ну и при выделении части ее в отдельную стопку просто создается новый объект предмета с новым UID.

 

[MrThirtyOddSix]

есть так сказать UID у большинства объектов в игре, так сказать уникальный идентификатор, по которому и обращаются к конкретному предмету, игроку, нпс и т.д.
т.е. не может быть к примеру двух отдельных предметов с одним и тем же UID, или двух игроков с одним UID.
в птс идут отдельные пулы этих UID для игроков, для предметов. т.е. к примеру может быть игрок и предмет с одинаковыми UID.
в яве же для удобства и упрощения для всего и вся используется один пул значений UID, генерируемый как раз такими вещами как например IDFactory в овере.

З.Ы. для стакуемых предметов вся стопка имеет один UID. ну и при выделении части ее в отдельную стопку просто создается новый объект предмета с новым UID.

Овечаю что-бы немного расширить эту тему.
UID нужен клиенту что-бы представить своеобразный реестр по окотому он может обновлять или же присвоивать предметы к игрокам, или обновлять NPC/игроков. Например когда предмет находится в инвентаре, то UID будет видно только игроку. А если лежит на землe где-то, то будет известен всем игрокам в определенном растоянии от него. UID в этом случае должен быть глобальным.
А вот например NPC, у него тоже будет UID. После его смерти, он может поменяться, а может и остаться прежним. Также можно например использовать те же самые UID для NPC в instance dungeon (копии инстансов, так как только одна парти будет в них находиться ) . Или же использовать одни и те же UID (не одно значение, но одинаковые значения при перезагрузке сервера), при создании всех NPC.

Для shortcut-ов, создание UID не имеет смысла. Так как все они сохраняются в БД по UID от игрока и для клиента используются значения от slot и page.

 

[nesss]

Все переписал, все работает как часы ))) Но сначала разобрался с самой механикой вот этих ID ))) Так теперь вопрос такой, когда иконку с панели пытаюсь перетащить на другой слот, она пропадает, после перезагрузки она снова на том же месте, то есть не меняет слот, я так понимаю должен приходить пакет на сервер от клиента?

 

[Gaikotsu]

Естесно, от клиента приходят пакеты на удаление/перемещение/добавление шорткатов и в ответ надо слать пакеты с результатами этих действий.

 

[nesss]

А что за пакет на перемещение? я потестил, мне что-то приходит на сервер в момент перемещения, но длина пакета меньше фактического пакета. У меня есть только 2 пакета, на добавление и на удаление, и тот и тот хорошо работают. Проблема только с перемещением

 

[Aristo]

Все переписал, все работает как часы ))) Но сначала разобрался с самой механикой вот этих ID ))) Так теперь вопрос такой, когда иконку с панели пытаюсь перетащить на другой слот, она пропадает, после перезагрузки она снова на том же месте, то есть не меняет слот, я так понимаю должен приходить пакет на сервер от клиента?

Спойлер: Офтоп

Если переписывать логику фундаментальных механизмов, и делать ее отличной от той логики, которая используется в ПТС, то чем глубже ты будешь пилить, тем больше тебе будет встречаться мест в коде, которые требуют ИМЕННО такое поведение, как заложили корейцы, и тем больше тебе придется делать костылей, что это компенсировать. Ты идешь тем же путем, что и L2j в свое время, когда вместо копирования логики слитого ПТС, они из-за копирайтных ограничений начали маскировать какие-то элементы костылями, а в каких-то моментах, из-за недостатка информации, были допущены ошибки в проектировании структуры, и для компенсации которых, были добавлены умопомрачительное количество костылей.
Яркий пример: наличие класса Playable, который вместо свойства объекта Creature, стал полноценным классом, от которого разветвились Player и Summon, а когда выяснилось, что Summon и Pet это просто Npc, было уже поздно и теперь в лыже есть почти два одинаковых класса, Summon и Npc. После чего, окончательно сломалась возможность прикручивать оригинальные Ии к Summon, использовать instanceof Npc и еще овердохера костылей в скиллах, зонах, проверках и прочем, где дублируется код проверок для Npс и Servitor

 

[Gaikotsu]

После чего, окончательно сломалась возможность прикручивать оригинальные Ии к Summon

Ну... в целом с этим особо проблем нет - при желании можно делать и прицеплять индивидуальные ИИ под каждого суммона или пета без особых затруднений, главное желательно делать их наследными от общего базового ИИ суммонов, чтобы не приходилось дублировать кучу базового кода управляющего их поведением.
Просто в большинстве сборок явно захардено что типа если создается/спавнится объект суммон или пет - автоматом создается дефолтное ИИ, например SummonAI. Но ничего не мешает считывать например из данных нпс являющегося темплейтом суммона/пета, какое же реально ИИ выставлено в этом темплейте и именно это ИИ назначить.

А что за пакет на перемещение? я потестил, мне что-то приходит на сервер в момент перемещения, но длина пакета меньше фактического пакета. У меня есть только 2 пакета, на добавление и на удаление, и тот и тот хорошо работают. Проблема только с перемещением

Спойлер: перемещение из слота в слот

 

[Aristo]

Ну... в целом с этим особо проблем нет - при желании можно делать и прицеплять индивидуальные ИИ под каждого суммона или пета без особых затруднений, главное желательно делать их наследными от общего базового ИИ суммонов, чтобы не приходилось дублировать кучу базового кода управляющего их поведением.
Просто в большинстве сборок явно захардено что типа если создается/спавнится объект суммон или пет - автоматом создается дефолтное ИИ, например SummonAI. Но ничего не мешает считывать например из данных нпс являющегося темплейтом суммона/пета, какое же реально ИИ выставлено в этом темплейте и именно это ИИ назначить.

Ну я так и говорю. Все больше и больше костылей. Там просто очень большой контролирующий класс ИИ НПЦ, который управляет общим поведением НПЦ, включая петов и суммонов. И чем более глубоко будет реализация ИИ, тем больше косяков будет вылезать и дублирующего кода, пока не придет понимание, что это должен быть один класс, а не два)

 

[nesss]

Все )) заработало, короче там размер байтов пакета от клиента приходит один, а сам пакет больше, а у меня проверка стояла, если размер пакета равен содержимому пакета, поставил меньше равно и все заработало )