[Idea] Store guid for quests objectives

[Siegels]

Hello,

I had an idea: Currently, players can validate a quest by speaking several times to the same creature or several times using a spell on a single creature or object (eg a player can behead several times a single humanoid ).

Why not create a table in which we store the GUID of creatures / objects on which targets have been validated for unfinished quests ?

A player has quest: Speak to 5 guards.

Guards have ID : 15 and GUID: 21 22 23 24 25

Player speaks to a guard: his guid is saved to character_questobjectives (idea) and +1 to the quest objective

Player speaks to another guard: same

Player speaks to the first guard: the guid is already in character_questobjectives : no add and no +1 to objective

at the end, when quest is finished and validated, occurs in character_questobjectives have to be deleted

It's just an idea but I think it would have to solve many problems in this regard.

On this, sorry for my broken English and I expect reactions =)

Siegels

[przemratajczak]

yes, i proposed similar idea at SD2 ircchannel but noone picked up conversation

[Patman128]

I'm sorry, but I don't quite follow. Can you give an actual example of a quest that has this problem?

[Siegels]

Hum ... eg in Zul'Drak, i had this problem with quest http://www.wowhead.com/quest=12509

[Unkle Nuke]

I think he's referring to quests where the objective is to gather a certain number of an item, such as stacks of lumber for the quest at Eastvale Logging Camp, or to kill a given number of a certain creature, i.e.: 12 Murloc Fins for the Murloc Bounty quest given by the guard at the bridge leading to Eastvale, in Elwynn Forest.

As it stands, you can simply stand next to the spawn point for a stack of lumber, wait for it to respawn, pick it up as many times as you wish and, each time, it counts toward your objective until you have fulfilled the requirements. Same goes for creature kills. You can kill the same spawn again and again to get credit for the quest objective.

I believe his idea would be for each item gathered or creature killed to have a unique identifier ( GUID ) that is stored in a table for that quest to prevent you from "camping" a spawn point and forcing the player to move on to the next target if they wish to gain credit for completion. Perhaps achieving this by preventing a gathered item or creature part/loot from respawning at the coordinates of the GUID for the item/creature part/loot.

[Siegels]

This is not for camping: not for quests in which the objective is to kill a creature.

No, this is for objectives as "speaking to X guards" but not X times to the same or "burn X houses" but not X times the same house.

[Diablox]

Good example would be http://www.wowhead.com/quest=12733 where you need to duel 5 npc and you can do that 5 times with one npc but if you use this then you need to duel 5 difrent npc.

[Siegels]

Yes, that's a good exemple =D Thanks ^^

[Unkle Nuke]

Six one way, half a dozen the other. The underlying theory is the same.

[Siegels]

Theory, yep.

On off, you cannot validate a quest by speaking 5 times the same npc but only if you speak to 5 differents npcs in my exemple

[Patman128]

I think he's referring to quests where the objective is to gather a certain number of an item, such as stacks of lumber for the quest at Eastvale Logging Camp, or to kill a given number of a certain creature, i.e.: 12 Murloc Fins for the Murloc Bounty quest given by the guard at the bridge leading to Eastvale, in Elwynn Forest.

As it stands, you can simply stand next to the spawn point for a stack of lumber, wait for it to respawn, pick it up as many times as you wish and, each time, it counts toward your objective until you have fulfilled the requirements. Same goes for creature kills. You can kill the same spawn again and again to get credit for the quest objective.

I believe his idea would be for each item gathered or creature killed to have a unique identifier ( GUID ) that is stored in a table for that quest to prevent you from "camping" a spawn point and forcing the player to move on to the next target if they wish to gain credit for completion. Perhaps achieving this by preventing a gathered item or creature part/loot from respawning at the coordinates of the GUID for the item/creature part/loot.

This is not official-like behaviour. On official you can get respawns all you want; they have respawn timers and most likely pool behaviour anyway.

As for the two quests linked as examples, they both require and could more easily be done with scripts, rather than add completely new and wasteful behaviour into core which 99.9% of quests do not need.

[przemratajczak]

i think you did not understood intention. there ARE quests and quite much of them that requires such a support. lets say we've got npcs corpse and you have to stake a snapshot with Q item, those corpses are not supposed to despawn after spell cast (it was even disussed at udb irc channel long time ago) How will you solve this problem at ScriptedAI level? it would be as natural and generic solution as sending loot recepient.

[Gotisch]

i think right way to implement this is some flag on creature that forbids usage by player, no? best would be to get some packet log showing what happens when one guard is talked to. I think if no flag or such is set then we should think about saving guids

[patrik774]

As Gotisch said, it can be done by flag. It's needed for more than two quests. For example: http://www.wowhead.com/quest=5441 [Lazy Peons] - now you can wait for cooldown and wake the same peon... This feature can be good. Just get it to work - flag will be nice for DB handling...

[Patman128]

As Gotisch said, it can be done by flag. It's needed for more than two quests. For example: http://www.wowhead.com/quest=5441 [Lazy Peons] - now you can wait for cooldown and wake the same peon... This feature can be good. Just get it to work - flag will be nice for DB handling...

From reading the comments of that quest, it would seem that you can just wait for them to fall asleep and them hit them again, so again this would not be official-like behaviour.

[patrik774]

/agree, this isn't good example but,

on offy they are working and because they are lazy, they fall asleep. But with today's Databases/Scriptdev2 they only sleep. That's what I'm talking about. I know this isn't core problem, but while it's not done by scriptdev, with this idea - simply add flag to NPC and bye to all "one NPC campers"

[maly32167]

Actually blizzard handles many (dunno if all ?) of them with auras

http://www.wowhead.com/spell=46073

http://www.wowhead.com/spell=72884

and many more

These are dummy auras that should not allow to get credit again from mob for some duration

[Patman128]

/agree, this isn't good example but,

on offy they are working and because they are lazy, they fall asleep. But with today's Databases/Scriptdev2 they only sleep. That's what I'm talking about. I know this isn't core problem, but while it's not done by scriptdev, with this idea - simply add flag to NPC and bye to all "one NPC campers"

No, this is bad idea. Better fix something properly than do hack fix and ignore problem.

[Unkle Nuke]

While some admins might like this idea as being more "hardcore" than retail, I see Patman's point. Why does the core need modifying to support this behavior when proper scripting could achieve the same effect?

[Diablox]

While some admins might like this idea as being more "hardcore" than retail, I see Patman's point. Why does the core need modifying to support this behavior when proper scripting could achieve the same effect?

There is a third way. I for example do not care if players interact only with one NPC. Only thing i care about is the quest itself working as it should (aside from the fact that you can talk to one NPC instead of 5 and still complete the quest).

[VladimirMangos]

In general i think creatures like talk or use-at for quest objective just have some internal cooldown timer like GO, some form its in this time also change AI work or sometime model/etc