@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());
}
}
}
}
Это понятно, про кеширование данных чара, его схемы, комиссионку на период нахождения чара в игре - вопросов 0. Тут полное согласие и солидарность.Учитывая что зачастую 99% "админов" серверов запускают их на дохленьких впсках, у которых ресурсов кот наплакал, такие оптимизации вполне разумны. Все что можно закэшировать для ускорения работы - стоит кэшировать.
А то зачастую смотришь в код какой нибудь сборки и прямо кровь из глаз - на каждый чих лезет в базу с запросами там, где можно раз прочесть и потом уже это хранить и отдавать из памяти...
З.Ы. Помнится я комиссионку в той сборке, что взял за основу после хф, переделывал - там тоже был положен большой и толстый на кэширование - каждое обращение, каждого игрока, к выставленным на продажу предметам - новый запрос в бд...
З.З.Ы. Еще таким часто страдают писатели бафферов и всего такого - зачастую тоже персональные схемы баффов и т.п. каждый раз пересчитываются из бд при обращении к бафферу
С тем же Ehcache не придется крутить какие-то доп. таски для чистки кэша - у него есть изначально настройки на то же время жизни объектов в нем, на максимальное количество объектов в кэше (при переполнении будет выкидывать самые старые/малоиспользуемые объекты) и т.д.А в случаи с кэшом, то можно скажем не удалять объект персонажа после выхода, а сохранять в список, где работает таск каждый час и удаляет из списка объект персонажа, если он там больше часа находится, тогда при входе заходе, совсем с бд не чего не будет загружаться, если второй раз входишь ))))
Так посмотри в том же овере IDFactory сделан. К чему создавать велосипеды?
Ну и такие идентификаторы для игровых всех объектов, которые используют оные, создаются разово при создании объекта и все, а не выделяется новый идентификатор каждый раз когда к примеру объект грузится из бд снова. Ибо в клиенте, да и в сервере куча всего работает именно базируясь на том что эти идентификаторы являются неизменными для конкретных объектов, а не меняются со временем.
Такие идентификаторы используются как минимум для предметов, персонажей, кланов, всех видов нпс (мобы, мирные, петы, суммоны и т.д.)
Овечаю что-бы немного расширить эту тему.есть так сказать UID у большинства объектов в игре, так сказать уникальный идентификатор, по которому и обращаются к конкретному предмету, игроку, нпс и т.д.
т.е. не может быть к примеру двух отдельных предметов с одним и тем же UID, или двух игроков с одним UID.
в птс идут отдельные пулы этих UID для игроков, для предметов. т.е. к примеру может быть игрок и предмет с одинаковыми UID.
в яве же для удобства и упрощения для всего и вся используется один пул значений UID, генерируемый как раз такими вещами как например IDFactory в овере.
З.Ы. для стакуемых предметов вся стопка имеет один UID. ну и при выделении части ее в отдельную стопку просто создается новый объект предмета с новым UID.
Все переписал, все работает как часы ))) Но сначала разобрался с самой механикой вот этих ID ))) Так теперь вопрос такой, когда иконку с панели пытаюсь перетащить на другой слот, она пропадает, после перезагрузки она снова на том же месте, то есть не меняет слот, я так понимаю должен приходить пакет на сервер от клиента?
Ну... в целом с этим особо проблем нет - при желании можно делать и прицеплять индивидуальные ИИ под каждого суммона или пета без особых затруднений, главное желательно делать их наследными от общего базового ИИ суммонов, чтобы не приходилось дублировать кучу базового кода управляющего их поведением.После чего, окончательно сломалась возможность прикручивать оригинальные Ии к Summon
А что за пакет на перемещение? я потестил, мне что-то приходит на сервер в момент перемещения, но длина пакета меньше фактического пакета. У меня есть только 2 пакета, на добавление и на удаление, и тот и тот хорошо работают. Проблема только с перемещением
Ну я так и говорю. Все больше и больше костылей. Там просто очень большой контролирующий класс ИИ НПЦ, который управляет общим поведением НПЦ, включая петов и суммонов. И чем более глубоко будет реализация ИИ, тем больше косяков будет вылезать и дублирующего кода, пока не придет понимание, что это должен быть один класс, а не два)Ну... в целом с этим особо проблем нет - при желании можно делать и прицеплять индивидуальные ИИ под каждого суммона или пета без особых затруднений, главное желательно делать их наследными от общего базового ИИ суммонов, чтобы не приходилось дублировать кучу базового кода управляющего их поведением.
Просто в большинстве сборок явно захардено что типа если создается/спавнится объект суммон или пет - автоматом создается дефолтное ИИ, например SummonAI. Но ничего не мешает считывать например из данных нпс являющегося темплейтом суммона/пета, какое же реально ИИ выставлено в этом темплейте и именно это ИИ назначить.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?