Рейтинг темы:
  • 2 Голос(ов) - 5 в среднем
  • 1
  • 2
  • 3
  • 4
  • 5
Работа над Goddess of Destruction (part 6)
косяк тут нашел на 531 протоколе в системе заточки - клиент зачем-то помнит uid последнего камня, увеличивающего шанс заточки и продолжает его слать в пакете RequestEnchantItem, даже если точится уже вообще другая вещь и т.д. и с вполне предсказуемым результатом камешки, если их было несколько в стопке, внезапно начинают автоматически тратиться при заточке на +4 и выше, если новая точимая вещица так же для камня подходит. притом естественно поле для камня в диалоге заточки остается пустым, создавая ложное представление о том что камень не задействован.
притом избавится от этих данных можно только полностью перезапустив клиент - простой перезаход в в игру не помогает - клиет все так же упорно шлет uid последнего использованного камня на все попытки заточки вещей.

кто в курсе - в дальнейших хрониках то этот косяк починили или все еще имеется?
ну или может какой новый пакет ввели, очищающий данную информацию в клиенте? а то в 531 то данные об этом со стороны серва вроде никак не обнулить.
Сталкивался ли кто с данной проблемой,

[Изображение: 06f3689ec88f93acc960311b0f498fe6.png]

Данная ошибка возникает когда надеваю предмет в уже занятый слот, а если слот освободить то все в норме...

П.С. пакет InventoryUpdate в норме, проверил на офф. снифах.
Mifesto Написал:Сталкивался ли кто с данной проблемой,

[Изображение: 06f3689ec88f93acc960311b0f498fe6.png]

Данная ошибка возникает когда надеваю предмет в уже занятый слот, а если слот освободить то все в норме...

П.С. пакет InventoryUpdate в норме, проверил на офф. снифах.

InventoryUpd
Код:
@Override
    protected final void writeImpl()
    {
        writeC(0x21);
        writeItems();
    }

    @Override
    public void runImpl()
    {
        getClient().sendPacket(new ItemList(getClient().getActiveChar(), false));
        getClient().sendPacket(new ExUserInfoInventWeight(getClient().getActiveChar()));
    }
writeItems()
Код:
protected final void writeItems()
    {
        writeH(_items.size());
        for (ItemInfo item : _items.values())
        {
            writeH(item.getChange());
            writeItem(item);
        }
    }
writeItem(item)
Код:
protected void writeItem(TradeItem item)
    {
        writeItem(new ItemInfo(item));
    }

    protected void writeItem(L2ItemInstance item)
    {
        writeItem(new ItemInfo(item));
    }

    protected void writeItem(ItemInfo item)
    {
        int check_Augmentation = 0;
        check_ElementType = 0;
        check_EnchantOption = 0;
        if (item.getAugmentationBonus() > 0)
        {
            check_Augmentation = 1;
        }
        if (item.getAttackElementPower() > 0)
        {
            check_ElementType = 2;
        }
        else
        {
            for (byte i = 0; i < 6; i++)
            {
                if (item.getElementDefAttr(i) > 0)
                {
                    check_ElementType = 2;
                }
            }
        }
        for (int op : item.getEnchantOptions())
        {
            if (op > 0)
            {
                check_EnchantOption = 4;
            }
        }
        writeC(check_Augmentation + check_ElementType + check_EnchantOption + 0);
        writeD(item.getObjectId());
        writeD(item.getItem().getDisplayId());
        writeC((int) item.getLocation());
        writeQ(item.getCount());
        writeC(item.getItem().getType2());
        writeC(item.getCustomType1());
        writeH(item.getEquipped());
        writeQ(item.getItem().getBodyPart());
        writeC(item.getEnchant());
        writeC(item.getCustomType2());
        writeD(item.getMana());
        writeD(item.getTime());
        writeC(0x01);
        if (check_Augmentation > 0)
        {
            writeD(item.getAugmentationBonus());
        }
        writeItemElementalAndEnchant(item);
    }

    protected void writeItemElementalAndEnchant(ItemInfo item)
    {
        if (check_ElementType > 0)
        {
            writeH(item.getAttackElementType());
            writeH(item.getAttackElementPower());
            for (byte i = 0; i < 6; i++)
            {
                writeH(item.getElementDefAttr(i));
            }
        }

        if (check_EnchantOption > 0)
        {
            for (int op : item.getEnchantOptions())
            {
                writeH(op);
            }
        }
    }

    protected void writeInventoryBlock(PcInventory inventory)
    {
        if (inventory.hasInventoryBlock())
        {
            writeH(inventory.getBlockItems().length);
            writeC(inventory.getBlockMode());
            for (int i : inventory.getBlockItems())
            {
                writeD(i);
            }
        }
        else
        {
            writeH(0x00);
        }
    }
вроде нашел проблему.
Gaikotsu Написал:косяк тут нашел на 531 протоколе в системе заточки - клиент зачем-то помнит uid последнего камня, увеличивающего шанс заточки и продолжает его слать в пакете RequestEnchantItem, даже если точится уже вообще другая вещь и т.д. и с вполне предсказуемым результатом камешки, если их было несколько в стопке, внезапно начинают автоматически тратиться при заточке на +4 и выше, если новая точимая вещица так же для камня подходит. притом естественно поле для камня в диалоге заточки остается пустым, создавая ложное представление о том что камень не задействован.
притом избавится от этих данных можно только полностью перезапустив клиент - простой перезаход в в игру не помогает - клиет все так же упорно шлет uid последнего использованного камня на все попытки заточки вещей.

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

На версии игры выше- баг убирается, там оно как триггер реализовано.
Отсылается ExRemoveEnchantSupportItemResult
тупизм, целый пакет на это выделять.
не логичней было бы банально обнулять переменную при закрытии диалога заточки...
Вычитал в теме, что клоны ножей и приманка - это нпс. Окей. Воткнул в пакет NpcInfo еще пару вариантов:
//Блок клонов ножей
public NpcInfo(CloneObject clone)
{
_npcId = clone.getTemplate().npcId;
_name = clone.getPlayer().getName();
_title = clone.getPlayer().getTitle();
_cloneOwnerId = clone.getPlayer().getObjectId();
_showName = true;
_HP = (int) clone.getCurrentHp();
_maxHP = clone.getMaxHp();
_isClone = 0x02;
common(clone);
}

//Блок приманок
public NpcInfo(DecoyInstance decoy)
{
_npcId = decoy.getTemplate().npcId;
_name = decoy.getPlayer().getName();
_title = decoy.getPlayer().getTitle();
_cloneOwnerId = decoy.getPlayer().getObjectId();
_showName = decoy.isShowName();
_isAttackable = true;
_HP = (int) decoy.getCurrentHp();
_maxHP = decoy.getMaxHp();
_isClone = 0x01;
common(decoy);
}

В классах DecoyInstance, CloneInstance и в главном классе-объекте CloneObject заменил отсылку CharInfo на NpcInfo с соотв. вариациями, которые выше.
Один из примеров:
@Override
public List<L2GameServerPacket> addPacketList(Player forPlayer, Creature dropper)
{
if (!isInCombat())
return Collections.<L2GameServerPacket> singletonList(new NpcInfo(this));
else
{
List<L2GameServerPacket> list = new ArrayList<L2GameServerPacket>(2);
list.add(new NpcInfo(this));
list.add(new AutoAttackStart(objectId));
return list;
}
}


В итоге, игрок-хозяин видит клонов на отлично, а другие видят кроликов вместо копий героя.
Сначала думал, что что-то в пакете не так, думал, что не отправляется objectId призывателя, но ошибся. Если не отправлять этот objectId, то у хозяина тупо не будет видно тела клонов. Мудохался два вечера, теперь их вовсе не видят другие игроки.
Подскажите, что я делаю не так?
UPD: Ах, да, приманка отображается нормально, проблема только с клонами.
Декой - это нпц, ток у него пакеты CharInfo, а не NpcInfo
consulo.io - Consulo - multi-language IDE
VISTALL Написал:Декой - это нпц, ток у него пакеты CharInfo, а не NpcInfo
Не соглашусь. В пакете NpcInfo есть тип призываемого Npc. 1 - decoy, 2 - клон ножа. К тому же на офе, если выделить decoy в таргет, то там будет показываться хп, в CharInfo не передаются данные о хп. Но, как я уже написал, с decoy в этом плане у меня все отлично, а клоны "морозятся".
Картинка
Или стоп: может NpcInfo должен отправляться только для призывателя, а для остальных CharInfo?
хм, я обхожусь одним NpcInfo, просто в нем еще дополнительно шлется инфа о том, с какого объекта поблизости брать внешность и т.д. - с хозяина клона т.е.
это d следущее сразу за полем с флагом режима полета (isFlying)

притом для самого владельца клонов, клоны будут черно-белые (видимо чтобы хозяин сам себя среди клонов не потерял), а для других игроков от владельца никак отличаться не будут.


Возможно похожие темы ...
Тема Автор Ответы Просмотры Последний пост
  Работа над Goddess of Destruction (part 7) n3k0nation 459 174,297 03-21-2022, 04:21 PM
Последний пост: TieLay
  Помогите с Сервером L2Dream версии 439 для Lineage 2 Gracia Part 2 CAHTEX 4 3,380 10-01-2021, 02:40 PM
Последний пост: tenor
  Работа с камерой и Энтер чат FriendlyGhost 0 1,302 04-29-2018, 06:07 AM
Последний пост: FriendlyGhost
  Goddess of Destruction ( новая ветка от NcSoft ) Bacek 180 59,012 08-22-2017, 12:32 PM
Последний пост: BadStealth
  EmuRT Gracia part 2 ? knaif 3 1,622 02-08-2016, 01:19 PM
Последний пост: knaif
  Gracia Part 1 от l2emu исходы TFH 6 1,964 10-05-2015, 07:53 PM
Последний пост: G1ta0
  Ищу исходы L2-Dream gracia part 2 knaif 1 1,385 10-05-2015, 07:51 PM
Последний пост: G1ta0
  Оплачиваемая работа Grek1993 1 1,349 08-01-2015, 11:29 AM
Последний пост: ztaecz
  Работа с мультиселлом Evencelance 11 2,446 09-19-2014, 12:43 PM
Последний пост: Evencelance
  Работа над Goddess of Destruction (part 5) Ozzy 980 339,178 10-09-2013, 09:13 AM
Последний пост: Ashe

Перейти к форуму:


Пользователи, просматривающие эту тему: 18 Гость(ей)