What is the deal with Highpass

[provocating]

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.

[07-14-2015 :: 18:55:17] Zoning 'Provocating' to: highpasshold (407) - (0) x=-318.170013, y=-108.790001, z=-21.420000

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.

[Nightrider84]

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.

[joligario]

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.

[knowom]

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.

[provocating]

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.

[Nightrider84]

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.

[N0ctrnl]

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.

[provocating]

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.

function event_spawn(e)
	local xloc = e.self:GetX();
	local yloc = e.self:GetY();
	local zloc = e.self:GetZ();
	eq.set_proximity(xloc - 20, xloc + 20, yloc - 20, yloc + 20);
end

function event_enter(e)
	if (e.other:GetClientVersionBit() <= 2) then -- #062/Titanium
		e.other:MovePC(5, 105, 63, 3.75, 128); -- Highpass
	else
		e.other:MovePC(407, -314, -113.79, -21.42, 160); -- Highpasshold
	end
end

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.

[provocating]

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.

[N0ctrnl]

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

[Nightrider84]

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.

[provocating]

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.

Zoning :: zoneid:5 instid:0 x:91.00 y:-979.00 z:4.00 h:14.00 zonemode:4 from zoneid:20 instid:0

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.

[Uleat]

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?

[provocating]

Originally Posted by Uleat

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

[Uleat]

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