Project 1999

Go Back   Project 1999 > Blue Community > Blue Trading Hub

Closed Thread
 
Thread Tools Display Modes
  #11  
Old 08-13-2010, 07:09 PM
Wenai Wenai is offline
VIP / Contributor

Wenai's Avatar

Join Date: Oct 2009
Location: Halifax, NS, Canada
Posts: 1,083
Send a message via MSN to Wenai
Default

Quote:
Originally Posted by guineapig [You must be logged in to view images. Log in or Register.]
It actually doesn't have anything to do with an MQ rule made by the server. It has more to do with the database not being able to handle MultiQuesting.

In other words It's an EQemu limitation.
Has nothing to do with database [You must be logged in to view images. Log in or Register.] just to give you guys an idea of how quests works. So I will write a generic quest script to show you what it looks like and how it works.

Quests are handled through PERL (.pl) files which are labelled via name or NPC ID#. When an event happen it will check it's PERL file to see if there is a reaction or event that should happen in response.

Code:
sub EVENT_SAY {
  if($text=~/Hail/i) {
    quest::say("Hail, traveler! You look as if you could use a [drink]!");
  }
  if($text=~/drink/i) {
    quest::say("Ahhhhh... You do need a drink! If you bring me a muffin I am sure I could spare you some of my milk!");
  }
}

sub EVENT_ITEM {
    if(plugin::check_handin(\%itemcount, 13014 => 1)) {
    quest::say("Ahhhh! Thank you so much for this delicious muffin! Have a bottle of this quenching milk!");
    quest::exp(9001);
    quest::ding();
    quest::summonitem(13087);
    }
}
So basically how this works is... Anything within EVENT_SAY is what determines how and NPC will react when you talk to it. If you say a /keyword/ then it will respond with the quest output specified within quotations after quest::say. The, i, after the /keyword/ does nothing other than make it so that it is not case sensitive.

Anything within EVENT_ITEM is how we determine how the NPC reacts when handed an ITEM(s). In this case he accepts item 13014 (muffin) in exchange for 13087 (milk).

quest::exp determines how much experience you gain from that turn-in.
quest::ding is the sound effect that you hear when you complete the quest.
quest::summonitem is the item reward that you see.

Now that you hopefully understand the basics of how the quest scripts work I can explain why MultiQuesting currently does not work.

When an NPC is handed an item(s) it does a check that if ALL conditions are met. If ALL conditions are not met.. then the quest is failed. The NPC does not flag itself as receiving an item for partial completion of the quest.

Would be be possible to have multiquesting? I believe so. I am no PERL expert by any means but I believe you could somehow set a flag for the NPC to show that part of the quest had been completed. This would result in having to re-script every quest that we have... which just isn't going to happen. [You must be logged in to view images. Log in or Register.]
  #12  
Old 08-13-2010, 07:10 PM
Noleafclover Noleafclover is offline
Sarnak


Join Date: May 2010
Posts: 295
Default

Quote:
Originally Posted by citizen1080 [You must be logged in to view images. Log in or Register.]
So MQing is stupid..but buying an item you yourself didn't camp isn't? I don't follow the logic =p

I better not catch you in EC sir !
The "No Drop" stamp shows you were at least there when it droppedand went out and played the game to get the item, instead of farming plat off endless seafuries or fools in EC.

Farming plat that way is fine, but the fact that that does not buy you everything is a plus to me.
__________________
Accersitus Mage
Ennui Monk
Vita mid 40s Cleric
  #13  
Old 08-13-2010, 07:18 PM
citizen1080 citizen1080 is offline
Planar Protector

citizen1080's Avatar

Join Date: Jun 2010
Location: Your Wallet
Posts: 2,980
Default

No argument here =) I just took his post as well if u didn't get it yourself then its stupid =p
  #14  
Old 08-13-2010, 08:27 PM
thxer thxer is offline
Aviak

thxer's Avatar

Join Date: Jun 2010
Location: Innoruuk
Posts: 58
Default

Wish more people knew this so they didn't do retarded shit like killing AC on their 50 bard.
__________________
-Halos
  #15  
Old 08-13-2010, 09:12 PM
Anaiyah Anaiyah is offline
Kobold

Anaiyah's Avatar

Join Date: May 2010
Posts: 103
Default

Quote:
Originally Posted by thxer [You must be logged in to view images. Log in or Register.]
Wish more people knew this so they didn't do retarded shit like killing AC on their 50 bard.
Lol because this is such a common event...
  #16  
Old 08-13-2010, 09:35 PM
mgellan mgellan is offline
Fire Giant

mgellan's Avatar

Join Date: Mar 2010
Location: Winnipeg Canada
Posts: 880
Default

Quote:
Originally Posted by Wenai [You must be logged in to view images. Log in or Register.]
Would be be possible to have multiquesting? I believe so. I am no PERL expert by any means but I believe you could somehow set a flag for the NPC to show that part of the quest had been completed. This would result in having to re-script every quest that we have... which just isn't going to happen. [You must be logged in to view images. Log in or Register.]
I was thinking we could just adjust plugin::check_handin to persist anything handed in, load in that along with anything else that had previously been handed in, so someone could hand something in (like, 3 honeycombs for Honey JumJum) which Kizzi would just eat like now, except when someone handed in 30 gp they would complete the quest and get the JumJum. It would only work with quests that don't return items handed in if they don't complete a quest but many don't (ie right now they eat the items) so they'd work - other critical ones could be modified, most we don't care about.

Alas, I've been learning PERL very slowly so some of the more esotheric code in the plugin::check_handin code still confuses me, but I'll get there and give it a go )

Regards,
Mg
__________________

OMNI Officer (Retired from EQ)
Check out my P99 Hunting Guide!
  #17  
Old 08-13-2010, 10:31 PM
Itchybottom Itchybottom is offline
Banned


Join Date: Jun 2010
Posts: 391
Default

Quote:
Originally Posted by Wenai [You must be logged in to view images. Log in or Register.]
Would be be possible to have multiquesting? I believe so. I am no PERL expert by any means but I believe you could somehow set a flag for the NPC to show that part of the quest had been completed. This would result in having to re-script every quest that we have... which just isn't going to happen. [You must be logged in to view images. Log in or Register.]
Incremented qglobal value wouldn't need to be in every PERLXS script you have, it'd just need to be in the ones that are verified multi-questable. It's actually quite trivial.
  #18  
Old 08-13-2010, 10:48 PM
keen keen is offline
Sarnak


Join Date: Apr 2010
Posts: 200
Default Hmm..

What if you only edited quests that contained multiple items and/or money, and at least one of the items had to be No-Drop?

The only reason we need MQ's are because at least one item is No-Drop.

That would probably eliminate thousands of quests.


Just a thought..
  #19  
Old 08-13-2010, 10:52 PM
Itchybottom Itchybottom is offline
Banned


Join Date: Jun 2010
Posts: 391
Default

Quote:
Originally Posted by keen [You must be logged in to view images. Log in or Register.]
What if you only edited quests that contained multiple items and/or money, and at least one of the items had to be No-Drop?

The only reason we need MQ's are because at least one item is No-Drop.

That would probably eliminate thousands of quests.


Just a thought..
I'd like to see the clusterfuck awk/grep shell script to even begin to identify those quests reliably!
Closed Thread


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 06:32 AM.


Everquest is a registered trademark of Daybreak Game Company LLC.
Project 1999 is not associated or affiliated in any way with Daybreak Game Company LLC.
Powered by vBulletin®
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.