Crazy idea for spells...

[AndMetal]

It seems like there have been several posts recently about spells, and trying to make easy ways to modify them, and it got me thinking... Why aren't the spells in the DB yet? Config files && hard coded variables == bad, database == good

I'm no programming expert, but it looks like somewhere the spells_us.txt file is parsed into an array (spells[]) using Separator, I think (from common/seperator.h). In theory, it should be relatively easy to change how it is loaded from a file to loading it from the database. I'd take a stab at this, but I'm having some trouble finding where in the source the spells file is actually loaded.

Does anyone know where that can actually be found?

[ChaosSlayer]

I am not a developer, but...
it may something to do with the fact that spell_us is loaded from BOTH sides, client and server. And since client cannot be altered, my best guess that spells format will have to stay the way they areat least on the client end.

Thought a fetaure where spels could be stored/edited in server db, and then dumped into txt file and given to players would be nice

[AndMetal]

Originally Posted by ChaosSlayer

Thought a fetaure where spels could be stored/edited in server db, and then dumped into txt file and given to players would be nice

That's exactly the end result I'm looking for

Right now, if you make custom spells, you have to give the altered copy of the spells_us.txt file for distribution anyway. If it is in a database, you can either setup a daily script to output the file for you, or have it manually created when you click a link (dynamic file), the latter being more resource intensive, but more real-time. This makes it easier for users to have access to it, and easier for admins to make changes.

[AndMetal]

After doing some more digging, I answered my first question. The spells are loaded in EMuShareMem using EMuShareMem/Spells.cpp. Unfortunately, I can't make much sense out of it.

[Davood]

assuming you want to do it all with a db,,

what if you made spells work by #cast 1-9 and text based spellbook? :P

then you could setup the spellbook to let you do searches

#book list 1 30
level range 1 to 30

and mem a spell !

#book mem 1 321

(casting slot 1, spell 321 from book)

then you could create tiers of spells all the way to 250 ! hahaha..............

mind you the players might balk at having to use commands for everything spell related, even though they can make hotkeys.

ok i experienced a momentary "mr wee" there... .. but seriously !

[narcberry]

This would make the server much cleaner, make spell editing easier and faster. It also means an extra installation step to convert the spells file into the db. Hope to see this soon.

[AndMetal]

I have finally decided to give this a shot, but I wanted to see if I could get some feedback.

I found where the functions are that actually load the spells from the spells_us.txt file, which is in zone/net.cpp. For the life of me, I can't figure out why they would be defined in the net code. Sure, I could just add some #include's to allow database functionality, but if possible, I'd rather put it in a more appropriate spot (zone/zonedb.cpp maybe?)

The feedback I'm looking for is this: would it be better to leave the code where it is, in zone/net.cpp, or should I put it somewhere else? And if I put it somewhere else, where should it go?

[So_1337]

If you use the PHP editor, the spells already have to be pulled into the database. So it's been done already for another purpose, just not actually used by the server. Might check that out.

[KLS]

zone/net.cpp is actually not named very well it should be named something like main.cpp as it is what actually contains the main() program. It's probably defined there because it was implemented rather early and that's a trivial way to get access to spells throughout the code.

[AndMetal]

That makes sense.

I think I might actually be lucky, because I think dbcore functions (RunQuery mainly) are accessible, although I'm not sure how because it's not #include'd directly. If not, I'll just add it, but I've already made about 1/3 of the changes needed, so hopefully I'll be able to start compiling & testing it by this weekend.

[KLS]

As long as the zonedatabase has been initialized you can use database.RunQuery() pretty accessibly throughout almost any part of the zone code.

[AndMetal]

I finally had a chance to revisit this (I was using RunQuery as opposed to database.RunQuery, plus I fubar'd some stuff with shared memory) and it's working great. However, I wanted to get some additional feedback: should we make everyone do this (just change the source), or should we #define DB_LoadSPDat vs #define NEW_LoadSPDat, that way everyone can update as they wish?

I'm kinda thinking the latter, but I wanted to see what everyone else thought, especially since we'll probably want to make a Perl script (I only have a PHP script) to load a custom spell set into the database vs using the Titanium spell set.

[Congdar]

Could you make it so it loads the default titanium spells first and then loads additional spells later if they exist by checking some rule? That would be ideal to keep it compatible with the current way and then enable the custom stuff.

[AndMetal]

Originally Posted by Congdar

Could you make it so it loads the default titanium spells first and then loads additional spells later if they exist by checking some rule? That would be ideal to keep it compatible with the current way and then enable the custom stuff.

I'm not sure I understand what you mean by "default titanium spells first".

This change allows the spells_us.txt file to be sourced into the database once & read from there instead of opening the spells_us.txt file each time the server (zone?) is loaded. The only thing that would change by the #define is whether or not you load from the spells_us.txt file (the "old" way) or load from the database (the "new" way).

[Congdar]

I like the idea of making things faster, but the added problem of downloading a txt file that matches a particular servers emu code level would be a pain if you played on multiple servers with possibly different code levels(like the one you play on when your favorite is down, etc).

So there would need to be the 'default titanium spells first' list in the db that works with anybody that connects and doesn't have 'the latest custom spell list with all the fixes'.