Trinitycore: Auto-accepting quests does not work correctly

[mindevis]

Description:
When accessing the NPC, auto-accepting quests should take place in the starting locations, but it does not work correctly, when the address is displayed, a menu with the name of the quest is displayed, and after it is clicked, an auto-acceptance of the quest takes place.
And it should work as follows: when accessing, the quest itself opens immediately and its auto-acceptance occurs.
As an example, the quest 28806 NPC951

And should work like this:

Steps to reproduce the problem:

1. Step 1 Click on the NPC 951
2. Step 2 Click quest name and quest auto-accepted, but it's not right

Branch(es):
master

TC rev. hash/commit:
https://github.com/TrinityCore/TrinityCore/commit/36ff7668823f56d81e422c4baeca43b8a32ba810

Operating system:
Windows 10 Pro

[mindevis]

No one knows how to fix this mistake?

[illfated]

Probably needs more feedback from other testers to narrow it down.

[mindevis]

Okey i'm record video file and posting in this topic.

[illfated]

There is also the question of whether this issue is caused by something in the core files or if it is only a DB issue (which we don't know yet).

[mindevis]

I think that this problem is related to the database,
The essence of the problem lies in the fact that when accessing npc, the task does not auto-accept, but a window opens in which it is necessary to click on the task name and its acceptance takes place

[illfated]

Very well, in the 3.3.5 branch (3.3.5a game client), any starting quest giver with only 1 quest available, opens directly into the quest gossip and that quest is auto accepted.
To me, it looks like this issue is caused by the quest_greeting window opening instead of the single quest gossip opening directly.
The quest_greeting gossip should (in theory) only be used by quest givers when there is more than 1 quest available.
I am still uncertain if this should be handled by DB quest condition settings, rules in the conditions table or by core quest handlers.

[mindevis]

I think that it would be better to make a video, and attach a link to the video for what would be seen clearly in what the actual problem lies.

[illfated]

@malcrom - if you are still around, would you venture a guess at this issue?

[mindevis]

@illfated what do you mean?

[illfated]

My question is for the user malcrom (https://github.com/malcrom), in case he still reads this issue tracker.

[Seyden]

The Question is, does the npc can have multiple quests at one moment ? and yes you could change the npc flag to "fix" this issue.. but dunno if the npc already has the correct npc flag

[Seyden]

He probably does have Flag 3, if you remove Flag 1, he will only have the Flag Quest Giver and will do that actions that you wanted

[Killyana]

The npcflag=2 for npc=951

[mindevis]

@Killyana @Seyden THX npcflag=3 works as on the official server
Please close this issue

[Killyana]

No, this is wrong this npcs doesn't have a gossip_menu so the npc flag must be 2 and not 3, it must be fixed on core side.

[mindevis]

@Killyana
Such a problem is not only in this NPC
This NPC was used as an example
Almost all NPCs of the start zones have this problem

[Shauren]

Isn't this caused by that completely broken sql update that mass updated all type_flags?

[Killyana]

No Shauren type_flags=0 and the commit related to this was never pushed to master and reverted on 3.3.5

[mindevis]

Comparing in the database two NPCs revealed the following:
NPC 197 and NPC 951
npc_flags: 197 (3), 951 (2)
NPC 197 working correct
NPC 951 working not correct

[mindevis]

what do you think about my comparison ??? @Killyana

[illfated]

A bit odd that it contradicts what Seyden suggested in https://github.com/TrinityCore/TrinityCore/issues/22010#issuecomment-396233214 . But as Killyana said in https://github.com/TrinityCore/TrinityCore/issues/22010#issuecomment-396366176, it most likely needs to be fixed in the core files.

[Seyden]

The question is now how blizz handles it.. if you could find a npc with flag 3 which only have 1 option available and instantly shows you the quest.. that would be a great indicator.. if you could find one, we could implement it in the core

[mindevis]

So here npc 197 has npcflag = 3
and so by default in the database, and it works as expected

[mindevis]

@Killyana so what all the same npcsflag should be?

[Seyden]

The code that does that is here.. but honestly.. you have to test on retail how it should be.. thats the only thing we can do to test if the issue is valid and if we have to do smth about it.

void Player::SendPreparedQuest(WorldObject* source)
{
    QuestMenu& questMenu = PlayerTalkClass->GetQuestMenu();
    if (questMenu.Empty())
        return;

    // single element case
    if (questMenu.GetMenuItemCount() == 1)
    {
        QuestMenuItem const& qmi0 = questMenu.GetItem(0);
        uint32 questId = qmi0.QuestId;

        // Auto open
        if (Quest const* quest = sObjectMgr->GetQuestTemplate(questId))
        {
            if (qmi0.QuestIcon == 4)
            {
                PlayerTalkClass->SendQuestGiverRequestItems(quest, source->GetGUID(), CanRewardQuest(quest, false), true);
                return;
            }
            // Send completable on repeatable and autoCompletable quest if player don't have quest
            /// @todo verify if check for !quest->IsDaily() is really correct (possibly not)
            else
            {
                if (!source->hasQuest(questId) && !source->hasInvolvedQuest(questId))
                {
                    PlayerTalkClass->SendCloseGossip();
                    return;
                }

                if (source->GetTypeId() != TYPEID_UNIT || source->GetUInt64Value(UNIT_NPC_FLAGS) & UNIT_NPC_FLAG_GOSSIP)
                {
                    if (quest->IsAutoAccept() && CanAddQuest(quest, true) && CanTakeQuest(quest, true))
                        AddQuestAndCheckCompletion(quest, source);

                    if (quest->IsAutoComplete() && quest->IsRepeatable() && !quest->IsDailyOrWeekly())
                        PlayerTalkClass->SendQuestGiverRequestItems(quest, source->GetGUID(), CanCompleteRepeatableQuest(quest), true);
                    else
                        PlayerTalkClass->SendQuestGiverQuestDetails(quest, source->GetGUID(), true, false);
                    return;
                }
            }
        }
    }

    PlayerTalkClass->SendQuestGiverQuestListMessage(source);
}

[offl]

Fixed by db6eb694656c58a817a965e2f5c85874e9c92d12, @matanshukry?

[matanshukry]

@offl nope; that commit push quests automatically without any interaction with npcs.

Edit: made a new PR to fix this.