Brainstorming: Quests stored in DB

[bushman77]

i see why you want the quests embedded into the database. Would allow someone to edit a quest while ingame (so aslong as they have access to the commands you create in perl to do this). I think you have to create these 'extra' commands in the commands.pl. Which means one would have to have an undestanding of how perl commands work. Fairly similiar to php commands from what i'm understatnding.
idea which might not work would be to make a global quest that activates all the mobs onthe server but have it so this 'quest' based on either name or npcid query the quest table in the db for its corresponding quest

This is only a brianstorm

[fathernitwit]

well as im not sure which your talking about, i'll discuss both:
1) perl stored in the DB - this would be doable with a small amount of effort, by subclassing the parser and extending it to query the DB instead of looking on the filesystem.
2) making table entries to represent conditions and actions to be preformed by quests - This option is significantly more complicated to implement, and even then it would not provide near the flexibility of using a scripting language. Sure, 90% of quests are simple hails or handins, but as soon as it gets much more complicated than that, representing it accurately in the DB gets exponetially more difficult.


The best solution to manage collaborative quest work is to use a source code control system such as cvs or subversion... give your quest people commit access, and you can pull them from CVS down into your server... and even audit the changes if you want.

[Teppen]

I could be wrong, but I heard mango's wow quest system is c++/sql based.

If this is true, the upside's that I could see if this was implemented into eqemu would be:

1) Less processes running since you wouldnt need perl installed or running.
2) One big sql file instead of individual .pl files.
3) a quest edit tag could be added to mystics peqeditor to edit sql quests.

Not sure of any downsides. This would be a nice upgrade, but not a demanding one.

I could see if the emu was just starting and talk discussing which method approach to use, but this is not the case, the project has a quest system already and it is working fine.

But dont let anything said in this thread discourage you. As you said, "you" would code and implement this. You could always code this up as you have purposed and host on your site as an optional quest system for eqemu, and those who want to go this route can. Could be tedious when new eqemu versions post but i guess it could be done.

[Cripp]

Originally Posted by fathernitwit

The best solution to manage collaborative quest work is to use a source code control system such as cvs or subversion... give your quest people commit access, and you can pull them from CVS down into your server... and even audit the changes if you want.

http://nug.cvs.sourceforge.net/nug/nugblazers/


I would also recommend this.. very useful...

and about c++ quests / sql....
perl is l33t, i <3 it and the idea of C++ / sql quests sounds horrible.