Сообщений: 1,065
Тем: 20
Зарегистрирован: Mar 2010
Репутация:
3,855
косяк тут нашел на 531 протоколе в системе заточки - клиент зачем-то помнит uid последнего камня, увеличивающего шанс заточки и продолжает его слать в пакете RequestEnchantItem, даже если точится уже вообще другая вещь и т.д. и с вполне предсказуемым результатом камешки, если их было несколько в стопке, внезапно начинают автоматически тратиться при заточке на +4 и выше, если новая точимая вещица так же для камня подходит. притом естественно поле для камня в диалоге заточки остается пустым, создавая ложное представление о том что камень не задействован.
притом избавится от этих данных можно только полностью перезапустив клиент - простой перезаход в в игру не помогает - клиет все так же упорно шлет uid последнего использованного камня на все попытки заточки вещей.
кто в курсе - в дальнейших хрониках то этот косяк починили или все еще имеется?
ну или может какой новый пакет ввели, очищающий данную информацию в клиенте? а то в 531 то данные об этом со стороны серва вроде никак не обнулить.
Сообщений: 527
Тем: 17
Зарегистрирован: Oct 2010
Репутация:
1,919
Сталкивался ли кто с данной проблемой,
Данная ошибка возникает когда надеваю предмет в уже занятый слот, а если слот освободить то все в норме...
П.С. пакет InventoryUpdate в норме, проверил на офф. снифах.
Сообщений: 106
Тем: 3
Зарегистрирован: Jun 2014
Mifesto Написал:Сталкивался ли кто с данной проблемой,
Данная ошибка возникает когда надеваю предмет в уже занятый слот, а если слот освободить то все в норме...
П.С. пакет 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);
}
}
Сообщений: 527
Тем: 17
Зарегистрирован: Oct 2010
Репутация:
1,919
Сообщений: 199
Тем: 0
Зарегистрирован: Jul 2013
Репутация:
348
Gaikotsu Написал:косяк тут нашел на 531 протоколе в системе заточки - клиент зачем-то помнит uid последнего камня, увеличивающего шанс заточки и продолжает его слать в пакете RequestEnchantItem, даже если точится уже вообще другая вещь и т.д. и с вполне предсказуемым результатом камешки, если их было несколько в стопке, внезапно начинают автоматически тратиться при заточке на +4 и выше, если новая точимая вещица так же для камня подходит. притом естественно поле для камня в диалоге заточки остается пустым, создавая ложное представление о том что камень не задействован.
притом избавится от этих данных можно только полностью перезапустив клиент - простой перезаход в в игру не помогает - клиет все так же упорно шлет uid последнего использованного камня на все попытки заточки вещей.
кто в курсе - в дальнейших хрониках то этот косяк починили или все еще имеется?
ну или может какой новый пакет ввели, очищающий данную информацию в клиенте? а то в 531 то данные об этом со стороны серва вроде никак не обнулить.
На версии игры выше- баг убирается, там оно как триггер реализовано.
Отсылается ExRemoveEnchantSupportItemResult
Сообщений: 1,065
Тем: 20
Зарегистрирован: Mar 2010
Репутация:
3,855
тупизм, целый пакет на это выделять.
не логичней было бы банально обнулять переменную при закрытии диалога заточки...
Сообщений: 441
Тем: 15
Зарегистрирован: Oct 2012
Репутация:
3,319
Вычитал в теме, что клоны ножей и приманка - это нпс. Окей. Воткнул в пакет 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: Ах, да, приманка отображается нормально, проблема только с клонами.
Сообщений: 1,912
Тем: 56
Зарегистрирован: Jan 2009
Репутация:
12,921
Декой - это нпц, ток у него пакеты CharInfo, а не NpcInfo
Сообщений: 441
Тем: 15
Зарегистрирован: Oct 2012
Репутация:
3,319
09-13-2014, 11:17 AM
(Сообщение последний раз редактировалось: 09-13-2014, 11:20 AM elastic.)
VISTALL Написал:Декой - это нпц, ток у него пакеты CharInfo, а не NpcInfo Не соглашусь. В пакете NpcInfo есть тип призываемого Npc. 1 - decoy, 2 - клон ножа. К тому же на офе, если выделить decoy в таргет, то там будет показываться хп, в CharInfo не передаются данные о хп. Но, как я уже написал, с decoy в этом плане у меня все отлично, а клоны "морозятся".
Или стоп: может NpcInfo должен отправляться только для призывателя, а для остальных CharInfo?
Сообщений: 1,065
Тем: 20
Зарегистрирован: Mar 2010
Репутация:
3,855
хм, я обхожусь одним NpcInfo, просто в нем еще дополнительно шлется инфа о том, с какого объекта поблизости брать внешность и т.д. - с хозяина клона т.е.
это d следущее сразу за полем с флагом режима полета (isFlying)
притом для самого владельца клонов, клоны будут черно-белые (видимо чтобы хозяин сам себя среди клонов не потерял), а для других игроков от владельца никак отличаться не будут.
|