Brainstorming: Quests stored in DB

Damilis · #1 11-06-2006, 07:19 AM

Title says it all Folks! What do you think about:

1) Having a perl plugin that takes the parameters passed to it by EQEmu, querying a Quests table in the DB via MySQL, and returning the appropriate data to EQEMU

-or-

2) Coding in a 100% C++ questing system, selectable via the config files, that taps the above mentioned Quests table directly.

Up till recently, this would require a custom tailored DB front end for Quest Scripting (tools like this exist now) but now EQEmu has a developing Web Server functionality. Serverops don't have to be at the machine console anymore as a lot of functionality is remote... why not extend this functionality to Quests also? This could potentially attract those who would like to help but can't/don't want to run their own server. (there would have to be a level of ServerOp authentication of course)

Aight, open floor! Questions, comments, concerns, ideas

Theeper · #2 11-07-2006, 11:29 AM

I guess my question would be why ? ...

Maybe I just don't see the possibilities here, but I am not sure what you'd accomplish by adding a bunch of queries to the quest system. If you want people to be able to remotely add and edit quests, just give them shell or FTP access.

As far as doing it in C ... I certainly don't want to re-compile and restart my server everytime I make a change to a quest, and more importantly, I doubt FNW and the other devs care to rewrite the quest system again.

Damilis · #3 11-07-2006, 12:37 PM

Quote:

I guess my question would be why ? ...
Maybe I just don't see the possibilities here, but I am not sure what you'd accomplish by adding a bunch of queries to the quest system. If you want people to be able to remotely add and edit quests, just give them shell or FTP access.

LOL like hell I am gonna give anyone shell or ftp access to my box. Way too big of a security risk. Besides, using a web interface is cleaner and easier to use. Plus FTP is blocked on my work LAN so I would need something on Port 80

Quote:

As far as doing it in C ... I certainly don't want to re-compile and restart my server everytime I make a change to a quest, and more importantly, I doubt FNW and the other devs care to rewrite the quest system again.

No no no, you missed my point. Just like the current Quest system is written in perl, make an additional system, selectable at startup, written in C. Quests will be stored in MySQL so they can easily be edited, added, deleted, etc via a web page. And as for the devs doing this, nay, I would never ask. They have to keep pushing the Emu 'forward' and let us serverops develop 'sideways.' I will tackle this project if there is enough interest, maybe even if there isnt

John Adams · #4 11-08-2006, 12:59 PM

Maybe our first question to you is, what's wrong with the way it's done right now?

Let me be clearer... you want to offer remote sysadmins the ability to write code in C++ that will execute on your box, but you are fearful of opening a SSH or FTP option for them?

Damilis · #5 11-08-2006, 02:03 PM

Quote:

Originally Posted by John Adams

Maybe our first question to you is, what's wrong with the way it's done right now?

Let me be clearer... you want to offer remote sysadmins the ability to write code in C++ that will execute on your box, but you are fearful of opening a SSH or FTP option for them?

*slams head on desk*

Lets try yet another approach at explaining.

-Quests would be stored in rows in a DB table.
-EQEmu uses a hardcoded C++ system to access and run these quests.
-Admin of these quests (add, delete, edit) would be via EQEmu's built in WebServer or some other custom built web interface.

No one said anything about giving anyone sysadmin ability.
No one said anything about writing quests in C++.

John Adams · #6 11-08-2006, 02:13 PM

Quote:

Originally Posted by Damilis

Just like the current Quest system is written in perl, make an additional system, selectable at startup, written in C.

My mistake... :/

Damilis · #7 11-08-2006, 02:31 PM

Whew, now (hopefully) its understood, anyone with pros/cons ?

The only reason I came up with this idea is I don't look forward to managing several hundred thousand text files worth of quests.

bushman77 · #8 11-09-2006, 05:12 AM

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** · #9 11-24-2006, 05:17 AM

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 · #10 11-24-2006, 05:52 AM

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 · #11 11-25-2006, 05:10 AM

Quote:

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.