Resinstalling old server- weird issue

[ChaosSlayerZ]

Ok people, here is what I have, hope you could advise me.

I have restored my server which i was running about 2 years ago.
I have my DB and the server build that matches it - 535 - yeah that old
They were backup on the last day I used the server, so I know they worked nicely together.

I have reinstalled Perl 5.8 (also from that time to match build 353)
and MySQL server 5.5.11

Now i use to run the server on Minilogin, but today i tested it both ways - on Mini and on Public login, and I am getting same issue:

1. When I log into my account, into char selection screen, and try to log in any of the chars there that already existed in the DB, I get "Zone is Unavailable" error.
In my dos window for world server it shows "trying to boot up zone.." and nothing happens

2. If I try to create a new char, the client gives "Name was rejected"
and in the world server window I see following error message:

error #1364 Field 'mailkey' doesn't have have a default value

I have checked my char table in DB - and I do have this column, and some of the char even have values in it

Another interesting thing that, the char that i did NOT tried to login have the mailkey column EMPTY, while those that I tried to lig in but failed (zone unavailable error) now do have some mailkey value set.

the server is run of Win XP.
I have tried to log in from SAME PC as server installed on via localhost, as well from a different PC on a network via public login - nothing changes, so its not a port issue i believe (with port issue people don't even get to char screen, but i do)

Any ideas?
thanks!

[Capheus]

The only times I've remembered seeing this problem was:

1. Problem in the /maps directory
2. Problem or missing info in the Zone table

[ChaosSlayerZ]

well my map files where they always were - nothing changed
zone tables looks fine and everything

[Derision]

http://eqemulator.org/forums/showthread.php?p=164157

Alter the 'mailkey' column in the character_ table to have a default value of 0, or try installing an earlier version of MySQL (5.1 ?).

Altering the mailkey column should get rid of 'error #1364 Field 'mailkey' doesn't have have a default value', however there may be other incompatibilities in MySQL 5.5 that are causing other issues.

[lerxst2112]

You should look through your logs to see why zones aren't starting.

For the mail error, that error doesn't seem to exist anymore in the current source. Look in your rule_values table for Chat:EnableMailKeyIPVerification and try setting it to false if it isn't already. You could also look at the description for the character_ table and make sure mailkey is char(16) not NULL with a default value of 0.

Any particular reason you're working with such an old server? It's going to be really hard to troubleshoot.

[ChaosSlayerZ]

the reason I am working with build 535 now, is cause my DB is from the same time frame.
I don't want to go upgrading server/Db until I get everything working as it was.

On mySQl version - yeah I installed modern version which could be a problem, considering server/db is 2 years old.
I will go and install older mysql and report back on it

Also The only other thing that shows up in error log is : "Loading spawn groups failed." Which is ridiculous and not seem to be connected to other issues at all...
Again could issue with different mySQL versions...
Will get back to you on this one.

what is the proper command to alter 'mailkey' ?

I see this in a change log file from even earlier times:

ALTER TABLE `character_` ADD `mailkey` CHAR( 16 ) NOT NULL ; ???

[ChaosSlayerZ]

UPDATE: ok I have installed mySQl server 5.085 - which I used to have 2 years ago
results:

-i can now create and delete characters - no more mailkey error

however, I still cannot log into zones :(

the only error in the logs is:

Loading spawn groups failed.

ideas?

[lerxst2112]

Originally Posted by ChaosSlayerZ

Loading spawn groups failed.

Well, I don't have your source code, so I can't look at what that function does in the old version, but now it performs these two queries:

SELECT DISTINCT(spawngroupID), spawngroup.name, spawngroup.spawn_limit, spawngroup.dist, spawngroup.max_x, spawngroup.min_x, spawngroup.max_y, spawngroup.min_y, spawngroup.delay FROM spawn2,spawngroup WHERE spawn2.spawngroupID=spawngroup.ID AND spawn2.version=0 AND zone='crushbone'

SELECT DISTINCT spawnentry.spawngroupID, npcid, chance, npc_types.spawn_limit AS sl FROM spawnentry, spawn2, npc_types  WHERE spawnentry.npcID=npc_types.id AND spawnentry.spawngroupID=spawn2.spawngroupID AND zone='crushbone'

Replace crushbone with whatever zone you like and make sure they both run in whatever SQL tool you use. You can search in your source code for the error message and see what the code does. It's probably close to the same I'd guess. The function I pulled those from is ZoneDatabase::LoadSpawnGroups in spawngroup.cpp.

[ChaosSlayerZ]

I don't have the source code for this neither =)

but i have run your 2 lines.

the 2nd one runs fine
the 1st one gives an error that column 'version' in spawn2 doesn't exist
i suppose it didn't exist back then

if omit the 'version' part - it runs fine

[joligario]

You are missing sql updates. Specifically, that one is present in 612 instances sql.

Edit: Ah, you are working with 535. Disregard.

[ChaosSlayerZ]

well thats the thing - went over change log file- can't find a mention when 'version' column was added to spawn2 table.

if anyone could find me that sql update line, would appreciate

[joligario]

I must have edited my post while you were replying. I noted it above.

[lerxst2112]

If 535 is the revision that your binaries were built from then "version" isn't in the query.

http://code.google.com/p/projecteqem...roup.cpp?r=535

Not sure what else to tell you. If you wanted to, you could retrieve a version of the source code from that revision and rebuild it. *shrug*

[ChaosSlayerZ]

yeah, that the thing both, my server file and my Db were just backup copied of to a safe place over a year ago... They suppose to work as is...
Unless something got corrupted...

well will try to run one of the next in lien rev like 660...

[trevius]

I don't recall offhand which revision it was added in, but if something is wrong with your spells_new table (if your revision uses it instead of the spells_us.txt file), you will get the zone unavailable message. If that happens, you should be able to run the perl import/export scripts for that table to export it, then import it back in to correct any issues like null fields that don't allow nulls. I have had this problem a few times.

If that isn't your issue, maybe enable all logs in log.ini and watch those to see what errors you are getting when zones try to boot up.