Crazy idea for spells...

[AndMetal]

Originally Posted by John Adams

Thanks AndMetal, sorry if my initial post sounded all assy.

Np

It's probably something worth mentioning in the changelog, since the structure of the spells (for shared memory) changed since we discovered some of the unknown fields, I just haven't gotten off my lazy ass to update it, lol.

[KLS]

How has this been working since the initial stumbles? Flawlessly I hope?

If it's working well I actually have an idea I'd like to implement next time I get some free time dealing with this (sekret idea but it's really cool trust me).

[trevius]

Well, the new DB Spells might be working ok, but I found a major issue with the current SVN revision that basically breaks spells if you try to use the old spells_us.txt way. The spells all still cast properly, but for some reason, they take 4X as long to cast either from items or just from casting a spell. There were so many changes that went in with the new spell changes AndMetal made, that I don't have any idea where to start looking for the cause of this.

I will probably move to the new DB version soon, but as long as the old way still exists, it should at least work :P

[AndMetal]

Originally Posted by trevius

Well, the new DB Spells might be working ok, but I found a major issue with the current SVN revision that basically breaks spells if you try to use the old spells_us.txt way. The spells all still cast properly, but for some reason, they take 4X as long to cast either from items or just from casting a spell. There were so many changes that went in with the new spell changes AndMetal made, that I don't have any idea where to start looking for the cause of this.

I will probably move to the new DB version soon, but as long as the old way still exists, it should at least work :P

I just did quite a bit of testing with SVN Rev 232 & 235 using the unmodified Titanium spell file, trev's slightly custom spell file, and an outdated version of Live's spell file and have yet to reproduce the casting delay either by casting from clickies or from the spell bar. For the clickies, I used a Brown Ornate Chain Bridle & Fabled Jaundiced Bone Bracer. I also used a combination of Ice Age & Greater Immobilize for casting spells.

The only thing I can think of is if there was a problem sourcing the spells into the database.

I've said it before, I'll say it again:

Originally Posted by AndMetal

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...

[trevius]

Oops, it looks like the issue must somehow be on my end. Sorry that I was too quick to assume that the spell changes you made were the cause of it. Apparently, it is an issue with the test server I am running and it happens in all builds I have tried so far and I don't know why. The test server is a Debian build running on VMWare on my Windows PC. I don't think that should cause a problem, but who knows? The only thing I suspect is that it could be due to me running 2 servers at the same time from the same internet connection. I know I can't forward the required ports to the server needed for players to log in, but it works fine for me to log in, since I am on the same LAN and don't get restricted by ports. Maybe I somehow missed something else important in the build, but I have never heard of this issue before.

I did a bit more testing on it and it seems that spells are taking exactly 7 times longer to cast than what their cast time says on the spell or clickie item. I have no idea why it is 7X, but that is what happens every time for all spells. I have tried both the old spells file way and the new DB spells way and both have the exact same issue. That is an issue for another post though, so I am not asking for answers in this one.

Sorry to derail the thread and my apologies to AndMetal for making an assumption without better testing.

To keep this somewhat on topic, I must admit that it is awesome to be able to sort the new spells table by any column to quickly check for certain things in spells. It made finding all of the mounts in the file a very simple and quick task. Once a tool comparable to the Ailia/Bleh spell editor is created for working with the new DB spells, I don't see any need to keep the old system around. I am sure we will find even more benefits from it soon.

[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

[ChaosSlayerZ]

Trev, isn't the both codes allready there for #define to be used?

binaries wise - they stil were using spells.txt as of R535 i last dowloaded - how else would i have been using my own spells =P (speaking of which its time to update the binaries on the oficial site)

unfortunately i don't have option to do my own compile =(

ALso what kind of loading script you refering to - could you post a sample?

[trevius]

Everyone has the option to compile their own source. It is only a matter of taking the time to figure out how to do it the first time :P

The import/export scripts aren't included with the Binaries yet as far as I can see, but when this change goes in, they should probably get added to the Binaries. Otherwise, you can get the import and export scripts by downloading the source code through the SVN, as it comes with it in the main directory there.

Here is some more information on the import/export scripts and how to use them. It is in this very thread we are in right now:

http://www.eqemulator.net/forums/sho...t=24193&page=3

See post #45 by AndMetal

[ChaosSlayerZ]

Originally Posted by trevius

Everyone has the option to compile their own source. It is only a matter of taking the time to figure out how to do it the first time :P

well as you could see number of downloads of ready binaries is well over 200 =P so as you see people far from comfortable of compiling their own source =P