Updated today and have naked char's :-)

[Xelaan]

You called it, it says Spells not loaded when I tried to do a #findspell.

When I looked into my DB I can see the spells_new table is populated with 14,000+ rows of data.

Do I need to set something else someplace?

[nosfentora]

yea i was having the same problem and i couldn't figure out why (still can't). i had to recompile my binaries, setting the server to load spells from the files instead of the db table.

i just updated to the 679 binaries, compiled (with database spells) and it works. you may want to either re-download the source and re-compile, or download the compiled binaries.

Someone plz correct me if the pre-compiled binaries are not database spell table enabled.

[Xelaan]

The binaries won't work for me as I am running under Debian Linux. I will try recompiling the 679 release. If that doesn't work where is the setting in the ource to repoint to the spells file instead of the db?

[Xelaan]

I also received this error during compile with the 679 release.

clientlist.cpp:229: error: sort was not declared in this scope
clientlist.cpp:231: error: unique was not declared in this scope
clientlist.cpp: In member function void Client::SendChannelMessage(std::string):
clientlist.cpp:1284: warning: suggest explicit braces to avoid ambiguous else
clientlist.cpp: In member function void Client::ChannelModerate(std::string):
clientlist.cpp:1797: warning: suggest explicit braces to avoid ambiguous else
make[1]: *** [clientlist.o] Error 1
make[1]: Leaving directory `/home/eqemu/source/trunk/EQEmuServer/ucs'
make: *** [all] Error 2

[nosfentora]

No idea about compiling under linux, but what you need to change:


change zone/spdat.h


To load spells from the spells_us.txt:

#define NEW_LoadSPDat
//#define DB_LoadSPDat

to load spells from the database:

//#define NEW_LoadSPDat
#define DB_LoadSPDat

[Derision]

Originally Posted by Xelaan

I also received this error during compile with the 679 release.

clientlist.cpp:229: error: sort was not declared in this scope
clientlist.cpp:231: error: unique was not declared in this scope
clientlist.cpp: In member function void Client::SendChannelMessage(std::string):
clientlist.cpp:1284: warning: suggest explicit braces to avoid ambiguous else
clientlist.cpp: In member function void Client::ChannelModerate(std::string):
clientlist.cpp:1797: warning: suggest explicit braces to avoid ambiguous else
make[1]: *** [clientlist.o] Error 1
make[1]: Leaving directory `/home/eqemu/source/trunk/EQEmuServer/ucs'
make: *** [all] Error 2

I've added #include <algorithm> to ucs/clientlist.cpp in Rev681. See if that compiles for you now. Odd thing is that it compiled fine for me on Gentoo and Windows without that include.

[Xelaan]

I will try the new release.

[Xelaan]

The new version worked once I switched back to using the spells in the DB. The compile error must have been what was tripping me up earlier.

Thanks again everyone, you guys are teaching me a ton and I appreciate it.

[gaeorn]

Originally Posted by Derision

I've added #include <algorithm> to ucs/clientlist.cpp in Rev681. See if that compiles for you now. Odd thing is that it compiled fine for me on Gentoo and Windows without that include.

It's probably a gcc version difference on the linux machines. I ran into this problem but was not sure if it was another odd 64bit difference or not (http://www.eqemulator.net/forums/showthread.php?t=28539).

[Yeormom]

Originally Posted by cavedude

I had the same problem, try:

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;

I ran into this same issue. What is interesting about it crashing in zone/net.cpp when trying to strcpy a null result row is if you change the select statement from order by ascending to descending, it works just fine. This little quark has me scratching my head. :(

Performing a sanity check before copying a null in works just fine but I'm more curious as to what caused this change to appear mroe than anything. Also wish I had not seen the "select *" statement used to populate spells...