need a good zonepoints_raw
 

been trying to work on the zone_points in the database to get them all working right(no more zoneing under world or having client crash due to bad locs).

akanon does not have a functioning zone line
lavastorm to soltemple not working correct(unknown zone, zone back to lava safe point) zone_points has correct info to zone, but zonepoints_raw is not correct.


i am sure there are others those are just the 2 i know about atm

I think the main problem I am having with zonepoints_raw is what format the field zoneline is in. Do we need to packet collect this info? I know how to set the field, but I'm not sure what values are important. I tried to follow the format in this post, but still have not been successful in getting akanon to steamfont to work correctly.

I tried using packet collector yesterday to collect zonepoints but I got disconnected everytime I zoned while running pc, so no luck there. Now I would guess that this info is in the world files, but I haven't explored the idea any further. Anyone else have info on this structure?

Is zonepoints_raw even used? In the DR2 code I have I searched high and low to find anywhere it's used and I couldn't find anything. That's why I coded OpenZone to emit zoneline information for the zone_points table instead.

WC

it's got to be getting called from somewhere...the simple fact that akanon has info in zone_points but yet you can not zone out of akanon..

lavastorm to soltemple..try to zone, you get unknown zone and back to lava safe point though there is good data in zone_points for zoneing to soltemple(have tried zone name and # with no luck.


i really think that it's time to stop being like SoE and throwing out new things and get the bugs out of what there already.

Yea, you can find zonepoints_raw being used in zone.cpp
What is being doen with it....

Well the more I mess with stuff the more I think this is a code issue, not a DB issue. For example, I deleted every entry for lavastorm in the zonepoints_raw table.
Even after doing this I could still zone from lavastorm to sol a, sol b, and nektulos, but still not soltemple. Next, I decided to mess around with the number field in the zone_points table. I changed id 657's (lavastorm --> najena) number to something other than 1.
When I did this I could not longer zone from lavastorm to najena. Instead I would just keeping running right past where the zone line should be. As soon as I changed number back to 1 I could zone perfectly. So that got me thinking that number is pretty important, so I tested this again, but this time with the lavastorm to nektulos zoneline.
Well guess what? It still worked! I set the number to 255. I could still zone from lavastorm to nektulos. So, I took it a step further. I completely deleted that record from the table.
Guess what? Yeah, I still could zone perfectly fine. Except this time I got put somewhere else in nektulos forest, most likely because the server tried to find target_(x,y,z) values and didn't find them, so it defaults to something else. So the number field seems to matter sometimes, but not always. But that still didn't answer my initial question. What the hell is determining when I'm supposed to zone?

It doesn't seem like it is taking this from the DB. Does the EQ client send a packet to the server when it hits a zoneline that is defined in the zone file possibly? Is the client sending a packet but our server isn't catching some of these and that is why we can zone sometimes but not others? I've looked at the code briefly but not enough to follow everything that is going on. I'd like to packet collect on EQLive and see if different packet structures are being sent when you zone from certain zones. The only problem is that when I run packet collector I am getting discconected when I zone. Anyway, I just thought I would share my findings and see if it brings anything out. I'd like to get this zoning issue fixed.

Lurker,
I saw your post a while back about the ZoneLineData_Struct structure. The thing is, I can't even find that structure in the DR3 code anymore.

That was before there was a zone_points table I think that section had a bit of an overhual from 4.4 to 5.0

The packet is probably the same or at least similar, but how EQEmu stores and handles it is definatly different now. If you look at zone_points you sill see that it contains a lot of the data from the ZoneLineData_Struct I posted.