Full Version : Stopping a player getting a quest again
xmlspawner >>Q&A >>Stopping a player getting a quest again
<< Prev | Next >>
BH_- 09-13-2007
Ive mostly got what I want working fine.. just having a little trouble with the last part.
What I am trying to do is have an NPC with xmldialog on it that you speak to to get quests... for example you say "quest" and if you dont have the first questbook on you... or the questattachment it will open the gump.. If you do have the book or attachment on you there is another 'quest' keyword line that checks that you have the first quest attachment on you and offers you the follow up.
Ive gotten the check working in the conditional field to see if they have the questholder on them using "~GETONCARRIED,The Hungry Wolves,questholder,visible=true" but im stuck on checking for the attachment as well.. i tried using..
"~GETONCARRIED,The Hungry Wolves,questholder,visible=true | ~GETONTRIGMOB,[ATTACHMENT,XmlQuestAttachment,The Hungry Wolves]"
But the gump still pops up even when they've done the quest providing they dont already have another questholder on them.
Cheers.
ArteGordon- 09-14-2007
you need to actually test for a property value here
~GETONTRIGMOB,[ATTACHMENT,XmlQuestAttachment,The Hungry Wolves]
just like you did here
~GETONCARRIED,The Hungry Wolves,questholder,visible=true
A good one for attachments is to test for the Deleted property, which will always be false if the attachment actually exists, like
~GETONTRIGMOB,[ATTACHMENT,XmlQuestAttachment,The Hungry Wolves,deleted]=false
from xmlspawner2.txt

QUOTE
- modified the syntax for referencing attachments using the GET series of keywords. Whereever a property would normally be specified for those keywords, the new property keyword [ATTACHMENT,type,name,property] can be used. For example, to read the value property on an xmlvalue attachment with the name XS on a triggering mob you would specify "GETONTRIGMOB,[ATTACHMENT,xmlvalue,XS,value]".

BH_- 09-14-2007
Thanks, I accually worked out what I was doing wrong just before by testing the name property against the name of the questholder... Im assuming it doesnt really matter which way I do it?
Also realised I kept using or instead of and which caused me some problems, I always do that
Thanks again, no doubt ill be back on here within the next few days/hours/minutes with another issue as I try to learn to do more and more complicated things heh.
ArteGordon- 09-14-2007

QUOTE (BH_ @ September 14, 2007 06:14 am)
Thanks, I accually worked out what I was doing wrong just before by testing the name property against the name of the questholder... Im assuming it doesnt really matter which way I do it? Also realised I kept using or instead of and which caused me some problems, I always do that
Thanks again, no doubt ill be back on here within the next few days/hours/minutes with another issue as I try to learn to do more and more complicated things heh.

yep, testing the name is fine.
BH_- 09-14-2007
Im having some trouble getting the SETONTHIS/doreset/true to work...
I was having a problem with gumps timing out before being able to read them all by having my ResetTimer set too low.. so you would read through the gump and by the time you picked your reponse it did nothing.
So ive been trying to work out how to make it reset by putting "SETONTHIS/doreset/true" in the actionfield of the last part of each conversation branch so I can set the resettime back to 1 minute.. without people having to wait forever between using the different parts.
Hope that makes sense.. Anyway it doesnt appear to work, still have to wait for the 1 minute timeout before speaking to the npc again.
Any ideas?
ArteGordon- 09-15-2007
In an XmlDialog action, SETONTHIS is actually referring to the object that the xmldialog is attached to.
Which is how you can do things like this

QUOTE
Or used in the Action field on an XmlDialog it could be used to make an npc bow, like SETONTHIS/ANIMATE,32,5,1,true,false,0

It just happens to also allow you to access xmldialog properties when the dialog is attached to an xmlquestnpc because those xmldialog properties like DoReset are explicitly mirrored on xmlquestnpcs.
So when you set it on the xmlquestnpc, it also gets set on the dialog, but that is a special feature of xmlquestnpcs.
I'm guessing that you have the XmlDialog attached to an item, or a regular npc instead. If you try do this when the dialog is attached to something like that, then it just tries to set the DoReset property on that object, and that does nothing.
To explicity refer to the XmlDialog attachment on the object use this syntax

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.

So for your Action, use something like
SETONTHIS/ATTACHMENT,xmldialog,,doreset/true
where the type is xmldialog, the name is empty, and the property you are referring to is doreset.
I am planning on adding support for individual entry reset times instead of just having the global reset time. That would allow you to specify more time for entries like gumps where they have a lot of reading, and less time for entries like end-of-conversations.
I may also add an option to allow it autoreset when the triggering player moves out of range so that if a player prematurely ends a conversation it can quickly reset.
I agree that having to wait for dialogs to reset can be annoying.
BH_- 09-15-2007
aha, yes its attached to a normal npc.. I dont know why I assumed since it was called from within the dialog that it would just know I meant which one to reset cheers.
Its not so much that annoying waiting for it to reset as players not understanding how the system works.. and not understanding why the npc suddenly seems to be ignoring them, an individual reset would be handy but its not a big deal imo since you can just make sure to reset it at the end of the branch.
The more I play around with this system the more I love it, to think ive been using xmlspawner for so long without even playing around with these options.
Another question I had was, is there anything wrong with setting an objective just to a line of text instead of an accual KILL/COLLECT/etc objective.. then using a spawner or another dialog to set the completed prop to true? Could this create any problems or is it just a line of text?
Sorry for all the questions, just really getting into learning how to use this system and its features and dont want to develop bad technique that could cause me problems down the road.
ArteGordon- 09-15-2007

QUOTE (BH_ @ September 15, 2007 06:54 am)
Another question I had was, is there anything wrong with setting an objective just to a line of text instead of an accual KILL/COLLECT/etc objective.. then using a spawner or another dialog to set the completed prop to true? Could this create any problems or is it just a line of text?

no problem at all. You can use any text you want and set up your own custom objectives just the way you described.
There are several sample quests in xmlextras that do exactly that.
For "go-visit-location" type objectives, at the moment that is actually the only way to do it.
BH_- 09-15-2007
Me again
I think I know how to do this but not entirely sure what is the best way to go about it...
You get the quest from an NPC to go pick up a sheep and bring it back, it creates a
questholder with 2 objectives.
You goto the other npc and he triggers a spawner to create the sheep and set its controlmaster to the player and the questbook completed1 to true. He also attaches a seperate xmlvalue attachment to the player and checks for it to make sure the player cant just keep dropping the book, grabbing a new one and spawning unlimited sheep.
I have gotten up to here and it seems to be working properly..
Im having trouble finishing this off though, what I think would be the best way to do it would have another spawner on the ground near the npc you need to return to that checks if a player enters its proximity carrying the book that has completed2 false.
Then it finds the sheep if they have one, deletes it, sets the property to true and sends them the completed msg gump.
Im unsure how to setup those kind of checks in a spawner and make sure its deleting the correct persons sheep, altering the correct questholder etc.
ArteGordon- 09-16-2007
Here was something similar
http://xmlspawner.15.forumer.com/index.php...&hl=getonnearby
So you would use something like this to check for a nearby tamed animal controlled by the triggering player
GETONNEARBY,3,*,sheep,controlmaster.serial={GETONTRIGMOB,serial}
from xmlspawner2.txt

QUOTE
- added the 'GETONNEARBY,range,name[,type][,searchcontainers],property' keyword that can be used to get or test properties on nearby items or mobiles. This can be used in property assignments or property tests. If more than one of the specified object is found, it will only return the value from one.
For example, to test to see if someone has placed the longsword named "Grizzleblag" on the ground near the spawner you could use a condition test like
GETONNEARBY,1,Grizzleblag,longsword,visible=true
Or you could get the size of a pile of gold in a nearby container with
SENDMSG/{GETONNEARBY,1,,gold,true,amount} gold pieces are in the container

You could use it in a #CONDITION keyword on a spawner entry like this
#CONDITION,GETONNEARBY,3,*,sheep,controlmaster.serial={GETONTRIGMOB,serial} ; SENDMSG/Thank you for returning the sheep
from xmlspawner2.txt

QUOTE
- added the "#CONDITION,proptest" spawn control keyword that allows individual entries to be made conditional on the specified property test. When combined with the new FastestPlayerSpeed and MovingPlayerCount properties, you can make spawn entries that will depend on the speed and number of nearby players with entries like
#CONDITION,movingplayercount<2 ; orc
which would only spawn the orc if fewer than 2 players were moving nearby.
#CONDITION,fastestplayerspeed>5 ; #PLAYER,3 ; orc
Which would only spawn the orcs if some player was moving faster than 5 tiles per second and would additionally have the orcs placed within 3 tiles of the triggering player when they are spawned.
You can use the same kind of condition tests that can be used anywhere else, such as compound tests or tests for properties on carried items, or triggering players, etc. For example,
#CONDITION,GETONTRIGMOB,skills.magery.value>100 ; lichlord
would only spawn the lichlord if the triggering player had magery greater than 100.

You could also use it in an IF test in a sequential spawner like this
subgroup 1: IF/GETONNEARBY,3,*,sheep,controlmaster.serial={GETONTRIGMOB,serial}/20
subgroup 1: GOTO/1
subgroup 20: SENDMSG/Thank you for returning the sheep
subgroup 20: SETONCARRIED,sheep quest name,questholder/completed2/true
which is useful if you have many different entries that you want to spawn once the condition is met.
Note that if there are other sheep nearby that arent owned by the player, this test might fail since it will just check the first sheep that it finds within 3 tiles.
To delete the sheep you could do something similar using SETONNEARBY
from xmlspawner2.txt

QUOTE
- added a property test option to the SETONNEARBY keyword that allows you to restrict the objects selected (thanks to Steelcap for the suggestion). The new syntax is SETONNEARBY,range,name[,type][,searchcontainers][,proptest]/prop/value/prop/value...
So, for example, to set the hue of all nearby creatures with hitpoints of less than 100 to blue you could use something like
SETONNEARBY,10,*,basecreature,false,hits<100/hue/500

so something like
SETONNEARBY,10,*,sheep,false,controlmaster.serial={GETONTRIGMOB,serial}/DELETE
which should delete all of the player's tamed sheep within 10 tiles. Note that unlike GETONNEARBY, SETONNEARBY will operate on all of the sheep and only those owned by the player.
BH_- 09-16-2007
Thanks for that, It seems to be working perfectly.
I set the sheep creating spawner to rename it to "a magnificent sheep" and the deleting spawner to check for that name so hopefully if theres a normal one nearby it wont interfere with it since a player cant rename with an extra word in there like that.
It all works but when I open the spawner again it shows one of the red error messages down the bottom that says "GETONNEARBY,5,a magnificent sheep,sheep,controlmaster.serial :" which is odd cos its working fine.
ArteGordon- 09-17-2007
It will complain like that when someone triggers and it cant find the sheep. I wouldnt worry about it.