Quest Share

[ccrs]

I open this issue to keep track on this still existing bug.

The other one is closed: #5881

Also there were two fixes: #7461 #9873
None of them solved this and @joschiwald recall them as hacks...

On 646fa3c I can reproduce these ones:

• Only players that are close to the player who is sharing the mission get the mission. The other ones are excluded
• In rare occasions the system gets fucked up and some players get the message of "X is busy right now" even standing next to the one who is sharing the quest. The only solution for this is relogging.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[2010phenix]

confirm

[ghost]

A couple of my friends using commit 058457d [3.3.5] have reported a related issue to me. It seems that shareable quest behaves like @Rushor wrote in #5881 (comment) . The quest gossip is received by the party member, but nothing happens when the receiver clicks [Accept], the quest does not get added to the user and the player sharing the quest does not get any confirmation.

The same also happens when attempting to share other shareable quests like the Rescue OOX-09/HL! (The Hinterlands), probably the same issue for sharing the other rescue quests as well. Is this problem related to this issue above, or is it separate from the distance issue, because my friends were close to each other and can't share quests. Could it be that the gossip action does not send opcodes to server or the return opcode does not reach the clients?

Does the sharing issue belong here, or should I open a new issue if I can confirm it on updated source?

[ghost]

3.3.5 core rev. hash: 8a7ba64 TDB: 335.58 + updates.
Update: Tested sharing quests between 2 players, orc + blood elf. It is completely OK to initiate a [Quest] [Share] and send the gossip to the other player in a different area, from Razor Hill in Kalimdor to Falconwing Square outside Silvermoon City in Eastern Kingdoms. So I am fairly certain that what @ccrs has written in his OP is no longer an issue, as long as the issue here is long-distance quest sharing.

The sharing issue I am get instead, is unrelated to distance. Neither the [Accept] button nor the [Decline] button works, you can only close the gossip window with the [X] in the top right corner.

Edit: after looking at the links in the OP, specifically #9873, I see that @joschiwald has commented "this "hack" was added to fix the quest sharing problems. look at: #5881 ". Looking at #5881, I find that point 2 and 3 match exactly the issues I get. Does this qualify for keeping issue #12304 (this issue) open, or should my confirmed issue be posted in a new issue?

[ccrs]

Its all the same @tkrokli

When i said that quest sharing didnt work if players are far away, i meant exactly what u have described.
Sharing "window" appears but Accept and Decline buttons dont work.

If the same thing is done with players standing near each other system seems to work, and quests can be shared.

Also I reported this

In rare occasions the system gets fucked up
and some players get the message of "X is busy right now"
even standing next to the one who is sharing the quest.
The only solution for this is relogging.

and still happens, usually in raid/group with several people trying to share the same quest.

210e45e

[ghost]

OK, thanks for the update, @ccrs . I think this may have something to do with the source code for sharing quests in general, but I don't know how to write any fix for it. I can only guess that it has something to do with QuestHandler.cpp, but I don't know enough about the gossip handling, or if the malfunctioning buttons and the $name is busy right now message is caused by other code, like opcodes or something else.

[ikir83]

Still happens

[ghost]

@ikir83 : add your core revision hash when confirming, so we know what source version you tested it on.
I confirmed this on TrinityCore rev. d74640a 2015-05-04 15:11:05 +0100 (3.3.5 branch) (Win64, Release)

[ikir83]

DB 335.58
rev 2b95a5f 2015-04-26

[ghost]

Anyone got a suggestion about which files to check for this bug? Suggestions are most welcome.
We should start looking at which parts of the core is interfering with the quest dialogue to make this issue.

[tcbhale]

No fix yet, still got the issue.

We've got Player A located in Durotar and Player B located in Orgrimmar (Or any other area or player race)

Player A tries to share quest and Player B gets Accept / Decline buttons but nothing happens when pressing them or only gets the Complete quest option, and nothing happens

Player A tries to share quest and Player B gets nothing up..

After Player A tries to share quest(and Player B got issue 1 or 2), Player B can no longer get any shareable quest until he relogs. And for Player A it will write in chat that Player B is busy.

I have tried sharing quest as admin to admin, and normal to normal and admin to normal user, nothing.

I have looked everywhere for a fix for this but can't find any. There are some old fixes wich i have read though to try n fix the issue my self but no luck there..

No mods on the server.

I have the newest 3.3.5 trinitycore rev which was updated not long ago.
TrinityCore rev. 5ac9fb9 2015-12-26 01:31:13 +0200 (master branch) (Unix, Release)
TDB 335.60

Thanks!

[ghost]

@tcbhale : your core is not a straight TrinityCore commit. You can see that from the fact that github does not find your core rev. hash in the TC repository, as well as you using the "master" branch name (no longer in use by TrinityCore since October/November 2014) instead of 3.3.5. The real TrinityCore 3.3.5 commits from 2015-12-26 were 812809a, b13c7f5 and 315123f (just to let you know).

[tcbhale]

Thanks for the reply, yes it's Eluna but in normal TrinityCore it doesn't work either. Couldn't find this issue posted anywhere else.

[ghost]

OK, fair enough. I hope we can start looking at this and see if something can be done to fix it, even if this issue is labeled as [Priority-Low]. Constructive suggestions are very welcome. 👷

[tcbhale]

That would be nice, I personally think this is a big issue and should be higher than [Priority-Low].

I do think it is somewhat connected to a bug in the core where the range doesn't function properly, like if you are too far away you can't share, when you are too far away u can't use the RAF summon. (Kinda ruins the summon function).

[ghost]

Interesting point. I wonder where that function hides in the source. Would be nice to look at it.

[ghost]

It may or may not be interesting to note that changing
(line 591 of questhandler)

receiver->PlayerTalkClass->SendQuestGiverQuestDetails(quest, sender->GetGUID(), true);

to

receiver->PlayerTalkClass->SendQuestGiverQuestDetails(quest, receiver->GetGUID(), true);

fixes the decline button doing nothing, and appears to stop the player is busy error from happening.
Tested across maps. Decline button now works, busy message bug no longer occurs, accept button closes the quest details window, but does not add quest to player's log.

[Shauren]

FFS stop changing that line! It absolutely must have the sender guid there - otherwise both client and server will think that receiver is sharing the quest (this must never be allowed under any circumstances - you could allow hackers to accept any quest out of thin air)

[ghost]

Calm down, it was just something I noticed while messing around with the code and thought it might be of interest to point out. It is good to know that it can cause other problems, but you could have worded it a little less harshly.

[ghost]

@lordwind68 : I know how it looks to you. He has just seen it too many times before to not react.
But are we getting anywhere with the problem? Will a solution involve more than QuestHandler ?
Edit: Would it be of any use to test Debug like Faq did in #5881 (comment) , or is that useless?