Infinite Zoning Loop

[WildcardX]

FNW,

There is a problem at the zone in of Vex Thal that causes a player to go into an infinite loop zoning. I use to think it was a problem in the database, but after an exhaustive search, I have been able to rule this out as a possibility based on 2 facts.

1. This bug will happen in a naked vex thal zone (ie no mobs, no doors, no traps, etc).

2. This bug is random. I have seen this bug happen on the same database with the exact same datasets and then after a reboot of the client, I have seen the bug not appear and I am able to walk into vex thal from the zone in.

I noticed messages in my debug log that records an "Unsolicited zone request..." and after looking into the source code, I can see the logic where the client sends an UnsolicatedZone message to the server, the server is unable to determine the nearest zone point to send me out of (vex thal has no zone points records) so the server then attempts to send me right back to where the client was sending me from (vex thal) and then the client sends me back out again as an UnsolicatedZone message and the whole thing just keeps on repeating.

The question here is why is the client just deciding at random to send me out via an UnsolicatedZone request? I hope it's not anything funny hardcoded into the client that is specific to this zone.

I'd appreciate any thought you may have on this matter. Thank you in advance!

[WildcardX]

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.

[WildcardX]

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.

[John Adams]

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.

[bufferofnewbies]

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.

[wraithlord98]

That's most likely the problem.. question is - has anyone tried "tweaking" the zone in point to see if it corrects it?

[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.

[Dymerius]

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.

[bufferofnewbies]

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.

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.

[WildcardX]

That is about the only thing I have not tried yet. I will try that immediately and report back here on what I find. Thanks for the tip!

[WildcardX]

I ran the following queries against my world database and I got mixed, but promising results.


update zone set safe_x = -1589.6, safe_y = 371.3, safe_z = -40.4, canbind = 0 where short_name = 'vexthal';
update zone_points set target_y = 371.3, target_x = -1589.6, target_z = -40.4, target_heading = 64.9 where id = 785;


After a quick reboot of the server, I found I can #zone vexthal and zone in to the updated coordinates and everything is great.. no problems.

But now here is where it gets.. odd. I zoned out to umbral plains and then zoned back into vexthal like a player would, except I didn't zone to the coordinates specified in the query above. Instead it lands me at the original zone in coordinates that were in the database before I updated it. And, of course, then I run into that same infinite zone loop.

I'll test this more tomorrow.

[bufferofnewbies]

check doors table
field id:
# 8917

someone might have set the zone as a door also, and it could be triggering before the zoneline does.

[WildcardX]

Ok I took the time to measure what I am going to call the zone line that is hard coded into the client for vexthal.

This zone-line begins at:

x = -1639.5
y = 372.8
z = -40.4

It ends at:

x = -1419.1
y = 343.0
z = -40.4

Based on this data, the best solution I came up with is to take the advice to move the zone-in point further into the zone, past this hard coded zone-line. I propose doing so with the following queries, which are based upon the PEQ Luclin Release database.


update zone set safe_x = -1400, safe_y = 343, safe_z = -40.4 where short_name = 'vexthal';
update zone_points set target_y = 343, target_x = -1400, target_z = -40.4, target_heading = 64.4 where id = 785;
update doors set dest_x = -1400, dest_y = 343, dest_z = -40.4, dest_heading = 64.4 where id = 8917;
insert into zone_points (zone, number, target_x, target_y, target_z, target_heading, target_zone_id) VALUES ('vexthal', 1, -741, -1451, 12, 253, 176);


Your mileage may vary on other world databases...

Thank you to all of you who responded to this thread and shared your knowledge with me. I couldn't have solved this problem as nicely as I did without your input.

[bufferofnewbies]

Good show. I'm glad you got it to working.
Now to steal your code cause I'm really lazy...

mwhaha
:D

[WildcardX]

I moved this thread because it's clear to me now that this bug isn't a bug in the EQEmu server code, but rather just a mechanism behavior of the EQ client.

[Angelox]

Just as a "quick solution" here's what i've done to solve this tell someone can figure it out -
I had this problem at one of the oow zonelines, I think it was bloodfields to draniksscar. I placed a "zoner" npc before this happens.
Just a tiny, invisible (race: invisible man), untargetable, and hidden npc, that uses quest::movepc automaticaly as you approach the zone line.
Probably sounds very "assenine", but works very well, and you'd never know it was there unless you were the one that put it there.

[John Adams]

Silly me. I thought that *was* the solution for adding zone lines. :)

[bufferofnewbies]

Sorry for a lack of updates on my end. Been busy with some RL things and havent had much of a chance to get into the emu scene. Still suffering from 'coder block' when it comes to my own server's development. I will look into this, but cant make any promises until after New Years. I probably wont have many updates until then, as alot is going on at this end.

Will try to fix the zoneline for you to automatically pop people back in, unless you can give me a zone/loc of where that zoneline is supposed to take you. (I didnt play during those expansions, so no idea what connects to what and where they connect thru)

Actually, those of you who have made these invisible port people: If you have the time, can you give me a list of which ones you have made and what purpose they serve? I will try to go thru the system and set zonelines up where I can instead of the workaround.

[Angelox]

Sorry for a lack of updates on my end. Been busy with some RL things and havent had much of a chance to get into the emu scene. Still suffering from 'coder block' when it comes to my own server's development. I will look into this, but cant make any promises until after New Years. I probably wont have many updates until then, as alot is going on at this end.

Will try to fix the zoneline for you to automatically pop people back in, unless you can give me a zone/loc of where that zoneline is supposed to take you. (I didnt play during those expansions, so no idea what connects to what and where they connect thru)

Actually, those of you who have made these invisible port people: If you have the time, can you give me a list of which ones you have made and what purpose they serve? I will try to go thru the system and set zonelines up where I can instead of the workaround.

I can tell you right off the bat, none of the OoW zones work - they just "look" like they do. And also, the zone from gunthak to stonbrunt too.
But more important - if you know how, and have the time, I'm in great need for a fix on the quest_globals problem.

[bufferofnewbies]

I cant even spell C++, let alone use it.

I just know how to do smaller things with databases atm, actual changes to the emu code are well beyond my current capabilities.

[bufferofnewbies]

I had a few moments to check things, and since you were doing some LoY updates I figured I'd look into your boat door.

As far as I can tell, the door you have on your boat works (door number 8 for gunthak). I removed your teleport guy and jumped in to see. Aside from errors on my side (I have been moding my client a small bit for my own tests), nothing showed up in error.

I don't remember which version of your dbase I have here (it's not the most current, it is from back when I downloaded it to check something for you), but if anything you have an excess of doors that lead to stonebrunt in the database. Off the top of my head, I think I counted about 12 or so of them. Not sure where they are all at, but I know you have two different boat door sets loaded on mine, both seeming like they should be working. (offset on the doors was very very tiny, so they are practically set inside each other)

Sorry I wasn't able to identify anything wrong at this point, only had about 10 minutes to set this up to check before I get drug back into the holiday stuff. If it still isnt working on your end w/o a TP guy, I will load your newest dbase up and check it out when this end is less hectic.

And zonelines are inc.. I promise. Just takes so long to do them, that I havent even started yet. I seem to have just enough time to log in to check updates on the eqemu sites before I'm drug off into neverneverland again. And a half-finished zoneline fix is more confusing that a fresh start.

Oh, one last thing, if it's not too much of a problem: Think you could send me a list of the keys in TOFS that go to the doors. I will try to match them up, but not really sure what they are called so I can't look them up for ID numbers. Will try to set those asap after New Years for you.

Peace out.

[Angelox]

This is imporatant and would be nice to have fixed;
TOFS Keys
Crystal Key - 2nd floor
Three Toothed Key - 3rd floor
Frosty Key - 4th floor
Small Rusty Key - 5th floor
Bone Finger Key - 6th floor
Large Metal Key - 7th floor
Tserrina's Key - Master Key
The top floor (Tserrina's floor) mirrors, those doors don't work right - they all warp you outside the dungeon. They are supposed to take you to different floors with the different keys, or master key ( or maybe just master key?), and one takes you outside.

As for the zonelines, I wouldn't worry about that too much - there's too much other stuff broken that needs fixing, with very few people fixing them.
A zoner npc works fine, so it drops down on the "todo list" tell all the other stuff gets fixed.

[John Adams]

As for the zonelines, I wouldn't worry about that too much - there's too much other stuff broken that needs fixing, with very few people fixing them.
A zoner npc works fine, so it drops down on the "todo list" tell all the other stuff gets fixed.
Don't take this the wrong way, but this is what I am talking about. Dismissing someone elses bug finds as "unimportant" will end up with people not helping at all. If buffer spent the time to troubleshoot and identify a fix, maybe it deserves more than being dismissed?

If I kept reporting bugs that never got any attention, I'd stop reporting bugs. No matter how insignificant.

[bufferofnewbies]

I wasn't sure which mirror went where on the top floor, so I started on the left and sent them to floor 1, floor 2, in that order.. up to floor 6. If that's wrong, just let me know the order and I will change it. I reset the mirrors on the top level to correspond to locations of where the other mirrors send you (except for the first one.. which is at zonein) and locked them with keys also (again, except for the first one).

The master key wont work to open any floors except the first floor one that sends you to the key room. That's a limitation atm with the emu, only 1 key per door as far as I can tell.

I set these as seperate commands, instead of one stream. So you will have to run them individually until I learn more about the limits of mysql.
As always: backup before you try this, as I code like old people f... well, you can fill in the blanks there.

UPDATE doors SET keyitem = '20039' WHERE zone = 'frozenshadow' AND doorid = '1';
UPDATE doors SET keyitem = '20033' WHERE zone = 'frozenshadow' AND doorid = '2';
UPDATE doors SET keyitem = '20033', dest_zone = 'frozenshadow', dest_x = '660', dest_y = '100', dest_z = '40' WHERE zone = 'frozenshadow' AND doorid = '166';
UPDATE doors SET keyitem = '20034' WHERE zone = 'frozenshadow' AND doorid = '4';
UPDATE doors SET keyitem = '20034', dest_zone = 'frozenshadow', dest_x = '670', dest_y = '750', dest_z = '75' WHERE zone = 'frozenshadow' AND doorid = '167';
UPDATE doors SET keyitem = '20035' WHERE zone = 'frozenshadow' AND doorid = '16';
UPDATE doors SET keyitem = '20035', dest_zone = 'frozenshadow', dest_x = '170', dest_y = '755', dest_z = '175' WHERE zone = 'frozenshadow' AND doorid = '165';
UPDATE doors SET keyitem = '20036' WHERE zone = 'frozenshadow' AND doorid = '27';
UPDATE doors SET keyitem = '20036', dest_zone = 'frozenshadow', dest_x = '-150', dest_y = '160', dest_z = '217' WHERE zone = 'frozenshadow' AND doorid = '169';
UPDATE doors SET keyitem = '20037' WHERE zone = 'frozenshadow' AND doorid = '34';
UPDATE doors SET keyitem = '20037', dest_zone = 'frozenshadow', dest_x = '-320', dest_y = '725', dest_z = '12' WHERE zone = 'frozenshadow' AND doorid = '168';
UPDATE doors SET keyitem = '20038' WHERE zone = 'frozenshadow' AND doorid = '44';

Let me know if anything is screwy, else I'm off to the zonelines to fix them.
edit: spelling errors, argh!