Once you learn how to compile your own source, it's pretty much just as easy as downloading a pre-build binary, but gives you the option of making changes to the code.

This page has all the info you should need for learning how to compile it on Windows:

http://www.eqemulator.net/wiki/wikka.php?wakka=VS2008

Or, you could setup a Linux server and make compiling as easy as typing "make" :P

IMO, if your main concern is having options, then you should take the time to figure out how to compile your own source. If you are not worried about options, then just use the Binaries and you will still have plenty of options but not as many as compiling yourself. Your main concern has been options for so long, you should have learned how to do this long ago! There is only so much we can do to give options with Binaries, but with compiling yourself, the options are practically limitless :P

well i will do my best to swith over to my own compiling, but just want to tell you to give other people advance warning that their custom spell file may stop working soon and then they will be all over the forum going "WTH?" =P

So i urge you to release CURENT last Rev in spell from txt format, and swith to Db spells AFTER that, and put a warning into changelog

There will definitely be a warning about it in the changelog. The change is simple enough that Cavedude could change it to the file loading before compiling the next Binaries if needed. But really, if you want to stay current with the EQEmu updates, there is always going to be 1 thing or another that needs to be adjusted whether that be database changes or whatever. We can't support all legacy options indefinitely or it would be very hard to make good progression with it. I think the change from the spell file to the database is a very good one. Sometime soon I would like to get some new features added that will really make use of the benefit of having spells in a table vs in the spell file.

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?

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.

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:

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

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.

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

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?

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.

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.

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?

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.