Слетающий комбатлог и пет по имени "неизвестно"

[rsa]

Проблема заключается в периодическом "затыкании" комбатлога на клиентах и пропадании имен петов.
В результате разборок выявлено, что запрос PET_NAME_QUERY от клиента приходит до того как выполнится запрос в базу на поднятие оттуда темпунсаммоненного или нового пета (вероятность естественно 50/50).
Частичное решение проблемы:
http://github.com/insider42/mangos/commit/15aa125f358103bcdcf20efec5461bf1c2ad9d9c
Полное решение проблемы (предлагается только путь):

=========== Pet.h
bool IsInWorld() const {return (!m_loading && !m_removed && Object::IsInWorld()); }
=========== PetHandler.cpp
void WorldSession::HandlePetNameQueryOpcode( WorldPacket & recv_data )
{
DETAIL_LOG( "HandlePetNameQuery. CMSG_PET_NAME_QUERY" );

uint32 petnumber;
ObjectGuid petguid;

recv_data >> petnumber;
recv_data >> petguid;

SendPetNameQuery(petguid,petnumber);
}

void WorldSession::SendPetNameQuery( ObjectGuid petguid, uint32 petnumber)
{
Creature* _pet = GetPlayer()->GetMap()->GetAnyTypeCreature(petguid);

if (!_pet || !_pet->isPet())
return;

Pet* pet = (Pet*)_pet;

uint32 sleeptime = 0;

while (!pet->IsInWorld() && sleeptime < 2000)
{
ACE_Based::Thread::Sleep(100);
sleeptime += 100;
}

if (!pet->IsInWorld() || pet->GetCharmInfo()->GetPetNumber() != petnumber)
{
WorldPacket data(SMSG_PET_NAME_QUERY_RESPONSE, (4+1));
data << uint32(petnumber);
data << uint8(0);
_player->GetSession()->SendPacket(&data);
return;
}
else if (pet)
{
std::string name = pet->GetName();

WorldPacket data(SMSG_PET_NAME_QUERY_RESPONSE, (4+4+name.size()+1));
data << uint32(petnumber);
data << name.c_str();
data << uint32(pet->GetUInt32Value(UNIT_FIELD_PET_NAME_TIMESTAMP));

if( pet->isPet() && ((Pet*)pet)->GetDeclinedNames() )
{
data << uint8(1);
for(int i = 0; i < MAX_DECLINED_NAME_CASES; ++i)
data << ((Pet*)pet)->GetDeclinedNames()->name[i];
}
else
data << uint8(0);

_player->GetSession()->SendPacket(&data);
}
}


Почему не предлагаю патчем - во первых использование sleep() в коде дурной тон, по хорошему это надо делать через блокировки, а это - уже к разработчикам. Во вторых у меня в коде петов куда глубже изменения и патча не выйдет. Но думаю мысль понятна.
PS оттестировано, работает как положено.

PPS как выяснилось, на серверах с особо тормозной базой 2х секунд явно не хватает, плюс еще при некоторых телепортах таже история. Приходится ставить 10 и более, никаких проблем это не вызывает. Для тестирования пробовал ставить минуту.

[SilverIce]

не совсем понял изз-за чего комбат лог "слетает" - из-за незагруженных DeclinedNames?
можно попробовать declined name пета инициализировать до добавления на карту, а не после, как это сейчас делается(см Pet::LoadPetFromDB)

[added]
без тормозов сервера воcпроизвести скорее всего не удастся
речь o:
@@ -265,10 +265,27 @@ bool Pet::LoadPetFromDB( Player* owner, uint32 petentry, uint32 petnumber, bool
m_resetTalentsCost = fields[15].GetUInt32();
m_resetTalentsTime = fields[16].GetUInt64();

delete result;

+ if (owner->GetTypeId() == TYPEID_PLAYER && getPetType() == HUNTER_PET)
+ {
+ result = CharacterDatabase.PQuery("SELECT genitive, dative, accusative, instrumental, prepositional FROM character_pet_declinedname WHERE owner = '%u' AND id = '%u'", owner->GetGUIDLow(), GetCharmInfo()->GetPetNumber());
+
+ if(result)
+ {
+ if(m_declinedname)
+ delete m_declinedname;
+
+ m_declinedname = new DeclinedName;
+ Field *fields2 = result->Fetch();
+ for(int i = 0; i < MAX_DECLINED_NAME_CASES; ++i)
+ m_declinedname->name[i] = fields2[i].GetCppString();
+
+ delete result;
+ }
+ }
//load spells/cooldowns/auras
_LoadAuras(timediff);

//init AB
if (is_temporary_summoned)
@@ -316,28 +333,10 @@ bool Pet::LoadPetFromDB( Player* owner, uint32 petentry, uint32 petnumber, bool
((Player*)owner)->SetGroupUpdateFlag(GROUP_UPDATE_PET);

((Player*)owner)->SendTalentsInfoData(true);
}

- if (owner->GetTypeId() == TYPEID_PLAYER && getPetType() == HUNTER_PET)
- {
- result = CharacterDatabase.PQuery("SELECT genitive, dative, accusative, instrumental, prepositional FROM character_pet_declinedname WHERE owner = '%u' AND id = '%u'", owner->GetGUIDLow(), GetCharmInfo()->GetPetNumber());
-
- if(result)
- {
- if(m_declinedname)
- delete m_declinedname;
-
- m_declinedname = new DeclinedName;
- Field *fields2 = result->Fetch();
- for(int i = 0; i < MAX_DECLINED_NAME_CASES; ++i)
- m_declinedname->name[i] = fields2[i].GetCppString();
-
- delete result;
- }
- }
-
m_loading = false;

SynchronizeLevelWithOwner();
return true;
}

[Insider42]

Проблема не только у петов охотника, очень легко воспроизвести с петом чернокнижника. Призываем импа, активируем Кровавый договор, садимся на коня и слезаем с него - готово - имя пета = Неизвестно

[rsa]

Я переделал патч на новом принципе, без sleep(). Declined names тут совсем ни при чем, главное чтобы на QUERY приходил осмысленный ответ, если нет - имеем "неизвестно" и слетевший комбатлог.

[LordJZ]

А что мешает отправлять SMSG_PET_NAME_QUERY_RESPONSE после «того как выполнится запрос в базу на поднятие оттуда темпунсаммоненного или нового пета»?

[rsa]

А что мешает отправлять SMSG_PET_NAME_QUERY_RESPONSE после «того как выполнится запрос в базу на поднятие оттуда темпунсаммоненного или нового пета»?

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

[LordJZ]

Нет, я имею ввиду не ответ на запрос, а конкретно отправление опкода после кода загрузки.

[rsa]

тем что 1) это хак 2) клиент все равно его игнорит если не запрашивал (пробовал ;)

[Fmut]

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

[SilverIce]

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

просьба оттестить, возможно загруженность серверов тоже чтото дает, хотя помоему это решает все

void WorldSession::SendPetNameQuery( uint64 petguid, uint32 petnumber)
{
Creature* pet = _player->GetMap()->GetCreatureOrPetOrVehicle(petguid);
if(!pet || !pet->GetCharmInfo() || pet->GetCharmInfo()->GetPetNumber() != petnumber)
+ {
+ WorldPacket data(SMSG_PET_NAME_QUERY_RESPONSE, 4+4+2);
+ data << uint32(petnumber);
+ data << uint8(0);
+ data << uint32(0);
+ data << uint8(0);
+
+ _player->GetSession()->SendPacket(&data);
return;
+ }

std::string name = pet->GetName();

WorldPacket data(SMSG_PET_NAME_QUERY_RESPONSE, (4+4+name.size()+1));
data << uint32(petnumber);

[rsa]

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

в том что пет еще не создан и не загружен. и это создание может затянуться на 1-2с+лаг до клиента.

[rsa]

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

просьба оттестить, возможно загруженность серверов тоже чтото дает, хотя помоему это решает все

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

[SilverIce]

у вас формат в первом посте неправильный, я не знаю что вы пробовали
баг описанный Карателем воспризвести не удалось

[rsa]

Неправильный формат чего? Инициатора перезапроса? Хе...
Баг существует на чистом ядре с времен 7ххх и всоспроизводится тем проще чем больше отклик сервера БД.

[SilverIce]

в [10651] лишь частичный фикс - баг один, но причины разные

[rsa]

Это не фикс, это подпорка, причем в принципе неверная. У меня она почти полгода глючила пока не решил наконец разобраться.
Причин там всего 3, именно этот патч не фиксит не одну из них.

[SilverIce]

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

[rsa]

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

[SilverIce]

Packet S->C, SMSG_DESTROY_OBJECT (170), len 9
37 0D 00 C4 4D 82 40 F1 00
GUID: 0x824DC4 UnitPet D37
bool False

Packet C->S, CMSG_PET_NAME_QUERY (82), len 12
C4 4D 82 00 37 0D 00 C4 4D 82 40 F1
Pet number: 8539588
Pet guid: 0x824DC4 UnitPet D37

Packet S->C, SMSG_PET_NAME_QUERY_RESPONSE (83), len 10
C4 4D 82 00 00 00 00 00 00 00
Pet number: 8539588
name:
name timestamp: 0
has declined name: 0


на этом думаю и закончим

[rsa]

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

[RomanRom2]

в том что пет еще не создан и не загружен. и это создание может затянуться на 1-2с+лаг до клиента.
и все же давайте еще немного продолжим, с вашего позволения.

я тоже не очень понимаю, что значит "пет еще не создан" и "это может затянуться"?

давайте рассмотрим последовательность действий:
1. игровой юнит (пет) сначала создается на сервере, затем отсылается А9 клиенту.
2. клиент видя такое дело запрашивает имя. у сервера запрашивает.
3. сервер отвечает именем. из уже созданной структуры данных на первом шаге.

или я что то не понимаю? откуда такое время берется: 1-2 секунды на создание? я могу предположить, что это время на транспорт пакета сервер->клиент, на лаги клеинта на отрисовку. это можно понять и так скорее всего и будет. но:

запрос имени пета будет позже на 1-2 секунды от момента создания юнита на сервере. соответственно в этот момент сервер легко может ответить корректным пакетом с правильным именем.

нет?

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

так что же не так в вашем случае? давайте разбираться.

[tempura]

Гаряа-а-а-ачии фински-и-и-ие па-а-а-арни веэ-э-эдь не-э-э устрооо-о-оят дра-а-аку?

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

[SeT]

Гаряа-а-а-ачии фински-и-и-ие па-а-а-арни веэ-э-эдь не-э-э устрооо-о-оят дра-а-аку?

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

скройся.

[RomanRom2]

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

[Fmut]

RomanRom2 я именно это и сказал в 9 посте :) Прям КО какой-то =)

[rsa]

Долго, скучно и неинтересно рассказывать то что желающие могут посмотреть по коду.
Коротко - клиент шлет запрос на имя пета тупо через Х мс после каста спелла, который его должен вызвать, или после изменения своего состояния (mounted, on_transport, on_vehicle). Почему - не разбирался.
В мангосе в 80% случаев структура "пет" при создании (то есть от момента начала отработки спеллэффекта "вызов", или от момента начала вызова темпунсаммоненного пета, до момента получения структурой значения в поле "имя") проходит стадию запроса информации из БД. В зависимости от загрузки и расположения БД запрос-ответ может занять Y мс - от 0,05 до 2-3 секунд (мерял лично, может конечно и больше).
В результате имеем следующие случаи: (в зависимости от разницы Х и Y)
1. запрос пришел когда структура "пет" еще не создана
2. запрос пришел когда структура "пет" создана, но еще не получила имя
3. запрос пришел когда структура создана, получила имя но не добавлена на карту
4. когда пет полностью функционирует.
При удалении пета история немного проще, но тоже есть 2 варианта:
5. пет убран с карты но существует как объект
6. пет удален полностью.

Добавленный SilverIce код частично устраняет проблему в случаях 5 (хаком, могут быть глюки посколько ауры пета еще не сняты) и 6 - ну там проблемы и не было.
В случаях 1-4 он превращает временную проблему с отсутствием имени в постоянную - зеро запишется в кэш клиента и пет будет глючить регулярно. Патч эксплуатировался с весны, поэтому протестировано достаточно.

Я решил проблему, предусмотрев все случаи (первый пост был только одним из вариантов, весьма кривым). Предлагать свое решение в ядро не буду, потому что оно не слишком красивое и самому не нравится. Но лучше пока придумать не могу. А поскольку возился я с ним достаточно долго и гонял все возможные варианты, то принятый в ядро патч (годичной давности, и уже всем давно известно что он не спасает) у меня кроме нервного "хихи" ничего не вызывает.

[TOM_RUS]

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

[RomanRom2]

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

Коротко - клиент шлет запрос на имя пета тупо через Х мс после каста спелла, который его должен вызвать, или после изменения своего состояния (mounted, on_transport, on_vehicle). Почему - не разбирался.
а стоило бы. после этой фразы я дальше не читал.
не так всё тут работает. вы наверное не до конца понимаете суть спеллов и спелл-системы в целом. давайте разбираться...

прямо по порядку. что такое "каст спелла"? это команда, инициированная со стороны клиента. типа: "я - начинаю".

далее опустим подробности о проверках валидности, области видимости, сбор целей и тому подобное. собственно это занимает некоторое время, хотя бы то самое, которое тратит клиент на отрисовку бегунка, ну типа каст выполняется.

далее собсно стадия "поехали" или "фейл". с этого момента серверу сообщается в частности "призвать пета".

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

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

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

итак, апдейт пакет ушел клиенту. клиент видя такое дело, опа - тут чото какие то новые объекты надо по-креатить. нуко разгребем. и начинает разгребать.

разгребает... разгребает... так, чего это у нас такое тут: update type = create, так хорошо. object type = unit, отлично. читаем структуру юнита. назначили GUID, скреатили. опа, UNIT_FIELD_PETNUMBER заполнен. дык ёлы палы - это ж пет чейто. UNIT_FIELD_SUMMON заполнен, ага - вот чей.

таак, а у пета ж имя есть, нука а чо за имя то? ща спросим: CMSG_PET_NAME_QUERY.

ход процесса улавливаете?

т.е. у вас явное недопонимание, что происходит между "каст спелла призыва пета" и "клиент запросил имя пета". а происходит вона скока всего.

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

видите аналогию? я вам открою маленькую тайну: так в wow сделано всё - сначала создается "нечто", только потом клиент спрашивает "а собсно чо это?".

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

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

[rsa]

[I]Долго, скучно и неинтересно рассказывать
а стоило бы. после этой фразы я дальше не читал.
не так всё тут работает. вы наверное не до конца понимаете суть спеллов и спелл-системы в целом. давайте разбираться...

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

[RomanRom2]

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

объяснение с точки зрения теории - это первое что мы можем сделать в данном случае. собственно мое мнение - чудес не бывает. я думаю никто не будет возражать, если мы примем за аксиому факт: клиент НЕ МОЖЕТ отослать запрос на имя пета БЕЗ апдейт пакета на этого пета?

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

для проверки я затыкал функцию саммона затычкой _до_ создания new Pet. пет естественно не создавался
о какой функции мы говорим? хендлер спелл-эффекта SUMMON_PET? если нет, - проследите от хендлера, когда вызывается ваша функция суммона пета. уверен, вы встретите функцию отправки апдейт пакета.

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

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

раз вы так любите все подтверждать практикой, предлагаю сделать следующее:
заткните затычкой весь спелл-эффект SUMMON_PET и после мы вернемся к этому разговору. простой exit(); или как там у вас в сях - return; в самом начале.

и подтвердите мои слова снифами ваших экспериментов.

[rsa]

1. Уважаемый RomanRom2, я вообще не программист.
2. Я знаю как и почему посылается запрос на имя пета именно "БЕЗ апдейт пакета на этого пета". Теперь мне интересно, как вы объясните этот факт своими теоретизированиями. Апдейт-пакет отправлен не был, примите это за аксиому. Могу даже дать подсказку - проблема в разнице мангоса и близз-сервера.
3. Прослеживать и сниффать я ничего не собираюсь. За последние 3 месяца я переписал код петов в мангосе процентов на 70, добавил им еще почти 100кб кода и еще больше данных, написал все саммон-хандлеры считайте заново. И что и как там происходит пока еще помню весьма неплохо.

[virusav]

1. После коммита SilverIce ни разу не было пета без имени, до этого очень часто.
2. rsa, нежелание отслеживать и разбираться не красит. Кроме того, если бы в ядро был принят упомянутый выше код петов, переписанный процентов на 70 и если бы он работал правильно, то тогда можно было приводить это в качестве довода.

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

[RomanRom2]

не хотите нормально общаться, да... никак не хотите... ну что ж...

1. Уважаемый RomanRom2, я вообще не программист.
да не стесняйтесь. я тоже не программист. я так... фуру разгружаю.

2. Я знаю как и почему посылается запрос на имя пета именно "БЕЗ апдейт пакета на этого пета". Теперь мне интересно, как вы объясните этот факт своими теоретизированиями.
ну хорошо, допускаю и этот факт. но так или иначе, апдейтить плеера нужно все равно ПОСЛЕ всех манипуляций с петом.

Апдейт-пакет отправлен не был, примите это за аксиому.
нет, не могу. поймите, ни что в этом мире не происходит просто так. в мире близзов уж тем более, коли этот мир был создан руками. была причина. какой то апдейт пакет БЫЛ послан. тот или иной.

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

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

За последние 3 месяца я переписал код петов в мангосе процентов на 70, добавил им еще почти 100кб кода и еще больше данных, написал все саммон-хандлеры считайте заново.
вы знаете, я уже не маленький мальчик и по моему опыту, когда звучат подобные фразы, означает, что человеку уже сказать нечего. вот скажите, например:
я переписал код петов в мангосе процентов на 70
как вы поняли, что на 70 процентов? меня лично всегда забавляла визуальная система оценки в подобных случаях. на поверку как правило эта цифра делится на 10.

добавил им еще почти 100кб кода
чем вы хвалитесь то? это разве показатель качества кода? мол де ваши дополнительные 100кб взяли и покрыли весь недостающий функционал? знаете, у индусов например код в 100кб легко трансфомируется в код в 20кб в большинстве случаев. при этом качество кода увеличивается, что подверждается всякого рода статическими analysis tools, которые соответствуют всего лишь третьему уровню оценки качества программного продукта. всего их пять. а давайте вместе поржом - натравим на ваш код coverity prevent? он нас рассудит.

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

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

в итоге что мы имеем: полагая что вы НЕ программист, могу себе представить ЧТО вы там понаписали.

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

не сводите на "нет" своей практикой все наши теории, накопленные и проверенные в нашем проекте за все эти прошлые пять лет.

[rsa]

1. После коммита SilverIce ни разу не было пета без имени, до этого очень часто.
2. rsa, нежелание отслеживать и разбираться не красит. Кроме того, если бы в ядро был принят упомянутый выше код петов, переписанный процентов на 70 и если бы он работал правильно, то тогда можно было приводить это в качестве довода.

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

гораздо реже, но будет продолжаться. я повторяю, использованный SilverIce код тестировал почти полгода. И не я один.
В ядро мой код принят не будет. Все желающие его давно используют самостоятельно.
К сожалению RomanRom2 не пытается "разобраться самостоятельно", а пытается найти повод для флейма ;) Что ясно по его крайнему письму, после фразы "это вы неподумав сказали, наверное, что бы еще больше подняться в глазах общественности? каких еще данных? там данных то... с десяток пропертей и методов."
Вот только 1 файл с данными:
http://github.com/rsa/mangos/blob/master/addition/731_pet_levelstats_data_mangos.sql
А их таких 4.
То есть человек полностью не представляет о чем идет разговор, и в то же время изображает из себя доцента на экзамене. К сожалению в таком ключе продолжать беседу смысла не вижу. Тему надо закрывать.

[Konctantin]

Господа, давайте не ссорится, а спокойно и хладнокровно вести конструктивный разговор.

[virusav]

rsa, стоило обратить внимание на все вышесказанное, учитывая хотя бы тот момент, что это исходило от разработчиков.

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

[RomanRom2]

К сожалению RomanRom2 не пытается "разобраться самостоятельно", а пытается найти повод для флейма
к сожалению всё с точностью да наоборот. проследите ветку. я вам задал вопрос, вы со словами "долго скучно и неинтересно" ответили в духе "два мнение, одно мое, другое неправильное", типа шли бы вы ребята... я же практиковался, я же сделал... я же проверил... целых полгода тестировал... а вы все тут только воздух сотрясаете. ну как то так выглядит со стороны.

касательно меня - я действительно пытаюсь разобраться. я вам рассказываю сценарии, прошу рассказать свои. выражаясь вашими же словами - вы в ответ только флейм разводите. я вам привожу конкретные примеры и сценарии, я вам говорю конкретные факты и задаю конкретные вопросы. на всё это я увидел только:
- Долго, скучно и неинтересно рассказывать
- Почему - не разбирался.
- ваши размышления прекрасны и удивительны
- без подтверждения практикой мне малоинтересно.
- я вообще не программист
- как вы объясните этот факт своими теоретизированиями
- Могу даже дать подсказку - проблема в разнице мангоса и близз-сервера. (спасибо, без ваших сакралов я бы не догадался)
- Прослеживать и сниффать я ничего не собираюсь
- В ядро мой код принят не будет.
- То есть человек полностью не представляет о чем идет разговор
- в таком ключе продолжать беседу смысла не вижу
вот ваш ключ этой беседы. ничего. ноль. в таком ключе честно говоря мне тоже кажется, что смысл диалога отсутствует с вашей стороны.

Вот только 1 файл с данными:
ах, вот оно что... вы путаете данные объекта с их значениями. ну это неудивительно, вы же не программист. а я и подумать не мог, что у вас все ТАК захардкожено... ну что ж, ладно, по этому вопросу беру свои слова обратно.

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

т.е. вместо того что бы ответить по существу, по теме так сказать, вы сами выбрали путь флейма.

в третий раз задаю вам свой вопрос: расскажите сценарий, при котором клиент отправляет запрос имени пета без какого либо апдейт пакета. как вопроизвести проблему?

[rsa]

rsa, стоило обратить внимание на все вышесказанное, учитывая хотя бы тот момент, что это исходило от разработчиков.
Чтобы не разводить флуд, ответьте хотя бы на:

Сценарий очень прост - апдейт-пакет приходит при _первом_ создании пета. 1 раз. Далее (это мои предположения, для проверки надо раскатывать клиент по сабам) клиент считает его существующим, пока поле плеера UNIT_FIELD_PETNUMBER заполнено. И после изменения состояния (см. 26) перезапрашивает имя пета (зачем? АХЗ. ну не хранится оно в самой структуре данных плеера).
Разница в том, что на близзсервере пет при том, что у нас называется tempunsummon видимо не удаляется как структура из памяти, а каким-то образом "прячется", продолжая иметь все необходимые для ответа на запрос характеристики. Мы же пета _полностью_ удаляем (не очищая вышеуказанное поле), и имеем описанные выше грабли, включая запрос имени, который по мнению RomanRom2 теоретически невозможен.
Кстати, читать его сообщения все смешнее и смешнее. Теперь понятно почему в некоторых местах ядра код такой, что смотреть страшно. Наверное его писали Программисты с большой буквы. Разработчики ядра, которые, четко отличают границу между данными и ДАННЫМИ, но даже не знают сколько же в ядре хандлеров отвечают за саммон петов. Не один, RomanRom2, не один. Не верите? Посчитайте. Их 5. И это без учета вспомогательных ;)

[RomanRom2]

Мы же пета _полностью_ удаляем (не очищая вышеуказанное поле), и имеем описанные выше грабли, включая запрос имени, который по мнению RomanRom2 теоретически невозможен.
конечно невозможен. дыма без огня не бывает. вы же сами ответили на свой вопрос, и я на него ответил... ну хорошо, скажем так - сделал предположение, в #33. потому что других вариантов нет. как я и сказал - апдейт пакет должен быть, примите это за аксиому, наконец.

я вообще то наивно полагал, что удаление пета из мира производится корректно. т.е. со всеми удалениями и очищениями. если это не так, то не логично ли поправить функции удаления?

вам как непрограммисту, видимо это сложно понять. вместо этого нужно сделать кучу затычек и затем таки предлагать свое "решение", при этом воровато оглядываясь, оправдываться мол да, так делать нехорошо и так далее в таком духе.

но даже не знают сколько же в ядре хандлеров отвечают за саммон петов. Не один, RomanRom2, не один. Не верите? Посчитайте. Их 5.
уважаемый Ученый, я вам охотно верю в этом вопросе. не придирайтесь к словам, вы прекрасно поняли что я имею ввиду. только, если вы не в курсе, я не имею никакого отношения к мангосу и никогда его не писал. у меня нет исходников мангоса со времен, кажется, толи 2.0, толи 2.2, честно не помню.

спасибо за ответ (наконец то) по делу. итак, руткоз найден: некорректное удаление пета.

[TOM_RUS]

... клиент считает его существующим, пока поле плеера UNIT_FIELD_PETNUMBER заполнено.


Судя по снифам это поле у плеера не должно инициализироваться...

[rsa]

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