Full Version : Quest NPC Checks
xmlspawner >>Q&A >>Quest NPC Checks


<< Prev | Next >>

Lord Hog Fred- 12-11-2006
Ok I got a couple of checks I want to do on a Quest NPC.
First is to have a GETONCARRIED check so that when the player approaches the NPC with the completed quest book they activate the reward section (Gump and Give items).
The second is to check for an attachment that will stop the player from recieving quests from that NPC for the time taken for the attachment to decay (the NPC is giving multiple quests so NextRepeatable wouldn't work). Also if possible is there a way of displaying text that says next quest available in *Attachment Decay Time*

Thanks smile.gif,


Vladimir- 12-12-2006
Ok this is how I would setup an NPC like that...

All of the entries I would set to "DependsOn" -2. Except for the reward entry which would depend on -1.

For the Condition field of the reward entry, you would have

GETONCARRIED,nameofquestbook,questholder,iscompleted=true

In the notriggeroncarried field right at the top of the Gump i put the name of the quest book, aswell as the attachment like so

Name of the quest | ATTACHMENT,name of the quest,XmlQuestAttachment

This means that the NPC will not give the player 2 of the same quest books, and will not let the player do the quest again if he has the attachment

Otherwise you could add the quest attachment into the Condition field if you only want it to apply to that entry like so:

GETONTRIGMOB,[ATTACHMENT,XmlQuestAttachment,name of quest,visible]=false

and i'm not too sure about displaying the NextRepeatable thing tongue.gif

Lord Hog Fred- 12-12-2006
Cool cheers mate that helped smile.gif

Lord Hog Fred- 12-22-2006
Ok, well I thoguht it had helped tongue.gif

It seems like when I put the attachment check into the condition window the NPC just ignores anything I say to him.

ArteGordon- 12-22-2006
what is the actual Condition string that you used?
Often the problem is a matter of misspelling names (they have to match exactly with same spaces, capitalization, etc).

Lord Hog Fred- 12-22-2006
Im using my own XmlData attachment as it makes it easier when adding more quests to use a single decaying attachment.
GETONTRIGMOB,[ATTACHMENT,XmlData,QuestTaken,visible]=true
The keyword was hello (same as for starting the quest). This should make the NPC say that he hasn't got any jobs and the char should come back later.

I then set the condition on the quest giving entries to
GETONTRIGMOB,[ATTACHMENT,XmlData,QuestTaken,visible]=false
Again the keyword is hello and would normally give a quest but in theory I thoguht should ignore these entries and use the previous one instead.

ArteGordon- 12-22-2006
ah, ok. The problem is that the following test is never going to be true

GETONTRIGMOB,[ATTACHMENT,XmlData,QuestTaken,visible]=false

what you want to do is to use the inverse operator ~ like this instead

~GETONTRIGMOB,[ATTACHMENT,XmlData,QuestTaken,visible]=true

The issue is that if the QuestTaken attachment doesnt exist, then any test for properties will fail and return false.

So what you do is to use this test

GETONTRIGMOB,[ATTACHMENT,XmlData,QuestTaken,visible]=true

which will be true if they have the QuestTaken attachment, and will be false if it doesnt exist.
And then add the ~ operator which will flip true/false so it will return false if they have the attachment, and true if they dont.

Lord Hog Fred- 12-22-2006
Hmm, for some reason this doesn't seem to be working either unsure.gif
I put the new conditions into the entries and it doen't seem to have any effect, the quests are still given as normal even if the attachment is present.

ArteGordon- 12-22-2006
sorry, I didnt notice that you were checking the 'visible' property on the XmlData attachments. Attachments dont have that property. It works when checking for questholders because they are items.

You can check other things, like the name

GETONTRIGMOB,[ATTACHMENT,XmlData,QuestTaken,name]="QuestTaken"

or the Deleted property is a good one

GETONTRIGMOB,[ATTACHMENT,XmlData,QuestTaken,deleted]=false

Lord Hog Fred- 12-22-2006
Ah brilliant, that works perfectly.
Just having trouble attaching the QuestTaken attachment to the player when the quest is given.

ArteGordon- 12-22-2006
how are you setting your Action?

SETONTRIGMOB/ATTACH/XmlData,QuestTaken


should do it.

Or if you want it to expire in 24 hours

SETONTRIGMOB/ATTACH/XmlData,QuestTaken,,1440

Lord Hog Fred- 12-22-2006
Ah ok, I wasn't using the SETONTRIGMOB

Lord Hog Fred- 12-22-2006
Fantastic, as always Arte you've provided amazing support and help on issues I've had.
Thanks a lot and have a good Christmas smile.gif.

DreadfullyDespized- 03-30-2009
How would one remove the xmlattachment/xmldata from a player?

Lichtblitz- 03-30-2009
Searching for "delete attachment":

http://xmlspawner.15.forumer.com/index.php...lete+attachment

QUOTE (ArteGordon @ August 09, 2006 01:00 pm)
you can do this

SETONTRIGMOB/ATTACHMENT,XmlQuestAttachment,Etting Trouble,dodelete/true

from xmlspawner2.txt

QUOTE

- added the DoDelete property to attachments that allows spawners to delete attachments by setting this property to true. For example, to delete the the xmlvalue attachment with the name XS on a triggering mob you would specify "SETONTRIGMOB/ATTACHMENT,xmlvalue,XS,dodelete/true" (See attachtest3.xml for examples). 


Also notice that the order of the name and type arguments for the ATTACHMENT keyword are reversed from the order used in the TriggerOnCarried strings.

QUOTE

- the SET series of keywords (this includes SET, SETONMOB, SETONTRIGMOB, SETONCARRIED, SETONSPAWN) now supports assigning properties on attachments.  Whereever a property would normally be specified for those keywords, the new property keyword ATTACHMENT,type,name,property can be used.  For example, to set the value property to 34 on an xmlvalue attachment with the name XS on a triggering mob you would specify "SETONTRIGMOB/ATTACHMENT,xmlvalue,XS,value/34" (See attachtest3.xml for examples).
The attachment properties can basically be treated as extensions of the target object's properties.