Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Database/World Building

Development::Database/World Building World Building forum, dedicated to the EQEmu MySQL Database. Post partial/complete databases for spawns, items, etc.

Reply
 
Thread Tools Display Modes
  #1  
Old 12-09-2006, 04:52 PM
WildcardX
Developer
 
Join Date: Apr 2003
Posts: 589
Default

A little more info about this bug...

Until now I thought the zone the client wanted to zone me to was just random, but I have noticed that it isn't random at all. In fact, I think it is the result of the servers Zone::GetClosestZonePoint() method. I'm not sure I completely understand the details of the mechanics involved here, but I know when I zone into VexThal and the last zone I was in was Misty (I was in Misty on a #zone command so I was standing by the newbie guards on the far side of the zone near Clan Runnyeye (however it is spelled... I hate goblins), when I try to walk into vexthal from the zonein, the client at random will decide to zone me out and in this case it will say I am zoning to Clan Runnyeye... If I was in UP and standing near the Maidens Eye zone when I #zone to Vex Thal, then it will say I am being zones to Maidens Eye... I think this might be signficant only because the object used to by the server to calculate a place to send me to cancel the unsolicated zone request I believe has data from when I was in Misty even though when the client tried to unsolicate zone me out, I was in Vex Thal, not Misty.

Sorry if this sounds confusing and if I can clear any of this up better for you, please let me know.
__________________
Read my developer notes at my blog.

Quote:
If it's not on IRC, it ain't l33t!

Last edited by WildcardX; 12-10-2006 at 12:57 AM..
Reply With Quote
  #2  
Old 12-09-2006, 05:20 PM
WildcardX
Developer
 
Join Date: Apr 2003
Posts: 589
Default

Even a little more info...

Once a player gets caught in this infinite zoning loop in vex thal, the player has no choice but to kill their client and restart EQ and log back in. Once they log back in, if they just keep going deeper into Vex Thal, they can, in effect, "camp out past" whatever the point is in the client that wants to send the unsolicited zone request.

And I can confirm the physical point in the zone where the client wants to send the Unsolicated Zone message is ALWAYS the same loc.
__________________
Read my developer notes at my blog.

Quote:
If it's not on IRC, it ain't l33t!
Reply With Quote
  #3  
Old 12-09-2006, 05:36 PM
John Adams
Demi-God
 
Join Date: Jul 2006
Posts: 1,552
Default

Fwiw, I was poking around The Nest one day and stepped off a cliff, and got into the same zone loop, had to kill the client to escape. Tried to make it happen again, and the second time I just fell to my death as expected. Couldn't reproduce, and didn't think to check logs at the time.

Letting you know I've seen it other than VT.
Reply With Quote
  #4  
Old 12-10-2006, 01:53 AM
bufferofnewbies
Hill Giant
 
Join Date: Dec 2005
Location: Lurking in KY
Posts: 239
Default

It's my weak theory that:

the error in VT is that most of the zoneins (default is at least) actually sets you behind their 'built-in' zoneline. so even when you are technically 'in ' the zone, movement still puts you into the space that the client tells the server you are attempting to zone. They might have specifically put 0, 0 location there to prevent anyone from useing the old zone viewer program to spoil the effects of the new 'big zone'.

Just in this case you are 'attempting' to zone into vex thal, and for some reason.. since you are already there, it errors out and cycles you over and over. I believe it is something about the code that requests current position vs. intended position. And since it is the same zone, it errors out for location.

But, thats just my weak theory with no support.
I wouldn't try to buy a newspaper with it.
Reply With Quote
  #5  
Old 12-10-2006, 01:38 PM
wraithlord98
Sarnak
 
Join Date: Oct 2002
Posts: 53
Default

That's most likely the problem.. question is - has anyone tried "tweaking" the zone in point to see if it corrects it?
Reply With Quote
  #6  
Old 12-10-2006, 02:02 PM
cavedude's Avatar
cavedude
The PEQ Dude
 
Join Date: Apr 2003
Location: -
Posts: 1,988
Default

It's not the zone in point for VT, it's as you are walking down the hallway. All data has been removed from that zone and it still does it. Very odd.
Reply With Quote
  #7  
Old 12-10-2006, 02:30 PM
Dymerius
Sarnak
 
Join Date: Oct 2004
Posts: 74
Default

I have this issue when zoning from HHP to HHK also. If you time it right, you can modify the zone in the characters table and prevent the client from having to kill the application.
Reply With Quote
  #8  
Old 12-10-2006, 03:11 PM
bufferofnewbies
Hill Giant
 
Join Date: Dec 2005
Location: Lurking in KY
Posts: 239
Default

Quote:
Originally Posted by cavedude
It's not the zone in point for VT, it's as you are walking down the hallway. All data has been removed from that zone and it still does it. Very odd.
That is what I mean by a 'hard-coded' zoneline. For another example, remove the zonelines from south karana and run across the bridge. It will set you into a zoneing process also. I know most of the old world zones are set like this, but also many of the newer ('newer than old world') ones are also.

Quote:
Originally Posted by wraithlord98
That's most likely the problem.. question is - has anyone tried "tweaking" the zone in point to see if it corrects it?
This is really the only way to 'default' around the hardcoded zonelines. Best bet is to put the zonein point much further up the hall, or into the first room.
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 09:00 AM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3