EQEmulator Forums
Page 3 of 3 12 3
Show 40 post(s) from this thread on one page

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Development::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=590)
-   -   Crazy idea for spells... (https://www.eqemulator.org/forums/showthread.php?t=24193)

cavedude 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 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 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 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 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 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 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 06-15-2009 06:27 PM
Quote:
Originally Posted by Zeice (Post 172201)
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 06-15-2009 07:08 PM
Quote:
Originally Posted by trevius (Post 172193)
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 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 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 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 :D

cavedude 06-15-2009 08:01 PM
Quote:
Originally Posted by trevius (Post 172216)
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.

Randymarsh9 07-12-2009 10:22 PM
Quote:
Originally Posted by erik_llewellyn (Post 163031)
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


All times are GMT -4. The time now is 09:16 PM.
Page 3 of 3 12 3
Show 40 post(s) from this thread on one page

Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.