Multiquest on Live?

[Knightly]

Can you still multiquest items on Live? It doesn't seem to work in the emulator is why I'm asking, but there's no sense making it work if Live stopped allowing you to do so.

[So_1337]

The stance on Live was almost always that you attempted MQs at your own peril. It was never supported that I ever saw, but rather came about from people being clever enough to figure out how NPCs accepted quest items and to use it to their advantage. Whether a quest was MQ'able or not usually just depended no what type of quest it was:

- If you turn in three items, it could likely be multiquested because you could have someone turn in one item and you turn in the other two.

- If instead you're given a box and asked to combine three items and return the box, there went your chance of any multiquesting.

I can't remember there ever really being "support" for MQing, but it was there.

Hope this helps. But probably not :)

[mattmeck]

most of the stuff you could MQ before, you can still MQ now.

SOE just made quests work diferently with newer content so you cant do it any more, but most of the older stuff is still able to be MQ'd...

Epics, Jboots etc etc are still able to be.

[Striat]

If you branch a tad bit out of the quest system, this is a very easy task. Heck, it can already be done through the current quest system even. It just requires a few extra lines.

[narcberry]

SOE doesn't like MQ'ing and their current strategy to stop it is to just not make it possible with new quests. Old stuff is still MQ'able.

[DoucLangur]

Is there any news on this, as in: has a generic code to allow a quest to be MQed been implemented into EQEmu?

If not, I am trying to provide a generic solution, as in: give a quest a flag to define whether it is MQable or not, and if that flag exists, NPC will accept individual items for that quest's turnin, and reward whoever completes a set.

We are currently facing the situation on Project 1999 that only JBoots are implemented as a MQ, because each MQ needs to be scripted separately. I would like to improve on that situation.

Also - if this is not provided as a generic functionality yet - I am interested in contact with any experienced EQ Emu programmers on the topic.

Cheers,

DoucLangur

PS: Why is the EQ Emu code so terribly underdocumented? I can hardly find any lines of documentation in the questmgr.cpp / .h files...

[ChaosSlayerZ]

it has ALWAYS been considered an exploit, and I am strongly against putting anything like that into Emu code.

If you running your own server and want to be able to buy quest parts from other players - just make then tradeable - problem solved.

[Secrets]

it has ALWAYS been considered an exploit, and I am strongly against putting anything like that into Emu code.

If you running your own server and want to be able to buy quest parts from other players - just make then tradeable - problem solved.

you're retarded.

it's not an exploit on live, and I don't think we make the choices for servers here. completely irrelevant. it's open source software, do whatever you want with it.

Douc, if you'd like to implement it, post a diff on the code submissions section. if you need any help on what something does, just post here, we'd be more than happy to help.

[sorvani]

Here is how I see it.

All NPC's will have to gain an inventory that items given to them can be logged in.

Then the quest structure will need to have commands added to it to check said inventory, and purge said inventory.

Then quest files themselves will still have to be rewrote to use these new functions.

[ChaosSlayerZ]

you're retarded.

it's not an exploit on live, and I don't think we make the choices for servers here. completely irrelevant. it's open source software, do whatever you want with it.

Douc, if you'd like to implement it, post a diff on the code submissions section. if you need any help on what something does, just post here, we'd be more than happy to help.

you are the one who is retarded and can't read.
If EQ designers ever wanted you to be able to MQ, they would have made those quest parts tradeable - they made them no drop for reason. But when they saw how people were exploiting they just never bothered to fix it, yet in the future they took every step to avoid it (quest boxes, task system etc).
It wasn't an exploit you were punished for, but never the less its an exploit, since you using this bug to go around no drop restriction.

And I never spoke of how privately owned servers should change their open source code - this is their business. I said, don't put this crap into OFFICIAL code.

[sorvani]

If EQ designers ever wanted you to be able to MQ, they would have made those quest parts tradeable - they made them no drop for reason. But when they saw how people were exploiting they just never bothered to fix it, yet in the future they took every step to avoid it (quest boxes, task system etc).

Quit ranting and prove it.

[ChaosSlayerZ]

Quit ranting and prove it.

LOL prove is above, read the thread from the beginning.

[trevius]

It would probably be fairly easy to just write a script function and/or plugin to handle multi-questing if someone really cared enough to make it happen. You can just save any item turned in into an array, and then check the items in the array to see if they match a hand in that is set. If the zone was reset, the items that had been turned in would clear out, but that is how it works on Live as far as I can recall. There should be no source changes required to make multi-questing fully functional to mimic Live.

If source was going to be change in relation to item hand-ins, I think the first priority would be to replace the existing plugins for it with commands that actually save the item instance that is turned in, so they can be returned with the correct charges, attuned setting and so on of the item that was turned in. I have a plugin that actually does this, but haven't fully tested it enough yet to submit it to the public.

[Secrets]

And I never spoke of how privately owned servers should change their open source code - this is their business. I said, don't put this crap into OFFICIAL code.

Why shouldn't we put it in code? If you're going to bitch about yet another thing, we can make a rule for you. Just for you buddy. We're supposed to be emulating live, and we're up to GoD. Guess what was possible in Gates of Discord? Multiquesting! Whether or not you like it, it was there.

You know, considering the rules system we have in code, saying that something shouldn't be in there because YOU don't like it on morality reasons, mind you, is a non issue because SOE didn't BAN for it. You didn't start a shitstorm about the FVNoDrop flag that allows GMs to trade nodrop items to players, and I am sure you wouldn't give a shit about my binary diff that disables the nodrop flag altogether. (made for GMs, but if clients use it they get kicked and hacker logged...)

What makes this any different? Nothing.

You shouldn't really be making dev team decisions if you aren't on the dev team, use our code, and submit nothing.

[trevius]

Please keep it friendly guys! We all know each other here :P

[Secrets]

Please keep it friendly guys! We all know each other here :P

Sorry :P I have a lot of tension lately.

[DoucLangur]

First of all, thanks to all for the feedback :)

Here is how I see it.

All NPC's will have to gain an inventory that items given to them can be logged in.

Then the quest structure will need to have commands added to it to check said inventory, and purge said inventory.

Then quest files themselves will still have to be rewrote to use these new functions.

I haven't seen enough of the quest manager code to fully understand how this works (the get item code seemed to purge *all* items of a certain ID from the players inventory, returning a yield count), however, I agree with you on the inventory part, and with trevius on the array (or collection) implementation:
- All items handed in to the NPC should be stored in there *if* - and only if - they are part of *any* item set the NPC would accept for a quest. To facilitate this, I guess the NPC could use an array that contained all quest items accepted by him, associated with a quest ID, a count "required amount" and a count "amount turned in".

- When an item is turned in that is contained in the array, it's according "amount turned in" counter is increased until max is reached. Another item of the same type would increase another counter if that item is in the list more than once, otherwise it would get "eaten" by the NPC (to mimic behaviour were you have to turn in multiple items *unstacked*).

- depending on how MQ NPCs behave on live, once all items for a quest are complete, the reward is triggered and the array is either reset or the items for the completed quest are removed from the array. I am not sure if you could multiquest 2 different quests at the same time.

I think that covers most situations that I can think of.

I'll have a look at the quest manager over the next weeks (am in no hurry) and see if I can find the actual code that does the completeness check on quests (I suspect it is in the perl scripts for each quest currently) - to generalize this in the questmgr code. Ideally, the perl code would only have to call some "getItem(arrayOfTurnedInItemsWithCounts)" function, and check it's return value for an event that indicates a completed quest. Shouldn't require much recoding on the script side. Or rather - I would try to make it so that it could be done without recoding. If possible.

Cheers,

Douc Langur

[Caryatis]

Secrets spending too much time in IRC with me it seems like haha.