Trinitycore: Core/Quest: available quests disappear after logout and login

[IlPicasso]

Description:

Starting Quest dissapear (Only tested on starting quests)

Current behaviour:

It doesn't seems be to something regarding "Initial Quests" but quests dissapear on log out and log in

They come back when TrinityCore is Restarted

Tested with clean branch, clean database and the same happens, there is a video , well two in fact, http://f.cgm.rs/2017-07-09_09-43-47.mp4 and http://f.cgm.rs/2017-07-09_09-44-16.mp4

Expected behaviour:

That the NPC is still there and that you can interact with him when you log back

Steps to reproduce the problem:

1. Create Character
2. Log in, see that the NPC that gives you the starter quest is there with the ! in the head
3. Log out
4. Log in again, the ! is not there anymore and you can't interact with him
5. Restart Trinity Core
6. Login to the server, you can interact now
7. Repeat step 3 and see that it happens again

Branch(es):

3.3.5a

TC rev. hash/commit:

TrinityCore rev. ed241a2fd6c8 2017-07-09 13:58:59 +0200 (3.3.5 branch) (Unix, Release, Static) (worldserver-daemon) ready...

TDB version: 335.63

Operating system: UBUNTU 16.04 x64

[IlPicasso]

note that, I tried this on Mangos and it didn't happened

[Killyana]

If you .die and .resp the npc you can take the quest.
Also if the npc is unloaded from the client, if you go back, you can get the quest again.

[IlPicasso]

I get that, howewer that is not a normal behaviour right? @Killyana

[Killyana]

Ofc not.

[IlPicasso]

This is a reference of
https://github.com/TrinityCore/TrinityCore/issues/20007

[Treeston]

Can reproduce on ed241a2

[Treeston]

Simple workaround fix:
Add a call to SendQuestGiverStatusMultiple to Player::SendInitialPacketsAfterAddToMap.

Further details:
However, this didn't satisfy me, so I dug a tad deeper, into WorldSession::HandleQuestgiverStatusQueryOpcode. Here's where things get interesting.

When you first log into a character, the client dutifully sends CMSG_QUESTGIVER_STATUS_QUERY for every creature it loads, causing the server to respond with SMSG_QUESTGIVER_STATUS, syncing the quest status (quest indicator display).

However, if you then log out to character select and back into the world, the client no longer sends CMSG_QUESTGIVER_STATUS_QUERY. This means the server never sends the quest giver status data, causing the exclamation mark to not appear.

This brings up a few questions (@Shauren I'd appreciate if you could dig into disassembly):

• Are we doing something wrong that's causing this opcode to not be sent? Is there some client cache we should clear on logout?
• If not, how does Blizzard re-sync their quest giver states. Is SMSG_QUESTGIVER_STATUS_MULTIPLE on map load a valid solution?

[ghost]

TrinityCore rev. ed241a2fd6c8 2017-07-09 13:58:59 +0200 (3.3.5 branch) (Win64, Release, Static)
Using World DB: TDB 335.63 + updates up to and including 2017_07_08_00_world.sql

Confirmed. I get this issue with quests where I produce items from professions and have stored several items (like skinned items for Leatherworking) and drop them into my bags from bank, but the quest giver will not complete the quest before I restart the servers (and possibly delete the game client Cache folder). If I have got 2 or more hand-in quests to complete, only the first quest can be completed+rewarded, because the following quests can not continue from the progression gossip (the [Continue] button is grey to me). The detail is that the game client (or message from server) shows the yellow on-screen objective completion numbers, but only for one of the quests (likely the first in a row).

[IlPicasso]

For the workaround fix

What line needs to be added to Player::SendInitialPacketsAfterAddToMap?

[Treeston]

SendQuestGiverStatusMultiple()

as the last call should work, or anywhere in the sequence really since it's just a hackfix

[IlPicasso]

Tested and working !

Thanks , waiting for the official fix

[Shauren]

I will check what makes the client send CMSG_QUESTGIVER_STATUS_QUERY later

[IlPicasso]

Why not providing the hotfix in the source directly until the real solution is found?

[Treeston]

Because we don't merge hacks. Anyone can easily merge the fix themselves if this is a huge critical issue to them (it really isn't).

[Shauren]

I researched this now. What the client does is semd CMSG_QUESTGIVER_STATUS_QUERY when receiving new CreateObject block but there is a catch. It will not do this if the object is freshly destroyed (this is 100% the same issue as our old good gameobject move command not updating position clientside). Objects are purged from client store 1 minute after SMSG_DESTROY_OBJECT or OutOfRange block.

Now what blizz does - simply send SMSG_QUESTGIVER_STATUS_MULTIPLE, right after spell modifiers (without any CMSG)

[Treeston]

:+1:, will PR