MQWarp/MQZone/MQGate Detector (Code Name: The VZTZ Hammer!)

[KingMort]

Yeah it is disabled but still in some zones people are going into loops, zoning in and out over and over or something... Only started happening after the code went in..

[TheLieka]

Never heard of this one. Is it only certain zones? If so, what zones?

Dax

[cavedude]

I had this looping problem with original code on the forums, however TGC has never had this issue with the altered version KLS put into the official code base. It was the incorrect zone_points in the DB causing it of course (putting in valid coords for both x,y,z, and target_x,y,z corrects this), and I believe KLS removed the zone check in the core code.

[Angelox]

Originally Posted by cavedude

I had this looping problem with original code on the forums, however TGC has never had this issue with the altered version KLS put into the official code base. It was the incorrect zone_points in the DB causing it of course (putting in valid coords for both x,y,z, and target_x,y,z corrects this), and I believe KLS removed the zone check in the core code.

What? I hope not! I've been all week fixing the zones - TheLieka already said what the problem was and what to do (disable in rule_values). This just needs to get all the zone_points fixed and in place; just a little work and I'll have it done in a while. I was planning on posting the fixes(when ready), but if it' out of the source, then it's pointless.

[KLS]

In the official source I still have the check but I took out the forced zone cancel which was what was causing the loop. The detection remained in place.

I'll be up for adding it back in if we can get the zone points completely updated.

[Angelox]

Originally Posted by KLS

In the official source I still have the check but I took out the forced zone cancel which was what was causing the loop. The detection remained in place.

I'll be up for adding it back in if we can get the zone points completely updated.

Did you quote it out or removed it? I need it to 'loop' so I can test after fixed (make sure it quit looping) - I don't want to post anything that's not tested.
What I'm doing is a slow process - already I thought i was testing for loops, so I guess I need to start over again.

[KingMort]

Hehe sorry if I caused a stir , perhaps someone could help me out.. Is our code out of date? Our good friend Ndnet is my prime coder atm so maybe you could help us fix this. Seems there are many zones where this is happening.. Players are getting frustrated.

[Angelox]

Originally Posted by KingMort

Hehe sorry if I caused a stir , perhaps someone could help me out.. Is our code out of date? Our good friend Ndnet is my prime coder atm so maybe you could help us fix this. Seems there are many zones where this is happening.. Players are getting frustrated.

What version EqEmu are you running?

[KLS]

Basically there's a block of code in zone.cpp that looks kinda like:

	if(closest_dist>(40000.0f) && closest_dist<max_distance2)
	{
		if(client)
			client->CheatDetected(MQZone); //[Paddy] Someone is trying to use /zone
		LogFile->write(EQEMuLog::Status, "WARNING: Closest zone point for zone id %d is %f, you might need to update your zone_points table if you dont arrive at the right spot.",to,closest_dist);
		LogFile->write(EQEMuLog::Status, "<Real Zone Points>.  %f x %f y %fz ",x,y,z);
	}

if you add the line:

closest_zp = NULL;

Right before the closing bracket it will attempt to cancel the zone request. I took it out so it just logs the invalid zone since if it cancels a zone at a zone point it will dump the player right back there and they'll attempt to zone again; thus an endless loop. Ideally it should probably send a cancel zone request and send you to the safe point in the zone like with other cancel zone requests, wouldn't fix a bad zone table but players wouldn't loop endlessly.