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

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Development::Server Code Submissions (https://www.eqemulator.org/forums/forumdisplay.php?f=669)

- - MQWarp/MQZone/MQGate Detector (Code Name: The VZTZ Hammer!) (https://www.eqemulator.org/forums/showthread.php?t=24761)

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

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

Dax

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.

Quote:

Originally Posted by cavedude (Post 152501)

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.

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.

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.

Quote:

Originally Posted by KLS (Post 152509)

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.

Quote:

Originally Posted by KingMort (Post 152510)

What version EqEmu are you running?

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.

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.

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.

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.

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.

I see that this is no longer stickied, but is work continuing on this? The detection is in, but there doesn't appear to be any form of punishment implemented that I can tell as of 1119.

Just checking in. The detection performs beautifully, thanks to everyone who has put work into this. It is sorely needed.

Thread necroing, sorry -- Wondering if there was a way to implement punishment via perl script, or debuff ?