Crazy idea for spells...

ChaosSlayerZ · #1 06-15-2009, 12:42 PM

Trev, my cusdom spell file is designed under Titanium.
the Spell table in DB is deisgned under SoF

are there mututaly exclusive properties between the two?
Can I source the T-spells into Db wihout problem, or does the spell structure layout different for SoF spells?

**cavedude** · #2 06-15-2009, 04:35 PM

Trev, would you mind zipping up and posting your spells_new file? I've never been able to get spell loading from the DB to work and it looks like the problem still exists. I want to rule out the DB first and go from there.

On a side note, once this is resolved I agree 100% with the change. Editing spells in the DB is far far easier and faster than that stupid flatfile.

**Derision** · #3 06-15-2009, 04:43 PM

After Rev664 my server was crashing on loading spells with my copy of the PEQ DB due to NULLs in some spell entry columns. From my .mysql_history, this is what I had to do to get the spells to load:

Code:

update spells_new set teleport_zone='' where teleport_zone is null;
update spells_new set you_cast ='' where you_cast is null;
update spells_new set other_casts ='' where other_casts is null;
update spells_new set cast_on_you ='' where cast_on_you is null;
update spells_new set cast_on_other ='' where cast_on_other is null;
update spells_new set spell_fades ='' where spell_fades is null;

**cavedude** · #4 06-15-2009, 04:46 PM

Ah ha! Thanks Derision, I was just about to reboot the server with spell logging on you just saved me some time

**trevius** · #5 06-15-2009, 04:58 PM

Actually, this is one of the reasons why the spells table is so great. The scripts can work to import any type of spell file from any client even up to EQLive if you wanted. Even though the older clients lack the newer fields, the scripts and table are setup to work with any number of fields and just fill in default values for fields that are missing in the spell file that is imported. The good part is that spell files are backwards compatible. This means that if you then export your spells table back into a new spells_us.txt file, it will then work with any client version. The spell files are not forward compatible, so a Titanium spell file will not work for SoF. But, if you do the import/export, you can essentially convert a Titanium spell file to be compatible with the SoF client so all clients can use a matching spell file and also match the server.

**Derision** · #6 06-15-2009, 05:11 PM

So I guess it should be possible to import the current Live spells_us.txt file into the DB so I can try and implement the Armor of Experience and Resupply Agent Veteran AAs ? (or at least just insert those two spells).

Zeice · #7 06-15-2009, 05:37 PM

The only thing I've noticed is that the .pl files aren't compatible with perl 5.10...I upgraded a while back since 5.10 was supported in compiling. So whenever I try to run those scripts it says that it cannot find the perl58.dll. Any easy fix for this?

**trevius** · #8 06-15-2009, 06:10 PM

Hmm, I don't know a ton about the perl version difference stuff. But, AndMetal wrote the scripts so maybe he would have an answer or can submit a fix to the SVN for those files if one is needed. You may even be able to download a version of perl that has that perl58.dll file and just put it in the right windows folder for it to work.

Andrew80k · #9 06-15-2009, 06:27 PM

Quote:

Originally Posted by Zeice

The only thing I've noticed is that the .pl files aren't compatible with perl 5.10...I upgraded a while back since 5.10 was supported in compiling. So whenever I try to run those scripts it says that it cannot find the perl58.dll. Any easy fix for this?

Hmmm. That's interesting. Perl is Perl. It shouldn't require compatibility...but if you are using a windows system (ActiveState Perl) it is possible that one of your modules, like DBD::Mysql, was downloaded using 5.8 and didn't get updated for 5.10. It would probably throw those types of errors. Check those and see if that is your problem. Off hand I don't know which modules it uses though.

ChaosSlayerZ · #10 06-15-2009, 07:08 PM

Quote:

Originally Posted by trevius

Actually, this is one of the reasons why the spells table is so great. The scripts can work to import any type of spell file from any client even up to EQLive if you wanted. Even though the older clients lack the newer fields, the scripts and table are setup to work with any number of fields and just fill in default values for fields that are missing in the spell file that is imported. The good part is that spell files are backwards compatible. This means that if you then export your spells table back into a new spells_us.txt file, it will then work with any client version. The spell files are not forward compatible, so a Titanium spell file will not work for SoF. But, if you do the import/export, you can essentially convert a Titanium spell file to be compatible with the SoF client so all clients can use a matching spell file and also match the server.

Trev if i read you right- what you saying I am screwed cuased my spell file is not compatebale with DB. WHich means all my custom spells just went out of the window

Also I don't see why people saying that DB is easier to edit- have you guys tried Bleh editor?

**trevius** · #11 06-15-2009, 07:35 PM

When I said that the table is great, I meant just that! It is fully compatible with all spell file types, so your spell file will import into it just fine.

I do agree that the ailia/bleh spell editor is by far the best way to edit the spells until you are really familiar with the table/fields. I am hoping that at some point, someone will be able to port the ailia/bleh editor to work with the database table, because that would really be awesome and is one of the reasons I think we were holding off on moving to the table. I wonder if ailia or bleh would be willing to take a look at making the switch for the tool, or giving out the source code so others could do it.

You can always export your spell table back into a file format and then use the ailia/bleh editor and once you are done just import it in again. It is extra steps, but it would still work fine that way.

The reason people like the table for editing is because it is easy to edit remotely so other devs working on the same server can all have access to edit spells if needed. Also, I am sure it wouldn't be overly complex to get a PHP webtool created at some point to allow for webpage based spell editing.

Zeice · #12 06-15-2009, 07:48 PM

Quote:

Hmmm. That's interesting. Perl is Perl. It shouldn't require compatibility...but if you are using a windows system (ActiveState Perl) it is possible that one of your modules, like DBD::Mysql, was downloaded using 5.8 and didn't get updated for 5.10. It would probably throw those types of errors. Check those and see if that is your problem. Off hand I don't know which modules it uses though.

Yep that was it. I feel a little stupid now lol. Thanks. =)

ChaosSlayerZ · #13 06-15-2009, 08:01 PM

wel If It works.. It will be good =)
We can always bug George to make a DB side spell editor for us

**cavedude** · #14 06-15-2009, 08:01 PM

Quote:

Originally Posted by trevius

The reason people like the table for editing is because it is easy to edit remotely so other devs working on the same server can all have access to edit spells if needed. Also, I am sure it wouldn't be overly complex to get a PHP webtool created at some point to allow for webpage based spell editing.

Actually, I plan on adding spell editing to the PEQ PHP editor down the road. AAs and items are ahead in the queue, however. But, the reason I like the DB over the flatfile personally is it's a hell of a lot easier and faster to edit spells using MySQL queries. I rarely use guis for anything, partly because PEQ has no gui, and partly because I am just a lot more comfortable at the prompt.