SMSG_LOOT_RESPONSE из 4.0.6а
 

Разобрал структуру этого пакета. Парсит его с оффа нормально, без всяких косяков. Сделал интрепретацию его на сервере, проверяю тем же парсером - никаких проблем. Но в игре при попытке облутать моба ничего не происходит. Я уже все перепробывал. Кто в курсе, в 4.0.6а сменилось ещё что-то кроме него?

Пример с офа:
На локале:
Про энтри на локале ничего не говорите, это особая магия =)))

Первое что приходит в голуву. Может randomSuffix!=0 должно быть??

randomSuffix это ид шаблона, по которому выдаются характеристики вещам, на которых написано <random enchantment>, кажется к делу это не имеет отношения.

Ну да. Первое что пришло в голову, что размер не правильный при формировании пакета выставил. Но потом это отпало, т.к. ядро динамически буфер для пакета расширяет, и данные отправляет корректно.

Самое странное то, что клиент этот пакет переваривать не захотел. Т.к. использовался инжекторный снифер для проверки, и он не хватает те пакеты, которые клиент не захотел кушать. И само собой этого пакета в снифе не было. Но в world.log он был. Не пойму что может быть не так :(

Не на то соединение послали :) (а-ля клиент не пропатчили)

Клиент пропатчен. Остальное то все нормально работает.

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

Скорее всего не в этом дело. Просто энтри парсер получает основываясь на инфе о гуиде, которую он получает из других пакетов, а в парсер я затолкал только 1 этот пакет, поэтому неправильный ентри.

Да и гуид с офа нормально читает. А он там не пакованный.

Похоже alien прав. Изучил этот RandomSuffix, оказалось что RandomSuffix не может быть равен нулю, или RandomProperty. У меня в базе 45к предметов у которых и то и то равно 0. Скорее всего в этом дело. Решил отпарить с офа, и тут возникла такая проблема:
Т.е. для каждого лута, пусть даже и одного итема получается разный RandomSuffix. Отсюда появился вопрос: как он может формироватся на офе? Посмотрел у нас в коде, там он просто берется из базы, без всяких доработок.

Разве это не генерируется случайным образом во время лута?

Точно :) Тогда попробую отпарсить пакет SMSG_ITEM_QUERY_SINGLE_RESPONSE

add: А вот это уже более интерестно :)
Было добыто из SMSG_ITEM_QUERY_SINGLE_RESPONSE. Похоже это то, что нужно :)

чото вы напутали с этими пропертями и суффиксами. вообще говоря проперти это некое ID, которое вроде даже где то в дбц было в виде вариаций. и грубо говоря это ID от нуля до некоего конечного числа, типа 100 или может 1000, не помню.

а те громадные числа я перевел в hex и оно мне TimeStamp больше напоминает. да и откуда вы взяли рандом проперти поле в SMSG_ITEM_QUERY_SINGLE_RESPONSE, его там от родясь никогда не было. это апдейт поле итема:
ITEM_FIELD_RANDOM_PROPERTIES_ID = 59; // 001 - [1] Integer - [001] PUBLIC

вот еще есть поле ITEM_FIELD_PROPERTY_SEED, вот тут более вероятно встретить таймстап, кажется это он и есть (не помню уж). но опять же, это А9, а не SMSG_ITEM_QUERY_SINGLE_RESPONSE.

покажите дамп всего пакета.

но вообще не о том говорим. и да, если апдейт поле цельное (не составные байты или слова), если оно integer и если оно равно нулю, то такое поле не передается в апдейтпакете. это такое правило. нельзя передавать зануленные поля.

я чесно говоря потерял нить проблемы, напомните плиз. клиент не воспринимает SMSG_LOOT_RESPONSE, сформированный вами? судя по вашему разобранному представлению этот пакет не менялся со времен царя гороха. вот у меня что:

Ну не знаю. Я строил обработчик пакета SMSG_ITEM_QUERY_SINGLE_RESPONSE по примеру из Кактуса. Клиент такие пакеты понимал нормально. http://pastebin.com/wDGtdqYH

Правда в парсере я его малость поправил, и получилось такое: http://pastebin.com/rcf5xztf
Вроде как парсит нормально.

По поводу SMSG_LOOT_RESPONSE. Да, трабла именно в нем, но структура помоему соответствует оффу. http://pastebin.com/LSgVzGE4

Есть такая мысль, что близзы поменяли алгоритм формирования randomSuffix, из-за чего клиент его не хочет принимать.

В 4.0.3 было добавлено новое поле. В 4.0.6 сменили тип у count (вроде бы :))

:ireful2:
вот только что сказал, что нет никакого randomSuffix. есть random property id - динамическое поле итема, и есть suffix - статическое поле из респонса (добавлено в 2.0.3).

Ну не знаю. Я строил обработчик пакета SMSG_ITEM_QUERY_SINGLE_RESPONSE по примеру из Кактуса. Клиент такие пакеты понимал нормально. http://pastebin.com/wDGtdqYH
то, что клиент их нормально понимал означает лишь то, что вы угадали с размерностью данных и числом полей, а не то, что всё в порядке :yes3:


то, что вы называете RandomProperty у меня называется Extra. это тоже не рандом никакой, а некое конечное число. в моей базе числа такие: 849, 1101, 514, 1016, 6273, 6272 и т.п.
RandomSuffix соответственно никакой не Random, а просто Suffix - указатель куда то в дбц на дополнительные фичи итема. это его отличает от "стандартного".

на самом деле Extra как бы по задумке было этим разнообразием. но вот в TBC близзы ввели понятие суффикса и вполне возможно поле Extra позднее стало обозначать что то иное.

в любом случае, это всё - вполне себе конечные числа в районе 1000-9000. ваши громадные значения клиент не может использовать в качестве ссылки (ID) и не может ничего по ним получить. вот и не хавает он такой невалидный пакет. кстати, где вы взяли такие числа? покажите пакет целиком.

и еще, random property id - это и есть suffix, соотвественно выбранный случайным образом (например при луте). на самом деле рандома у близзов никогда никакого не было и нет. но это другая тема.

Черт, я запутался уже в этих названиях :(
Итак, как я понял это дело завязано на 2х dbc: RandPropPoints.dbc (в котором идут параметры рандом статов) и ItemRandomSuffix.dbc (в котором идет энтри, и имя суффикса (из-за названия файла такое название и поля :)))

Т.е. по этому числу ищутся параметры в ItemRandomSuffix.dbc, так? А по суффиксу из RandPropPoints.dbc?

Числа были нормальные. Сейчас вручную просмотрел, и оказывается на некоторых итемах данные съезжают :( Вот пример: http://pastebin.com/LQELX8cv и съехало вот так: http://pastebin.com/VEQ7pZRU
Походу где-то что-то упустил :(

ну не стоит же все так буквально вопринимать, думать то тоже надо иногда :mda:
ItemRandomSuffix - имеется ввиду, что в этой таблице собраны рандомы суффиксов (еще одно подверждение, что никакого рандома у близов нет, все заранее просчитано).

я не могу сказать, где что сейчас ищется. давайте разбираться.

ну. конечно. мусор сплошняком :pardon:
для начала давайте пофиксим размерность пакета и поставим все поля на свои места, если это необходимо - введем новые unk-и.

и еще, поля в основном int, а не uint:
11.Allowable Class: 4294967295
12.Allowable Race: 4294967295
эти и подобные поля должны быть равны минус еденице.

Помоему близзы имели ввиду что рандомные будут статы у предметов, а не номера :)
Я заметил такую закономерность: если итем не имеет спеллов, то по имеющейся структуре он парсится более-менее нормально. Но если есть хоть один спелл, то размер пакета вырастает на 62 байта. Идой я особо не владею (что плохо :().
Заменить просто лень было :) Поправлю, спасибо :)

я так не думаю, на близзов это не похоже. они часто делают "рандомы" среди готовых записей (строки таблиц). но никогда еще не делали рандомы у значений полей этих записей.

у меня больше не открываются ваши ссылки на pastebin (удалены или протухли?). такие вещи лучше постить прямо в форум, не надо стесняться. отсюда уж точно никуда не денуться. обернуть их в тег CODE и все.
у меня подозрение, что вы неправильно или вообще не парсите счетчик спеллов итема. но вроде как у спеллов не было счетчика, был у бонусов. покажите дамп пакета.

ЗЫ. блин, надо какой то irc что ли...

Я это и имел ввиду :)

Вот к примеру отпарсенный итем с спеллом:

И дамп:
А на это начинает съезжать размер:

Спеллы парсю вот так:
Вроде как их кол-во равно 5, и вроде не менялось :)

:(

ICQ, Jabber, Skype :) Любой IM на ваш вкус :)

ну что я могу сказать, парсинг правильный. формат правильный.
а вот дамп неправильный. минус поставьте тому сниферу, который это отснифал. поля тут реально съехавшие прямо в дампе. у этого итема один спелл.
http://wowcore.ru/tmp/tpl_item_32453.gif

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

Добавлено через 35 минут
поразбирал дамп итема 32443, начиная со спеллов.
по формату видно, что количество полей совпадает. 6 полей на каждый спелл. но содержимое полей заставляет задуматься о том, что дамп явно кривой. видны уехавшие вниз поля данного спелла, а между ними какой то мусор в виде нулей и "-1".

еще непонятка с m_description. ну видно что юникод, но какие то левые нули в середине и странные коды "символов". толи я что то не знаю о юникоде, толи тут два m_description, толи тут опять мусор.

до тройки, которая является m_material поля совпадают. дальше не парсил. но тем не менее, непонятное значение в последнем интовом поле, это не инт, не флоат, а какой то... "мусорный рандом" :yes3:

еще там ближе к концу должны быть поле extended_cost, равное 1564 и поле req_disenchant_skill, которое равно -1. но в этих полях я не уверен. уверен лишь в том, что значения полей должны быть в дампе, если только эти поля не убрали из пакета. сразу оба.

у меня назрел вопрос:
откуда и каким образом был сделан снифф?

Добавлено через 17 минут
не удержался, распарсил концовку.

названия полей набил руками в соответствии с одним из последних сандбоксов, что я делал для катаклизма, не помню какой билд. т.е. размерность вроде как совпадает, теперь только вопрос, разве такие holiday_id бывают? :) в вашем парсинге не хватает двух полей. в связи с этим еще один вопрос: что за код и формат вы используете? что-то явно устаревшее.

Использую этот инжектор:

Насчет неправильного дампа не уверен, снифер ещё ни разу в плане фрагментации пакетов не подводил :)
Помоему extended_cost в этом пакете близы давно уже не шлют :)

Формат да, он страшный :) Но альтернативы пока что нет :( Сейчас с другом пишем свой снифер, но там пока что застряли на фрагментировании пакетов.

еще я тут подумал, что раз доверие к сниферу некоторое имеется, что раз другие пакеты дампятся нормально, значит так кардинально сменился формат SMSG_ITEM_QUERY_SINGLE_RESPONSE. значит спеллов там теперь не пять, а один, но полей по нему стало в 5 раз больше. было 6, стало 30. это само по себе не удивительно, такие манипуляции с данными близы проводят иногда. удивляет только то, что полей для одного сраненького спелла у одного сраненького итема стало в 5 раз больше. чем по сути экономии в байтах никакой и не сделали. это всё удивляет.

насчет extended_cost я ж говорю, я не уверен. я уверен только в том, что по количеству полей этот кусок дампа совпал. а значит этот extended_cost передается. ну или если он не передается, то передается дополнительно что то еще.

HuntsMan у вас неправильно читаются спеллы, на 90% уверен, что еще и статы и сокеты (т.к. код чтения не видел). В 4.0 структура изменилась.

Статы читаются нормально, проверено. А по поводу спеллов можно поподробней?)
Помоему это нереально, т.к. возьмем туже темную скорбь. К ней привязано несколько спеллов.

Топик стартер, а ты проверял, вызывается хэндлер этого пакета в клиенте вообще или нет? Например, сейчас я обнаружил, что при 100% правильной структуре и опкоде пакета SMSG_LIST_INVENTORY её хэндлер не вызывается. Причем не только хэнлдер, клиент этот опкод (в NetClient__Process) вообще не видит. При этом в world.log этот пакет тоже логируется.

Пытаюсь разобраться :(

ps: клиент перманентно пропатчен, однако.

Да, это заметил. Мб таже фигня что и с пингом было. Пинг тоже не получилось заставить работать под 4.0.3, хотя структура была индентична офу, но клиент втупую не хотел его обрабатывать...

итак, проблемы с размерностью и форматом данных, в частности по спеллам, успешно разрешены. чем дело то закончилось?

Вобщем кажись дело в гуиде. Никто не подскажет как его формируют близзы в 4.0.6?)

Ещё далеко не конец этой длинной и запутанной истории :D

Они сместили Entry на байт вверх.

К сожалению дело не в гуиде :( поправил формирование гуида, но ему все равно :(

Но зато хоть терь парсер нормально ентри парсить стал :)

Скиньте дамп world.log с этим пакетом. (в любом формате)

Пожалуйста :)

RandomSuffix-а нету, единичку туда попробуйте пошлите :) или Counter гуида

Неа, не прокатывает :( Там походу какая-то особая новая формула генерации этого поля, но мой моск пока что её не осилил :(

Тред думаю можно закрыть. Проблема решена хоть и хаком, но все-таки кое как работает :)

нет, не надо закрывать без объяснения. рассказывайте чо там.