Need help on a turn in
 

I'm hoping I can get some insight on why this script is not working correctly. I ran in through a perl command line with no syntax problems.

At this point the turn-in works as far as it goes. That is, when I give 4 bone chips to the npc, they are accepted, and I receive the right amount of exp, cash, and faction. However, when I test it with other items--or with fewer than 4 of the right items--those items are accepted as well, and I still receive exp, cash and faction. Because all items are accepted the script never gets to the return_items line, so I cannot tell yet whether that part is working. I've looked at several examples on these forums of the check_handin line, and mine seems to be right. But the variables are being ignored. Any clue why? Thanks!

if(plugin::check_handin{\%itemcount,13073 => 4})

swap curly brakets for parentesis here


if(plugin::check_handin(\%itemcount,13073 => 4))

That did the trick :) Thanks!

I had actually (briefly) considered that possibility, but I had seen
examples from others using the curly brackets and thought it must be a valid usage.

np
the bracket prabobly work in some cases, but parentesis work always

Okay, here's another one, then:

Each time I give the item to the npc, he gives it back and defaults to the return_item text. I have triple-checked the item #, and it is correct. I have tried a different operator (< 2 instead of == 1) with the same result. I have tried placing the initial quest::say before all the reward lines, with the same result. I have run the code through a Perl cmd line and it reported no syntax problems.

Thoughts?

Try the following. You forgot to put in an EVENT_SAY section:

Thanks Trevius. I made the change, but he's still returning the item. I'm just learning Perl, so I appreciate your patience with this. Fyi, I already have one EVENT_SAY section that comes before the EVENT_ITEM section (yours would be a second one that comes after). I didn't include it in the first post because it was working fine on it's own. The only section I'm having trouble with is the turn in. Any other suggestions?

You only want to have 1 EVENT_SAY in your quest. Put all of the ones in the script I posted into your pre-existing one and remove the one I put in.

You have to keep certain things like that completely separated for a reason, otherwise they will get messed up as you are now seeing.

Anytime you have an "if" statement, whatever it is if'ing on is what section it should go in. So, if's on text should go in EVENT_SAY, and if's on turn ins should go in EVENT_ITEM, and if's on timers should go in EVENT_TIMER, etc.

Okay, here's the entire script, annotated by me. Maybe this will help.

I removed the final EVENT_SAY section and tested the script without it, and the npc still returns the item. It makes no sense to me. He recognizes the item in the hail during the first section ((hasitem), but doesn't seem to recognize it when I actually give it to him.

i think you have an icorect follow up of elses and ifs in first part

there can only be ONE else inside a single if and i belvie you have incorect open closed brakets

I made your change, Chaos, and (oddly enough) it made no difference in the quest (not sure why--you'd think placement of brackets would matter). I'm making live changes directly to the quest/zone folder, and I "reloadquest" after each change. As I mentioned above, that part of the script has always worked fine. It fails only once it calls the EVENT_ITEM script.

Okay, I have been experimenting with this code, and got it to (semi-) work. I replaced:

sub EVENT_ITEM {
if(plugin::check_handin(\%itemcount,13732 == 1))
{

with . . .

sub EVENT_ITEM {
if($item,13732)
{

I though, as long as I have only one item to turn in, maybe I won't need the count variable. I have no idea whether this is "sound" from a scripting standpoint, but the npc now takes the item and rewards me with the right exp, plat and faction. But now he'll also take just any item and give the same reward. Any way to modify this so only that item is recognized?

oh yeah make sure than you only have ONE EVENT_SAY section as Trevies pointed out

and to be sure
you need to place a closing curcly braket when I said
and remove one where i said

try this.
replace

if(plugin::check_handin(\%itemcount,13732 == 1))

with

if(plugin::check_handin(\%itemcount,13732 => 1))

Yay! That did it! It's now accepting only item 13732. Since that item is lore, the ">" operator becomes moot. (But why doesn't == work?)

Thanks for all the help. Next up; mob spawns triggered by the same turn-in. Going to try my hand at solo-ing the quest:spawn feature, but I may be back. Thanks again.

Was about to paste this when you apparently resolved your issues. Your quest still had the brackets in the wrong lines for your hasitem check and text responses to work properly. I adjusted that, I also did the => fix, and I removed all of the ;s and --s in your quest::say's, because you have to be careful when using certain characters in there, and I haven't personally used either of those in that way. So, I thought it might have something to do with your issue, but apparently not.

Here is the final quest after my edits:

Notice that I also changed the format on how the quest is written so that it is easier to read. It is a good idea to write in a way similar to that so you can find mistakes quicker.

And, whenever I am working on a quest, I remove 1 section at a time until I narrow it down to a certain section and then I remove a line at a time until it works. Then add them in again until it breaks and fix the line that is causing the break to happen.

I belive its not the operator you thing it is.
rather than "greater or equal" it reads something like "fetch from item slot"
- basilcy its not an operator at all (from my logical understanding)

regading mob spawns. here is an easy sample for you to work with pulled from one of my quests


Enjoy =)

Thanks Trevius. I replaced my current version with yours just to be on the safe side, so your work wasn't in vain. It also helped me to see a better way to format. Thanks again.

That's good to know. I just assumed it was a "greater than or equal to" operator, but could not figure out why the = comes before the >. That explains it.

Very helpful. I will use this as a template. Thanks. What's the logic behind using quest::spawn2 rather than quest::spawn?

Chaos, I modified your spawn script and everything works great. I now have the first part of a larger npc war script finished. Just seeing all those guards spawn to reinforce the kingdom when I turned in the item to the king brought a tear to my eye :wink:

Thanks again for all the help!

np 8-)
.

Okay, one thing I didn't expect was for the newly spawned mobs to disappear when I log off. If I want them to remain spawned until they are killed by a player raid or an npc war, is there a way to do that? The goal of the npc spawn is to provide reinforcements against members of another faction coming in and taking over the city in an attempt to retake the item I just turned in to the king. If they despawn when I log from my account, then the quest is functionally useless to my storyline. I want to make it so that they remain there to guard the realm against players of a different faction who are looking for the item I just turned into the king. If another faction does come in, kills all the npcs (except for the king), loots a specified item from one of the named npcs, and turns it into to the king, the king then yields the item they came for (via another turn-in), and all his reinforcements despawn, never to spawn again until and unless someone else turns in the same item to him.

How do I make the spawns stay put? Would that be a quest::spawn rather than a quest::spawn2? Something else? Also, once I have them there, I want to have the second item turn-in trigger their despawn. Any ideas on this?

the server has no way to store any data about something what is not a part of default spawn DB

you may want to turn on the Persistant State rule in Variables section of the DB. but no garantee that server will record and reproduce CURRENT state for mosb that are not part of DB spawns

basicly if you looking for soemthing like a GM event where mobs become persistant, you want to actualy add them to regular spawn tables and turn then on and off as requred.

of course it would have to be done by hand, cuase there no conection betwen quest scripts and DB

NOTE: once Persistant State has been turned on ANY changes you do Db will auto crash the server untill Persistant State turned off.


As far as despawning goes, there is a comand quest::depop

basicly once item turned in to quest NPC, npc will need to send a SIGNAL code command to each npc you want to dispawn, and each of those npcs will execute depop comand

Actually, this works very well. I turned persistent state on, did the quest, did a #zsave (not sure if that matters, but I did it anyway), logged out, shut down world, came back in and the mobs were still there.
Thanks; I'll give this a try.

well its nice to know that Persistant State rule works like this .
Rememebr however - you will not be able to edit DB as long as it turned on.

I mean you can edit it, but then the server won't boot up cuase Persistant State requres for Db to remain IDENTICAL to what it was before server was shot down in order to restore it to exactly how it was

I once did that.. I spend 3 days trying to figure out why server is not booting up anymore =)

Odd. I have been able to make changes to the DB with this on. I changed the zone points in the zone_points table for a custom zone I have, and it works just fine.

well from what i know its not all parts of the DB its some parts which would have a direct impact of persistant data stored - like walking grid for a mob