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