findspell and cast X do not work for all chars all zones after recompile
 

Required SQL's from git repository are sourced.
database shows all spells and spell information.
showspell returns zero's or nothing for spell info
cast X returns nothing and nothing is cast
log shows that spell was attempted to be cast.
used command: #findspell 30 (target=NONE)
spells_en and spells_us are in the server run directory
I'm at a loss here as to what I didn't do.

re-re-compiled version in new database still showing no spells
 

I get "spell ID out of range" on a new character. There are no mobs/npcs in the tutorial(all I've checked)
I copied spells_* to the /server directory from an untouched HoT client install
I'm willing to troubleshoot so my kids can get back to turning all the PoK npc's into raptors :grin:

Usually when spells wont load correctly it's because shared_memory hasn't been rerun since a code or database change.

Spells are loaded from the database, specifically the table: spells_new and then are shoved into a shared_memory segment that all the zones open. Also sorry, spell support gets less traffic than the other support forums so we check it less often.

Thank you for posting, KLS. In this case, it appears the user wasn't telling the truth. I *thought* I had sourced in all required files, but I think the query I was using only sourced in 2014*. After carefully making sure to use the ones with 2013* and forcing them to go in ignoring errors, it seems to have worked. I quickly made a backup when everything was running smoothly.

For any future readers, the required sql's are in ../eqemu/utils/sql/git/required
I sourced them in with these commands:
$ mysql -u eq -p --force eq < 2014*.sql
$ mysql -u eq -p --force eq < 2013*.sql

The '$' means regular user not a priviliged user and the 'eq' before the '<' is the database that the sql files were being sourced in to. There were errors when sourceing. This is why I ran it a couple times. It seems as though some columns that were needed already weren't created until further down in the importing. By this I mean that, let's say the imaginary SQL file 2014_h.sql had a column it created that 2014_g needed. Running the above commands multiple times with the force option made sure that any columns that needed to be made, were, and were populated on the next run-through.

Thanks again, KLS, and I appreciate all the hard work you guys do!