Go Back   EQEmulator Home > EQEmulator Forums > General > General::General Discussion

General::General Discussion General discussion about EverQuest(tm), EQEMu, and related topics.
Do not post support topics here.

Reply
 
Thread Tools Display Modes
  #1  
Old 12-24-2016, 03:06 AM
fzzzty
Fire Beetle
 
Join Date: Aug 2010
Posts: 23
Default EQEmu, database and era pivot

Hello,

Not too long ago I started working on my own server. I got it up and running (on FreeBSD) and made a couple useful tools in the process to make getting started easier (simple "one-click" shell script to take care of everything). I was starting over a lot and this helped me immensely. During my journey I realized a few things that I use regularly in my daily life that I wish were a part of EQEmu (I'm a developer both in my 9-5 day job and moonlighting).

I haven't messed with starting up in a while so I apologize if any of these are different now.

My main frustration was that EQEmu isn't really "an app"--it's more like a combination of half a dozen things with some (ha) assembly required. I think it would benefit a lot from some standardization or streamlining.

One example is bots. Enabling bots required patches to the source, "patches" to the SQL (which may or may not work depend on other patches and versioning), config changes, and maybe changes beyond that. It would be a lot nicer if everything were simply baked in and toggled via configuration options (or modular but that's usually a lot more work).

Speaking of SQL, probably the biggest oddity I encountered and one of the largest sources of confusion for me was how the database is handled. EQEmu doesn't really have a database. The database seems to be determined by another group (peq) and sort of used by EQEmu. The problem this creates, or at least one of them, is that one side of the eqemu-pqedb pairing can change, independently, breaking the combination. Also, version numbers, dates, etc. made it really confusing for me to know what to heck I was supposed to do. I had to take one version of the DB, apply a bunch of SQL migrations/patches, skip some of them (!?), fix a couple of older ones because the DB schema changed from what it was...it was kind of a mess, even with the helper scripts.

I think it would be better to have a bona fide official DB schema as part of EQEmu, with tables that make sense for EQEmu and all of its features, and have a separate ETL layer for translating the peq db into EQEmu. Basically view peq as the data that goes into the eqemu DB, but remove the schema dependency. Distribute the eqemu DB schema with the app itself. The SQL migrations would be less fragile and simpler to deal with.

This brings me to my last suggestion, which probably would involve the peq folks as well, but I think would be super beneficial to EQEmu as a whole: era support. I know for my server I wanted to make it classic, and lots of people want to stick to certain eras/expansions, or have their own custom content. I think it would help a ton to bake that into the schema. You could make it a simple int or enum, but I would lean towards a start date. The idea is to assign an era_id (or similar) to almost everything (everything content-related at least), and have a list of eras somewhere. The primary key would probably change to be a composite (id,era_id) where applicable. One nice thing is that this doesn't prevent custom content or tweaking existing content at all, you just add an era or modify the era you're using.

Take, for example, the NPC Brother Hayle (I think that's the one). In classic, he lives in Paw, IIRC, but in modern EQ he is in SK. The idea is that you would have two (or more) entries in the NPC table, something like:

id|eraId|name|zone|spawnLoc
1|1|Brother Hayle|paw|500,2500,-200
1|2|Brother Hayle|southkarana|1000,4000,20

The user could decide to delete previous or future era versions of data if they wanted, and it would be pretty easy to do so, e.g. to reduce index requirements. A configuration setting could determine which era you're using. You could potentially push out changes with this and "roll back" just by flipping the era ID. You could take the current peq DB and merge in the TAK classic data, potentially P99 data (as if), and have one data set from which anyone could run any sort of server and into which corrections could go. The community wouldn't need to be so fragmented with different and duplicated efforts...

It could also be possible to use the era_id only within the peq DB and, if the schemas were separate, just pull out the era data you wanted into your server based on that ID.

These thoughts are all coming from a point of view of separating the data and application whilst at the same time solidifying the application into something more standardized and predictable. With one mainline DB schema, era-based data covering all expansions, and a single (less patchy) more predictable/testable code base, I think the app would benefit a bunch...
Reply With Quote
  #2  
Old 03-08-2017, 02:49 PM
NostalgiaEQ
Banned
 
Join Date: Sep 2016
Location: us
Posts: 201
Default

Great post but at this point I feel everyone does what they do and we have to "slightly fork" and make improvements on our own. If something tests out to be great and stable then we can give it back to eqemu and they may implement it in their code base.

I am working on a classic server too so I would love to work with you to inprove things (and learn from you). Hit me up here or nostalgiaeq@gmail.com. Mabye we can also work on a standardized classic database (many have tried and all have failed thus far lol) which would be a huge boon to the community.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 04:32 PM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3