[SLANDS] How are objects and units outlined / are quest objective? It's not CGQuestObjectiveCache

[cxmplexwow_]

I've never seen this question answered before. I've seen multiple people attempt to answer it, but from what I've found, none of them are correct.

The first suggesstion from the very own Jadd is to use these two functions:

CGQuestObjectiveCache::ObjectTrackedInQuest
CGQuestObjectiveCache::CreatureTrackedInQuest

However, I've noticed that ObjectTrackedInQuest DOES NOT work for things like GO_TYPE_CHEST. Take a look at the quest cache entry below for the quest :

Assault on the Vestibule - Quest - World of Warcraft

This item requires the item Weak Anima Mote - Item - World of Warcraft

That item is looted from this TYPE_CHEST gameobject:

Depleted Anima Canister - Object - World of Warcraft

However, the QuestCache DOES NOT save the object value, instead it simply saves the required item (172451)



------------------------------------

In the GameObjectCache, another suggestion to find tracked quest objects, we can find:



Which contains the objectId, and a string saying "questinteract". The game however does not populate the questId field of ChestGameObjectData, TrinityCore marks that it's unused, so that's a no-go as well. There is no link back to the Quest, so the GameObjectCache knows it's a quest interaction object, but doesn't actually know which quest it's tied to.

So it's neither QuestCache nor GameObjectCache. This includes the functions I mentioned above which check the QuestObjectiveCache. The quest objective cache only has the item the container contains.

------------------------------------



Both the tooltip AND the renderer knows that this is a quest object. It applies a outline/glow effect AND populates the tooltip with the quest related information. The question is HOW. How does it retrieve quest object information for this specific object. It doesn't appear to be QuestObjectiveCache, GameObjectCache, or QuestCache.


TrinityCore searches it's LootManager and iterates through LootTemplates to determine if a chest/container has quest loot:

bool LootStore::HaveQuestLootFor(uint32 loot_id) const
{
    LootTemplateMap::const_iterator itr = m_LootTemplates.find(loot_id);
    if (itr == m_LootTemplates.end())
        return false;

    // scan loot for quest items
    return itr->second->HasQuestDrop(m_LootTemplates);
}

bool LootStore::HaveQuestLootForPlayer(uint32 loot_id, Player const* player) const
{
    LootTemplateMap::const_iterator tab = m_LootTemplates.find(loot_id);
    if (tab != m_LootTemplates.end())
        if (tab->second->HasQuestDropForPlayer(m_LootTemplates, player))
            return true;

    return false;
}

They don't check any flags or game object values, instead stick solely to the loottemplate, so I'm really not sure if there is anywhere we can find this via the gameobject itself.

So that leaves me to think I need to find either how the tooltip is populated with quest information for a object (TooltipDataProvider I believe) OR how the game determines it should outline an object. I tried poking around in Ida to see how the game handles the OutlineMode cvar, and I did eventually come across something related to C_Player and OutLineMode (likely the self/player outline for "findingyourself"), but wasn't able to find anything related to quests or gameobject.

Has anyone ever figured this out? I know I can just scan tooltips in lua, but that's stupid for what I'm trying to do, and has expensive overhead. I want to call the function that gives the tooltip the quest information for that object. I can't find any function for this. I had thought the ones Jadd posted would be good enough (the CGQuestObjectiveCache ones), and they mostly work, but not for all objects sadly.

[cxmplexwow_]

Partial answer:


From an old version of trinitycore (this isn't present in modern TC for some reason):

else if (isType(TYPEMASK_GAMEOBJECT))                    // gameobject case
    {
        for (uint16 index = 0; index < m_valuesCount; index ++)
        {
            if (updateMask->GetBit(index))
            {
                // send in current format (float as float, uint32 as uint32)
                if (index == GAMEOBJECT_DYN_FLAGS)
                {
                    if (IsActivateToQuest)
                    {
                        switch (((GameObject*)this)->GetGoType())
                        {
                            case GAMEOBJECT_TYPE_CHEST:
                            case GAMEOBJECT_TYPE_GOOBER:
                                *data << uint16(GO_DYNFLAG_LO_ACTIVATE | GO_DYNFLAG_LO_SPARKLE);
                                *data << uint16(-1);
                                break;
                            default:
                                *data << uint32(0);         // unknown. not happen.
                                break;
                        }
                    }
                    else
                        *data << uint32(0);                 // disable quest object
                }
                // hide RAF flag if need
                else if (index == UNIT_DYNAMIC_FLAGS && GetTypeId() == TYPEID_PLAYER)
                {
                    if (!((Player*)this)->IsReferAFriendLinked(target))
                        *data << (m_uint32Values[index] & ~UNIT_DYNFLAG_REFER_A_FRIEND);
                    else
                        *data << m_uint32Values[index];
                }
                else
                    *data << m_uint32Values[ index ];       // other cases
            }
        }
    }

Basically, if the gameobject is a quest object, then the dynamicflags of the object are set to 0xFFFF0204.

This in combination with

CGQuestObjectiveCache::ObjectTrackedInQuest
CGQuestObjectiveCache::CreatureTrackedInQuest

Should work for every time of object (unit, gameobject -- perhaps not all of them though, item), but I haven't confirmed on everything yet.

------------------------------------------------------------------------------------


I say partial answer though, because I want to know what determines GLOW/OUTLINE (perhaps its even these flags, but I want to see the function), but the answer above accomplishes the same thing I was after anyways.

[shauren]

TrinityCore/QueryPackets.h at efdca47aff354079bc73d248e022c2e914d94e7b . TrinityCore/TrinityCore . GitHub - it is linked to quests using itemid, not questid

And the code you mentioned was simply moved, it is still there TrinityCore/ViewerDependentValues.h at efdca47aff354079bc73d248e022c2e914d94e7b . TrinityCore/TrinityCore . GitHub

[cxmplexwow_]

TrinityCore/QueryPackets.h at efdca47aff354079bc73d248e022c2e914d94e7b . TrinityCore/TrinityCore . GitHub - it is linked to quests using itemid, not questid

And the code you mentioned was simply moved, it is still there TrinityCore/ViewerDependentValues.h at efdca47aff354079bc73d248e022c2e914d94e7b . TrinityCore/TrinityCore . GitHub

That GameObjectStats is useful, didn't know about that one.

Again though, I am a bit curious on what determines glowing effects as both your player unit, enemy unit, and gameobjects all exhibit a glow/outline.

Checking DYN_LO_FLAG_ACTIVE and DYN_LO_FLAG_SPARKLE works great for gameobjects, but I don't think the game actually uses those values to determine if it should outline the model.

[shauren]

That should be enough for gameobjects. If you disable outline in video settings, you get the classic sparkles back when that flag is set

[cxmplexwow_]

That should be enough for gameobjects. If you disable outline in video settings, you get the classic sparkles back when that flag is set

What about tooltip population? Do you know how the quest text is added to the tooltip (obviously some sort of lookup has to happen there). Is this sent from the server I'm guessing?