Crazy idea for spells...

**KLS** · #1 11-24-2008, 03:35 PM

Just for the future: I'd rather you turn large (potentially game breaking) features off by default at least at first when they coexist with previous implementations.

**cavedude** · #2 11-24-2008, 03:53 PM

It doesn't look like it can be disabled. :( Without the table, zones crash as soon as a spell is cast, with a blank table, the zones won't boot at all.

leslamarch · #3 11-24-2008, 04:36 PM

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

Code:

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*

Andrew80k · #4 11-24-2008, 04:44 PM

Quote:

Originally Posted by leslamarch

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

Code:

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*

Did you install the DBD::mysql module? It's got a new name and I don't remember what it is off the top of my head. You should be able to use ppm to find it though. I'm not sure what the mysqlPP is, but it typically means mysql Pure Perl. I'm not sure if that's the same thing or not. I don't run it on my windows box anymore so I don't know for sure.

**trevius** · #5 11-24-2008, 07:33 PM

Is it possible to retract an SVN submission? Would be pretty awesome to just be able to remove it and not have to either manually remove everything added in it, or commit an older version to revert it.

I was hoping to get the new food stats fix in that I got done last night, but couldn't because of the problems with this.

**AndMetal** · #6 11-25-2008, 02:03 AM

Sheesh, I go away for 17 hours and everyone freaks out...

Anyways, to address the questions:

Quote:

Originally Posted by trevius

Can you give an example of using the script?

cavedude pretty much got it. I would recommend using the -h (for [h]elp) switch, recommended in the changelog:

Quote:

==11/24/2008==
AndMetal: Spells can now be loaded from the database, and is now enabled by default. Use utils/import_spells.pl to import, utils/export_spells.pl to export. Use -h on either for usage.

Required SQL: utils/sql/svn/229_spells_table.sql

Code:

perl import_spells.pl -h

perl export_spells.pl -h

which gives the usage (which I also posted above):

Quote:

Originally Posted by AndMetal

Code:

Usage: import_spells.pl [-c path] [-s path] [-t table] [-d]
  -c path       path/to/eqemu_config.xml. defaults to eqemu_config.xml
  -s path       path/to/spells_us.txt. defaults to spells_us.txt
  -t table      table to load the spells into. defaults to spells_new
  -d            erase all spells from the database first

Quote:

Originally Posted by AndMetal

Code:

Usage: export_spells.pl [-c path] [-t table] [-i column] [-s path] [-o]
  -c path       path/to/eqemu_config.xml. defaults to eqemu_config.xml
  -t table      table to load the spells from. defaults to spells_new
  -i column     name of the column in the database table to order by. defaults to id
  -s path       path/to/export/spells_us.txt. defaults to spells_us.txt
  -o            overwrite spells_us.txt if it exists

By default, it will look for both eqemu_config.xml & spells_us.txt in the current directory (as indicated in the usage info for the switches, since they don't have any /'s before the names of the files), so you could easily just execute it from your server directory. For me, I would end up using something like this, cause even though symbolic links are awesome, I don't really like making them a lot:

Code:

eqemu@amsk-server:~/svn/EQEmuServer/utils$ perl import_spells.pl -c ~/server/eqemu_config.xml -s ~/server/spells_us.txt -d

eqemu@amsk-server:~/svn/EQEmuServer/utils$ perl export_spells.pl -c ~/server/eqemu_config.xml -s /var/www/eqemu/spells_us.txt -o

Then, you can just add the export to your startup script so it exports at runtime if you wanna be one of the cool kids

Quote:

Originally Posted by trevius

Also, how do you disable using this so it continues to use the normal spells file? From reading the changelog, it sounds like it is supposed to use this table by default. I am guessing that means it will ignore the spells file unless you disable this feature? Or, will it use the spells file if it can't find the table?

The idea is this will replace using the spells file. The only reason I didn't just straight take out the old stuff is so everyone can continue to use it if they want to (just like turning bots on, SPELL_EFFECT_SPAM, etc) by changing the #defines in zone/spdat.h:

Code:

//#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

One change I might make would be to create a default case if neither are defined:

Code:

//#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
#if !defined(NEW_LoadSPDat) && !defined(DB_LoadSPDat)
#define NEW_LoadSPDat
#endif

However, then we're completely rid of the real old way of doing it (lots of hard coding). I honestly don't think anyone's using that old code, but who knows.

Quote:

Originally Posted by trevius

BTW, your code box in your export script post says "import", not "export" for usage.

Minor typo. I was copying/pasting the top half of the scripts, and forgot to make that change.

Quote:

Originally Posted by KLS

Just for the future: I'd rather you turn large (potentially game breaking) features off by default at least at first when they coexist with previous implementations.

I've actually been using this code, successfully, for just shy of a month (since October 27th to be specific). The only thing that took a little time was the scripts to import/export the spells (having a kid in the middle of all that did slow things down a bit). Not only that, but the main thing it's doing is loading spells into the spells[] "array" from the database instead of the spells_us.txt file. There were also a few unknown values in the SPDat_Spell_Struct struct that I came across, but I made sure it worked with the spells_us.txt file before I even tested with the database (which caused problems with sharedmem a few months ago when I first started working on it). I personally don't consider it to be a "large feature", rather just a bunch of copying, pasting, & tweaking of existing code.

Quote:

Originally Posted by leslamarch

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

Code:

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*

I'm running Debian & have libdbi-perl & libdbd-mysql-perl. The scripts use DBI, so Perl probably just assumes MySQL when trying to connect to the server (automatically negotiated maybe?):

Code:

use DBI;
use Getopt::Std;

As far as I can tell, both of the DB packages are installed automatically when installing the MySQL 5.0 server, again at least on Debian.

I guess the question now is anyone actually having problems after getting the spells into the database? Because other than that, I'm not sure what all the ruckus is about...

I know it compiles, I know it runs, I know it works, and made sure to test it thoroughly before I got to this point. I even just checked my launcher status page & haven't had any zone crashes since my server was booted up at 6:28am today.

**AndMetal** · #7 11-25-2008, 02:28 AM

Got to talk to trev, and it appears there is a compiling issue when setting to NEW_LoadSPDat. Looks like I missed some +'s when I was copying from a diff (thanks again Google!):
zone/net.cpp

Code:

+               // May crash zone
+               /*
+               sp[tempid].nodispell=atoi(row[186]);
+               sp[tempid].npc_category=atoi(row[187]);
+               sp[tempid].npc_usefulness=atoi(row[188]);
+
+               for (y = 0; y < 18; y++)
+                       sp[tempid].spacing189[y]=atoi(row[189+y]);
+
+               sp[tempid].spellgroup=atoi(row[207]);
+
+               for (y = 0; y < 18; y++)
+                       sp[tempid].spacing208[y]=atoi(row[208+y]);
+               */

Took 'em out, recompiled with NEW_LoadSPDat, and works fine.

EDIT: This is in SVN as Rev 232.

**KLS** · #8 11-26-2008, 04:18 PM

Quote:

I've actually been using this code, successfully, for just shy of a month (since October 27th to be specific). The only thing that took a little time was the scripts to import/export the spells (having a kid in the middle of all that did slow things down a bit). Not only that, but the main thing it's doing is loading spells into the spells[] "array" from the database instead of the spells_us.txt file. There were also a few unknown values in the SPDat_Spell_Struct struct that I came across, but I made sure it worked with the spells_us.txt file before I even tested with the database (which caused problems with sharedmem a few months ago when I first started working on it). I personally don't consider it to be a "large feature", rather just a bunch of copying, pasting, & tweaking of existing code.

You don't, but I do. It interacts with a core part of the server functionality so I would consider it big even if it doesn't seem all that complex. Also given that there are no real benefits yet (it's all a idea for future expansion) I'd rather retain backwards compatibility right now. People who want to use the new system can use it but until we start getting applications that take advantage of it I'm not gonna force people.

I'm glad you guys got it all sorted out before I got back, kinda hard to fix stuff with svn when on the road =/ Keep working with this it has potential even if we haven't found it yet.

erik_llewellyn · #9 01-17-2009, 02:33 AM

Quote:

Originally Posted by leslamarch

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

Code:

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** · #10 02-24-2009, 01:08 AM

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 · #11 02-24-2009, 01:26 AM

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

**trevius** · #12 02-24-2009, 02:17 AM

Quote:

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.

Randymarsh9 · #13 07-12-2009, 10:22 PM

Quote:

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