Project 1999 - Jboots Quest

Project 1999 (/forums/index.php)

- Blue Server Chat (/forums/forumdisplay.php?f=17)

- - Jboots Quest (/forums/showthread.php?t=5102)

Hi,

Can anyone confirm or deny that you can MQ Jboots?

Thanks,

deny

because MQ is not allowed here

GG

You can't MQ on P99.

yeah I was just told this, disregard or delete!

Thanks!

Quote:

Originally Posted by Virtuosos (Post 36789)

deny

because MQ is not allowed here

GG

you know he's talking about multiquesting right?

FAIL

MULTI QUESTING

Not so much not allowed but doesn't work. The database they use doesn't support it.

The database isn't the issue, it is the operation of the perl that handles quests. Time for a little perl 101 I think!

Code:

if (plugin::check_handin(\%itemcount, 10032 => 2, 10000 => 1)) {

                quest::say("Here is your prize - a lambent star ruby.");

                quest::summonitem(10117);

                quest::faction(320,5);

                quest::faction(291,-15);

        }

this is a standard turn in, lambent star ruby. It checks for all the items to be turned in at once. Now, it might be possible to enable chaining of quests, but it would require a rewrite of -every- quest in the game, which is several thousand. It would involve adding a global variable for each item turned in for the NPC and then cycling that variable out when the last item is turned in... This could also change writing a quest from probably 30 minutes to several hours.

None of us on the project were familiar enough with perl when we started, or the emulator in general to be able to see this possible caveat. But as a rule, the system just doesn't allow for quest chains out of the box. I've never tested this hypothesis either and I might not even work how I have it laid out in my mind and not work at all. Using the plugin is what allows for item returns on a bad turn in as well and would go away.

In essence it is a double edged sword and a Pandoras Box that I'm not sure we are capable of opening based on staffing levels & time requirements.

hire sony to do it

:o

Quote:

Originally Posted by Aeolwind (Post 36863)

It would involve adding a global variable for each item turned in for the NPC and then cycling that variable out when the last item is turned in... This could also change writing a quest from probably 30 minutes to several hours.

Just throwing out some ideas here, I totally understand what you're saying. Perhaps I'm being naive here - I'm not real familiar with perl. I'm just looking at this from possibly a different angle. Obviously, no offense is meant.

For an NPC in the database, store 4 "inventory" fields which each would contain an item number, an iterator (that counts to 4) and (if necessary) the id of the last character to do a handin.

When an item is handed in, add that item to the inventory# of the iterator, and iterate. If the iterator = 4, set it to 0. On each handin, check quest completion. If the quest is completed, summon the item, and delete the appropriate inventory items.

Additionally, I would think that you could do this in such a way as to keep the majority of your quest code. Possibly writing a simple perl script or find/replace, in conjunction with some external methods, would allow you to affect the majority of the quests to be MQable.

In your example:

Code:

if (plugin::check_handin(\%itemcount, 10032 => 2, 10000 => 1)) {

                quest::say("Here is your prize - a lambent star ruby.");

                quest::summonitem(10117);

                quest::faction(320,5);

                quest::faction(291,-15);

        }

Creating a method here called check_inventory which takes the same parameters as "check_handin" would allow for easy replace all. Then, all you need is a method called "add_to_inventory" which gets triggered every time something is handed in (subsequently, the check function should be called... as I assume it already is.) Within the check function, delete the appropriate items from the inventory when the check succeeds (and obviously return true).

Sorry, I'd write up a bunch of pseudo code but I don't even know where to begin with parameters like the above.

I don't consider MQing really very important, so I wouldn't expect you to spend alot of time on such a fix. But if you were so inclined, an approach like the above might be worth looking into. Anyway, thanks for the early morning brain teaser.

Cheers.