Problem with Zone Geometry/Safe coordinates

[kefka517]

I am having an issue with zone geometry.. This is a brand new server build from the lastest svn of projecteqemu, projecteqdb, projecteqquests and eqemumaps. Sourced the rev.sql file and the load_player.sql file into MySQL. Using the Titanium client to connect. When I #zone into most zones, I start suspended above the ground. In others (such as iceclad), It loops saying that I am under the world and says it is putting me to safe coordinates, and then says I am under the world, etc. I then set my own safe coords using #zsafecoords and that usually will get me out of the loop, but: When I turn on flymode, I can travel a bit, but get stopped by invisible walls.


Any ideas how I can solve this problem or what I am doing wrong?

Thanks,

-Kefka

[VarianTemplar]

Check your eqemu_debug_<ProcessIDNumber>.log file in the $EQEmu-Home-Directory$/server/logs directory - you might find in there a few references to a missing field ("suspendbuffs" field perhaps) on an SQL query in the 'zone' table (apparently the logic fails to the point where it allows a character to zone in, but places them at 0,0,0. So in certain locations like Halas you can move around as long as you don't try to cross an interface like a doorway, a stairway or like the raft and lake between Halas and Everfrost.

Best thing is to review the SQL patches at http://code.google.com/p/projecteqem.../utils/sql/svn and see if you're missing any elements in the zone table.

Do this by first stopping your EQEmu server, than Logging to mysql and issuing the following commands:

use <your EQEmu database name>;
SHOW COLUMNS FROM zone;

Compare the field outputs with the SQL patches from the above link that include the word "zone" in them (you're looking for Table Alterations or Field Updates inside each patch file). If there's a patch out there that wasn't reflected in your zone table, that's the culprit. Patch up by issuing the SQL commands. For instance, I found my rev of the PEQ database (rev1589) was missing the "1618_zone.sql" patch. So I issued the following commands after first having selected my EQEmu database (as above code segment showed):

ALTER TABLE zone ADD suspendbuffs tinyint(1) unsigned NOT NULL DEFAULT 0;
UPDATE zone SET suspendbuffs = 1 WHERE short_name IN ('guildlobby', 'guildhall');

You might want to "FLUSH TABLES zone;" just to make sure it's all up to snuff. Then you can restart your world. Hopefully it was just a misconfigured zone table. lastly, I did a sanity check to validate all the other patches against the other tables and I don't think I found anything else missing from the Rev1598 PEQ db.

I have to admit, even though some of the set up information is fragmented a slight bit - the install with some searching of these forums to find the remedial actions for the small bugs resulted in a fully working world. I am extremely impressed as to the quality of the in-world experience. It's running virtualized quite nicely in Debian 5.x on one of my 2U servers running a VMWare/ESXi hypervisor. If I get some time later in the year, I might package it up as a ready-to-go EQEmu server VM appliance one could run with VMPlayer or other equivalent VM hypervisor (since VMWare not only provides free VM players/hypervisors, they also provide a free up/down converter for various VM products).

[spiritling]

I just wanted to say thank you!

This solved my problem. I was setting up a new server with peqdb_rev1589.sql and I could get everything to work... except when I logged in, I was stuck in place. If I used #zone poknowledge (just an example of a new zone aside from tutorialb), I would then be stuck in that location as well.

Thank you again!