Closed Romman closed 11 years ago
знаю что в трине бодались долго и таки победили. можно взять там...
В трине так же как и у нас отсылают 0, или проблема всё-таки не в этом?
мда. то ли у меня склероз, то ли это было в каком-то привате. там юмор вроде был в том, что если игрок близко, то гуид не нужен, берется типа с кэша, а если далеко - то надо вместо 0 втыкать гуид отсылающего...
сейчас попробую впихнуть сюда гуид, посмотрю что получится
в тс аналогичная ситуация. пробуйте слать гуид мало ли что и получится
а ничего и не получается...
вот я и помню что долго бодались... не зря наверное.
хэндлер проверьте, который обрабатывает этот опкод (мало ли там какие проверки)
Опкодов от клиента вообще чтоли нет?
есть опкоды, вот только чтобы в пати да еще и далеко - нет ни одного примера. а так в этом опкоде часто первый гуид дважды идет, в остальных случаях вторым 0. в клиентхендлере черт ногу сломит, и проблема явно не там а в каких-то LUA-наворотах, до которых чтобы просто добраться - день надо убить...
WorldSession::HandleQuestgiverAcceptQuestOpcode(WorldPacket & recv_data) смотрим, анализируем.
лично у меня возникают вопросы по поводу этих строчек в тс: // some kind of WPE protection if (!_player->CanInteractWithQuestGiver(object)) return;
опаньки... а слона-то и не приметили :) я кстати давно уже собирался этот метод маленько причесать...
там ничего криминального нет
bool WorldSession::CanInteractWithQuestGiver(ObjectGuid guid, char const* descr) { if (guid.IsCreatureOrVehicle()) { Creature* pCreature = _player->GetNPCIfCanInteractWith(guid, UNIT_NPC_FLAG_QUESTGIVER); if (!pCreature) { DEBUG_LOG("WORLD: %s - %s cannot interact with %s.", descr, _player->GetGuidStr().c_str(), guid.GetString().c_str()); return false; } } else if (guid.IsGameObject()) { GameObject* pGo = _player->GetGameObjectIfCanInteractWith(guid, GAMEOBJECT_TYPE_QUESTGIVER); if (!pGo) { DEBUG_LOG("WORLD: %s - %s cannot interact with %s.", descr, _player->GetGuidStr().c_str(), guid.GetString().c_str()); return false; } } else if (!_player->isAlive()) { DEBUG_LOG("WORLD: %s - %s is dead, requested guid was %s", descr, _player->GetGuidStr().c_str(), guid.GetString().c_str()); return false; }
return true;
}
остается только понять, что же это за гуид приходит с клиента
в сниффах что есть у меня - либо дубль первого либо 0.
Что-то после продублирования первого гуида ситуация никак не изменилась
тогда реверсим или подключаем логику.
сегодня лазил по иде, заодно кое-как дополз до этого пакета. структура, что сейчас в мангосе, нихрена не правильная, наверное оттуда и грабли. кому-нибудь еще интересно? https://gist.github.com/2731485 PS не то чтобы совсем неправильная. но неполная. судя по нему, гуид надо слать реального гивера, а вторым гуидом - плеера.
мне интересно, вижу ваш gist, довольно забавно получается. sub_58C5A0(npcGuid, playerGUID, HIDWORD(playerGUID), 1, &v19, v68, BYTE3(a1)); sub_58C720(&v18); sub_58DD50()
В последней точно вызываем SignalEvent(event_quest_detail, v26) и .. все. на посторонние действия перестает реагировать. Кстати со труктурой в трине все окей, возможно в мангосе тоже все нормально
https://gist.github.com/2732425 да пошел этот второй гуид куда подальше, лично не вижу смысла в нем. в гисте рабочий вариант куест шаринга, правда для трини, но думаю тут минимум отличий
там только убрано несколько проверок, в мангосе их и так нету... с гуидом этим основная песня идет в sub_58C5A0, там муторно, но проверяется его наличие у клиента и если он недоступен - то он заменяется на второй гуид. чушь в общем. а может я все это хреново понял... https://gist.github.com/2757063
@rsa, там шлется гуид кому отправляем вместо гуида отправителя. Скорее всего не близзлайк, но рабочий ;) Да и поидее у нас должны быть закешированы на клиенте все гуиды игроков, которые в пати/рейде, но там возникает какойто бред. Как насчет того, чтобы посмотреть как это сделано в кате? (томрус недавно обновил базу)
can you guys speak English?
this is why I hate mangosr2... for that freek language. That is why I never bother to use it in my servers!
this dialog not needed anybody, except developers. by netiquette, discussion cotinued on starting language - some another dialogues in R2 change not one language in process. if you do not know how to use googletranslate, then you nothing to do in the Net at all
It would be gracefully, that all write english. to googletranslate: I want not swap between tabs, when reading. the translation from google is sometimes bad. ---->Better: all write english (simple english)
@rsa, на трине это уже давно работает ;)
@Chaplain, now and on R2 =)
in https://github.com/mangosR2/mangos/commit/ade50e961950ada5b0a1dfef472591be7519f332
If you share the quest to the groupmate who stands close - everything's alright
But when you share quest to player being far away (out of visible range) or on another map - it doesnt work.
Quest Gossip appears as expected, but pressing Accept or Canel Button doesnt respond with any reaction. Or even sometimes player gets quest completing (with choosing reward and Complete button), and still no reation.
WorldPacket data(SMSG_QUESTGIVER_QUEST_DETAILS, 100); // guess size data << guid; data << uint64(0); // wotlk, something todo with quest sharing? data << uint32(pQuest->GetQuestId()); data << Title; data << Details; data << Objectives; data << uint8(ActivateAccept ? 1 : 0); // auto finish data << uint32(pQuest->GetQuestFlags()); // 3.3.3 questFlags data << uint32(pQuest->GetSuggestedPlayers()); data << uint8(0); // IsFinished? value is sent back to server in quest accept packet
Sure problem with the second value
uint64(0);
Either need put guid of target of the text or need give sort of flag (for example IsfromQuestGiver / IsFromSharing)Any ideas?
P.S. http://ru-mangos.ru/showthread.php?t=3839