Infinite Zoning Loop

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

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.

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.

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