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

KingMort · #1 07-12-2008, 10:12 PM

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 · #2 07-13-2008, 08:37 AM

Quote:

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** · #3 07-13-2008, 08:52 AM

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

Code:

	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:

Code:

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.

Angelox · #4 07-13-2008, 10:41 AM

Thanks - Hopefully, when this is all done, The only players getting looped will be the cheaters.
I'm also making sure the player lands in a proper position after zone (for example, not facing the zone he just came from).

For anyone who has time to help;
If any one is doing this or wants to help, please post here. I started with Kunark (maybe you can work another expansion).
It's a simple process , once you understand what you are doing (I hope I understood!).

I use 'MySql Query Browser'
Here's an example;
The line

Code:

 SELECT zone,y,x,z,heading,target_y,target_x,target_z,target_heading,target_zone_id FROM zone_points where zone ='firiona' and target_zone_id ='85'or zone= 'lakeofillomen'and target_zone_id ='84';

will produce this (open in a new window , I can't post HTML here I guess);
http://www.nahunta.org/~angelox/zonetest.html
what you see is the 'fixed' version of zone_points between FV and IllOmen. before fix, both sets of x, y, z were set to '0'.
Since I isolated the two occasions of zoning between mentioned zones , it's now much easier to change the right coords, and you can see which settings you need, for example;
x,y,z is where you should be in firiona and is the same as target_x, target_y, target_z in lakeofillomen, because that's where you were sent from. Same deal for lakeofillomens zone_points.
After the first query, you can re use the same one, just change 'zone' and 'target_zone_id' for the new query (Keep everything windowed, so you can switch from client to MySql Browser).

Since Kunark has so many zones, I went to EqAtlas, and printed the Zone Connection Map for Kunark, I then wrote in the zone number by each zone name there for reference. Now that I have a chart of all the zones with the connecting zonelines, I can find what I need for the query. Once that zone line is done, I go over the line with a red pen ( so I know it's done).
MySql Query Browser has 'on the fly' edit feature, so you can change the coords you are looking at.
#reloadzps doesn't always work right - so, if you think you got it right, and it still doesn't work, then you need to log out and restart the server.

I just thought I'd post in case anyone wants to help, we can get it done faster, if not I'll get it done, just will take a while.

**trevius** · #5 07-13-2008, 05:59 PM

Is there any way to add an IP Address column to the Hackers Table and have it log the IP that is being used to cheat from? This would be useful for the players who try to lie their way out of it. I am all about giving a second chance if I think one is warranted, but I hate being lied to.

As long as someone confesses and promises not to do it again, I am ok with that. But, if they lie about it and make up a story about someone else doing it on their account, I would prefer to just ban them outright if I can prove that they are lying.

Angelox · #6 07-13-2008, 06:41 PM

This should exempt any zones that are not ready;

Code:

UPDATE zone_points set x='999999',y='999999', z='999999' where x='0' and y='0' and z='0';

Since the query looks for only the ones that have x,y, and z with 0's, it will only fill in the ones that are not fixed. So far, it looks to be working.
For anyone just tuning in to this thread , Leika has already posted pre-Kunark fixes in the first part of this thread.

Angelox · #7 07-13-2008, 06:52 PM

Also (my edit time ran out);
I did notice some zones still will act funny, "closest_zp = NULL;" or not, until I did the 999999 fill with the query.
Here's more that I noticed; if you do a #goto in GM mode, when you zone, that's where you will land when you get to the other zone (same coords you #goto'd before) - I just spent hours in Howling Stones figuring this out. HS has one entry point, two exits, and both exits far away from zin and each other. So, although you may think you are exempt from the restriction in GM mode, don't believe it: Some things will not work right unless you play/test under normal conditions.