Crazy idea for spells...

[erik_llewellyn]

Originally Posted by leslamarch

Been trying the export script for 2 hours now with no luck

perl export_spells.pl
install_driver(mysql) failed: Can't locate DBD/mysql.pm in @INC (@INC contains:
C:/Perl/site/lib C:/Perl/lib .) at (eval 4) line 3, <F> line 36.
Perhaps the DBD::mysql perl module hasn't been fully installed,
or perhaps the capitalisation of 'mysql' isn't right.
Available drivers: DBM, ExampleP, File, Gofer, Proxy, SQLite, Sponge, mysqlPP.
 at export_spells.pl line 62

*waves the white flag*

This error is caused because the DBD-mysql perl module is NOT installed. I ran into this issue ever since the Nov update and could not get the import_spells.pl or export_spells.pl scripts to run. After getting around to conducting some research on it now that my time has freed up, the issue seems to be that the default PPM package availability list no longer has DBD-mysql listed as an option. The DBD-mysqlPP will NOT WORK for the sake of the spell scripts and you must install the normal DBD-mysql module. To install it, follow these steps:

1. open the Perl Package Manager
2. click the Edit menu - Preferences
3. click the Repositories tab
4. In the location box type "http://theoryx5.uwinnipeg.ca/ppms/"
5. Click Add
6. Click OK
7. Install the DBD-mysql package

OR

1. open a command line prompt
2. type "ppm install http://theoryx5.uwinnipeg.ca/ppms/DBD-mysql.ppd
"
3. Press Enter

At this point, the import/export scripts will run correctly.

[trevius]

Since I think this is now a proven alternative systems for spell management, I was wondering if we should consider making it on by default. Otherwise, maybe we could set a rule that will allow admins to chose which type of spell system they want to use (the file or the table) and only have to set it the one time in the rules table instead of changing the define each time before updating the code on their server. Any ideas or input?

[ChaosSlayer]

will players still need to have their own spell file if spells will now be loaded into DB?

[trevius]

Originally Posted by ChaosSlayer

will players still need to have their own spell file if spells will now be loaded into DB?

Yes, this changes nothing about how the client handles spells. It just lets the server load spells directly from the database instead of from the spells_us.txt file. Basically, it doesn't really make much of a difference yet which way they load them. There is alot of potential with loading from the DB though. For one, it means you could download the PEQ database and have spells included with it so you don't have to put move the spells file from your EQ directory over. That is fairly minor, but 1 less step in the setup process. A big benefit of having it in a table like this is that you can give your GMs access to the table and they can edit it very easily to fix broken spells or make custom ones. Kayen has made quite a few adjustments to the custom spells on Storm Haven already. Many changes he makes doesn't require an update to the spells file that the clients use. It all depends on what changes you are making and to what spells.

The main benefit I can think of for loading spells into the database with this system would be that we can add extra features for spells that just aren't an easy option for the spells_us.txt way. My first idea for this is to create 2 new columns in the spells table at the end of it that will allow you to set a name and a value that could maybe be tied into quest globals. Basically, the idea is that the default name and value might be something like 0 for those fields, and anyone will gain those spells when using the #scribespells command or a spell scriber quest. But, any spells that are set to another name or value won't be scribed unless that player has that particular global with the same value or greater. So, basically, you could create tiers of spells or define special spells that will only be able to be learned if the player has earned them via a quest or whatever. I think it would be a great system and shouldn't be all that hard to create using the new database spells system and quest globals. That would be pretty tough to do/manage if spells weren't loaded into the database like they can be now.

Unfortunately, I won't have time to even think about working on that new system for quite a while. But, it is definitely something I would like to get going at some point.

Another quick idea to make use of the new database spells would be to create an additional field that would let admins set certain spells to be automatically converted into another spell if it was cast between a Titanium and a SoF client. This would be useful to correct any discrepancies between spell files of the 2 clients and also would be useful for servers with custom spell files. I don't even know if this idea is possible, but it would be pretty cool if so. The field could be called something like SoF_SpellID and you would just put the spell id of the spell that you want the SoF client to use in place of what the Titanium client is casting or visa versa. There could probably also be a Titanium_SpellID column added as well that would convert an SoF spell into a Titanium spell ID. So, say that the buff Temperance was spell ID 100 in Titanium, but spell ID 200 in SoF, by setting 200 in the SoF_SpellID field, it would convert the spell ID to the correct one so that the correct effect happens on SoF. Though, this might require 2 spells tables, one for Titanium and one for SoF. They would have to both be loaded into memory though. I think with 2 spells tables, it might actually not be too hard to do a conversion system like this though. Just an idea anyway.

[trevius]

If no one has an objection, I am going to finally change the default to the spells_new table as apposed to loading spells from the spells_us.txt file tonight. I see no reason not to change it now, anyway.

Of course, anyone still using the spell file will either need to make the switch to using the table, or will need to change the define before compiling. I think Cavedude have been changing the default before compiling the binaries anyway, so no reason not to change it in the source. The old way will still be there and will probably remain there indefinitely or until it is decided that we never have need for it again.

Let me know if there are any objections before I change it tonight. If a reason does pop up later, it can always be changed back easily.

[ChaosSlayerZ]

ah Trev, I may have a small objection
One thing about workign with spells, that txt file is far easier to swap around when something needs to be changed FAST. (like copy and paste for entire chunk of lines)

So instead of a define- could you make this option into a Rule instead? this won't even give an overhead since all spells load only ONCE when sever starts.

[trevius]

To change it to a rule would probably mean adding in duplicate of a ton of code in multiple files. I don't really think it is a good option or it probably would have been done already.

If you need to do some major changes like that, you can easily use the import and export scripts to export the spell file from the spells_new table, change it and them import it back into the table. That is what the scripts were made for

Another reason that the table is a really good way to go is because if people export it to create their server's spell file, the exported file will work perfectly with both Titanium and SoF, since it has the correct number of fields to function with both clients.

I think the binaries have been set to use the table loading for a while now. So, if you use those, you would have been stuck with the table loading anyway. If you don't want to use the table loading way, it is very simple to change the source to use the file loading way instead and then compile your own binaries. All you have to do is go to zone/spdat.h and change the following:

//#define NEW_LoadSPDat
#define DB_LoadSPDat  //load from DB vs spells_us.txt. for now, we're piggybacking NEW_LoadSPDat, so it will take precedence

to this

#define NEW_LoadSPDat
//#define DB_LoadSPDat  //load from DB vs spells_us.txt. for now, we're piggybacking NEW_LoadSPDat, so it will take precedence

[Randymarsh9]

Originally Posted by erik_llewellyn

This error is caused because the DBD-mysql perl module is NOT installed. I ran into this issue ever since the Nov update and could not get the import_spells.pl or export_spells.pl scripts to run. After getting around to conducting some research on it now that my time has freed up, the issue seems to be that the default PPM package availability list no longer has DBD-mysql listed as an option. The DBD-mysqlPP will NOT WORK for the sake of the spell scripts and you must install the normal DBD-mysql module. To install it, follow these steps:

1. open the Perl Package Manager
2. click the Edit menu - Preferences
3. click the Repositories tab
4. In the location box type "http://theoryx5.uwinnipeg.ca/ppms/"
5. Click Add
6. Click OK
7. Install the DBD-mysql package

OR

1. open a command line prompt
2. type "ppm install http://theoryx5.uwinnipeg.ca/ppms/DBD-mysql.ppd
"
3. Press Enter

At this point, the import/export scripts will run correctly.

I tried doing this but it had no effect. It kept saying things like no PPD found at http://theoryx5.uwinnipeg.ca/ppms/. So instead I just tried ppm install DBD-mysql and it looks like the import.pl is working now