What is the deal with Highpass
 

Of and on for years now I have had complaints about Highpass and looping. Many seem to think it is overlapping zone lines, I am thinking it is not. I have had people say this has happened from Karana and Highkeep. I can never seem to duplicate the issue, no matter how many times I have tried. I had another complaint about it today but when I tried it, at least 10 different times it would not do it for me. I was hoping it was possibly hitting the zoneline at a different location could be causing it, but I have yet to see it myself. I am nearly positive all complaints have been when people are using Underfoot.

If it were the zone line I would think it would be easily duplicated.

If I remember correctly (when I had the same issue), the highpass zone is hard coded. You have to be using the new one (highpasshold) with the newer clients. Either way, it should be showing up in your logs as unsolicited zone requests.

That's just from memory, so I could be off a little.

Yeah I am going to turn on more debugging in my source after this. I will be blowing away all of those zone lines tonight to make sure they do not overlap. I saw a post on PEQ about a possible overlap. If I could for once make my own client do it, that would make diagnosing it so much simpler.

What is really strange is it appears the actual zone line is hard coded? I could move the zone line between East Karana and HighPassHold anywhere I wanted but the zone point always seemed to want to stay at a particular point. I am thinking this could be the entire issue. And yes, I did finally get caught in a loop and the logs were showing an unsolicited zone request.

There are a couple places they did that, but yeah, that's what I found too. I ended up switching to the new highpass and just calling it a day.

I think I solved the problem, but not in a desirable way. I will not argue as long as it fixes the problems for the players and consistently works.

I toyed with the idea of putting an invisible porter trigger nearby. Is that what you did?

Yep!!

Now this is the strange thing that makes me think there is something really screwed up with that zone. If I placed the invisible NPC way toward the back of the the zone, he would quit working. I moved him inward of the zone and he starts working, moved him back and it quit again. But now that everything is placed I really hope this ends the constant "I am in a zoning loop"

I do think I've heard people who work with the client-side zone files say there are occasionally zoning lines set in the zone geometry definitions. I wouldn't be surprised if there were also tight min/max x/y/z coordinates for NPC processing plugged in occasionally for performance optimization on the ollllllld computers that used to run EQ.

Well that NPC would not respond to proximity checks before I moved him, it was very strange.

Do you have all three files in your map folder on the server?
highpass.wrt
highpass.path
highpasshold.map

Yes /10chars

there is a zone_points table and there is/was a 'number' field tied directly to the zone point id. You couldn't change these numbers around because the client had an array of zone points hardcoded. I imagine the zone points added later on they either used the existing zone points or added new #'s in.

http://wiki.eqemulator.org/p?zone_points

I had read the same in the wiki when doing this. I used the original sequence numbers PeqTgc had used. I am nearly positive this is going work well, time will tell, and lots of testing.

An update on this...

The one place I did not zone a player via quest, and just used normal zone lines it happened again today. I will replace those with quest npc's too. But this was in the log. I wanted to just give some more information on it, in case someone else runs into this.

Now this is me zoning. The player in question was a guide, I know for a fact he uses Underfoot like I do. So it was bypassing the zone line and trying to send him to the old Highpass, although he has Underfoot and no Highpass exist.

I had him repeat the same action later and it did not duplicate itself. This has been a highly random occurrence. I will have a player spend hours around Highpasshold and not have an issue, then later they get in a zoning loop.

Yeah the issue lies with it being hard coded to the titanium client. The looping issue is usually when a player with an incompatible client like UF tries to zone into it or you force zone them like with a GM command or a proximity porter. That is the last zone in my list of zones to convert back to Classic. If you change the info in the DB to point players to zone into classic that dont have Titanium even if they take the zone files for the new zone out it just crashes the client. Thats about all the info I have, if you find a way around it please share.

Mixture of everything above. Hard coded lines, zoneline numbers, and highpass vs highpasshold zones, etc. There used to be a bypass to the valid zone request check in the source, but I think I removed that years ago when fixing warp/zone detection. The only fallout to this was the random looping which hasn't been narrowed down (obviously). I'm not able to dig in to find the old lines, but you can always add that bypass back into the source.

Those hard coded zone line loops really suck there are a few others as well if I remember split paw was another. You can manually change the players X, Y, Z and zone info to revert them to another zone manually in SQL DB. It doesn't fix the actual root problem though however.

I'm not sure if maybe extracting the .obj within the s3d version of it with the other could work or not. I had tried some other things like renaming file versions and swapping them, but didn't try anything quite that extreme and involved that involved other programs.

Well I am going to try this and see if it works. If it does not I very well be doing what Joligario recommended. That was my next step. I know it is not a huge ordeal but since every server seems to have multiple threads in their forum "stuck in a highpass zoning loop", I would like to at find a fix that works.

I wrote a guide for the lavastorm and neriak zones, you might use that as a reference when pointing people to the zone. If you manage to fix it send me a message I would really like classic back in my server.

Make sure you look at the highkeep -> highpasshold zoneline if using the new one. I actually had to pull the highkeep zone files out of the SoF client (I think it was SoF anyway) to get highkeep working with highpasshold. The geometry of the zone is still exactly the same, but the zone point to the new HH seems to only work from the updated highkeep file.

On a side note, all these hard-coded zonelines suck. I spent a lot of time getting that all lined out and don't even support the Titanium client now as a result. Just a lot less headache to worry about Titanium doing it different than all the rest.

Wow, now this got really, really strange. I have no zone lines, not trusting them anymore for this zone. Everything seemed fine and then it got strange. Here is a script for an invis NPC.

zone-dynamic_16.log:ESC[33m[Status] Zoning 'John' to: highpasshold (407) - (0) x=-314.000000, y=-113.790001, z=-21.420000ESC[0m
zone-dynamic_19.log:ESC[33m[Status] Zoning 'John' to: northkarana (13) - (0) x=-314.000000, y=-113.790001, z=-21.420000ESC[0m
zone-dynamic_13.log:ESC[33m[Status] Zoning 'John' to: northkarana (13) - (0) x=-314.000000, y=-113.790001, z=-21.420000ESC[0m
zone-dynamic_13.log:ESC[33m[Status] Zoning 'John' to: beholder (16) - (0) x=-314.000000, y=-113.790001, z=-21.420000ESC[0m

So suddenly this poor player starts going to North Karana and Beholder when the script is telling him to go to 407? Notice all of the X Y Z coordinates are the same.

Well a rather smart player figured out the combination of things. He was in East Karana and died, but was bound in HighKeep. If East Karana was the last zone you were in and zone out of HighKeep you will end up in an odd zone. I tried this myself and can repeat it every single time.

I never could make it work quite right and just replaced highpass with highpasshold.

Yeah it's because its hard coded into the client, So unless you fix the clients server side and have a patch system to patch client's that connect, I don't see any other way to fix it. Currently (that I know of) the only way to access old highpass is through Titanium Client.

This thread is not old enough to call this being necro'd but I wanted to add to this. This is not totally an issue with using the old High Keep. This is more complicated and really seems to be an issue with HighPassHold. This is a sure fire way to repeat it.

Go to HighKeep and bind there.
#zone eastkarana
gate back to HighKeep
Now zone into HighPassHold
Now zone back to HighKeep

You will either go into an unrelated zone or a zoning loop. I say it is not totally related to HighKeep because I have personally logged in at Kithicor and zoned into HighPassHold and ended up in Gorge of King Zorb. I have had others end up in Rivervale. I had someone last night zone from Kithicor to HighPassHold and ended up in Zone 5 which is HighPass. Since you cannot go there with Titanium he had to move his character.

I know this has to do with Unsolicited Zoning so I have added some log.out output to help diagnose it down. I am just recording this information here for reference until the problem is resolved.

Before I added the extra debugging I did have some entries in my query server, here is one from last night.

You will see they were in Kithicor and zoning to HighPassHold but the server pushed them to zone 5, Unsolicited. Now myself, I have tried to repeat what the player did last night and I zone perfect. It is some combination of things that causes this.

Any way to get a packet dump?


Take a look at this: https://github.com/EQEmu/Server/blob...zoning.cpp#L87

'GetClosestZonePointWithoutZone()' does check for client version..but, it is possible that something is wrong with the process - or the player's client..wouldn't be the first time.


It does sound like a hard-coded zone-line issue..but, that's just a guess based on the infomation so far.


EDIT: Did this player 'replace' zone files for these zones?

Definitely not. At the moment though, I am redirecting anyone with Titanium and higher to HighPassHold when they request HighPass in zoning.cpp

This is setup using an 'invis' npc with proximity and script handling?

You mean my fix? No I did it in the source. I would not call it a fix yet because these issues are intermittent and not always repeatable, needs heavy testing. I am damned well determined to never see a Highpass zoning issue again. I will get it resolved.