Mixed-up zone points with 0.5.2 db.sql

[Drawde]

I'm encountering a strange problem with the zone points in the 0.5.2 db.sql.
They all work, and are in the right place, but their destination zones and/or locations are mixed up.
For example:

Butcherblock-G.Faydark goes to Dagnor's Cauldron
Dagnors-Butcherblock goes to Kedge Keep
N Qeynos temple teleporter (this is a zone point, just one that goes to the same zone) goes to Qeynos Aqueducts
N Qeynos-Qeynos Hills goes to Qeynos Hills, but to the W Karana zone point, not the N Qeynos one

This is using the 0.5.3DR3 binaries. The zone point and zonepoint_raw data in the DB is from the 0.5.2 db.sql, not
from my DB or anyone else's.
However, I also encountered this problem with the latest MyWorld DB.

Anyone else experiencing this problem? Is it a DB problem, or a code one?

[wize_one]

zone_points is one of the things being worked on in the MW database. dont have a eta when that patch will be complete, but it is being worked on..8)

[Edgar1898]

read this post:

http://www.eqemulator.net/forums/viewtopic.php?t=12724

It should explain why thats happening and how to fix them. Let me know if you have further questions.

[Drawde]

So what can I do to fix it? Wait for the final 0.5.3 version to be released?

Zoning worked OK in previous EQEmu versions with most zone points. The current problem isn't that you can't zone, but that you get sent to the wrong
destination. This appears to happen both with hard-coded zone points and those stored
in the EQEmu DB.
From reading the post it sounds like one of the opcodes relating to zoning has changed in the
EQ client, and this is what's causing the mix-up problem.

[Edgar1898]

What are you talking about? You obviously didnt read all the posts from the link, so I'll be nice and post it again.

Whenever you login to the zone the zoneserver sends all the zone points to the player. Whenever the client runs into these zonepoints (most are hard coded) the client tells the server that it wants to zone. The problem is that it doesnt tell the server which zone point the client is using, so the server relies on the players position to determine which one the client used and the correct place to send them based on the coords in the database for the particular zonepoint. The x,y,z coords are the coords that the zonepoint itself is located at, it doesnt have to be exact but it needs to be close. The target_x,y,z coords are used by the server to tell where it should send the player once they have zoned. Its a little difficult to explain, but I'll give you an example:


id | zone | number | y | x | z | heading | target_zone | target_y | target_x | target_z | target_heading
341 | gfaydark | 4 | 2608 | -53 | 16 | 0 | crushbone | -660 | 162 | 4 | 999
345 | crushbone | 1 | -660 | -162 | 4 | 0 | gfaydark | 2608 | -53 | 16 | 999



Now as you can see the zonepoint in gfay is physically located at 2608,-53,16 (y,x,z) and whenever someone goes over it, they are zoned into crushbone to -660,162,4 (y,x,z) the heading of 999 tells the client to keep whatever heading it was using when it zoned. Now if you didnt have the right x,y,z the server would try to find the closest zone point, which might NOT be the correct one and it would send you somewhere else.

[Drawde]

Sorry for being stupid.. I've found the source of the problem now, and I think I've fixed it - the default
DB zone points (which I was using) have some incorrect coordinate values, some being set to things like 9999.
I've updated the zone points from my DB addon to 0.5.3 format, and loaded them and they now all seem to work OK
(i.e go to the right place).

However there is another zoning-related bug I've encountered, where zoning will occasionally lock up the EQ client (but not the EQEmu
server). There is an error message which appears in the zoneserver window when this happens, something like "invalid zone number, sending character to arena"
though when you re-start the client, the character that caused the crash is NOT in the Arena zone, but in the correct destination zone.
This appears to be random, and not caused by any particular zone line.

[wize_one]

thats the zone_id=0 error..there is a couple posts somewhere on how to fix it(will need to recompile).

it happens if you try to zone into a empty(non-static zone). if the zone has someone in it already, or is a static zone, you wont get the client crash.

[Lurker_005]

the default
DB zone points (which I was using) have some incorrect coordinate values, some being set to things like 9999.

The 9999 should designate to keep the clients value from the previous zone. If this is used where that value does not match for both zones you have problems. But it is needed for zone lines like east commons to west commons.