No, the bug where CoH puts you at the zone's safespot triggers neither the warp detector, nor the zone/gate detectors.

Dax

I just read the Gunthak thing that I think you were bringing back up, and I believe I misunderstood your question / statement before (or just explained it wrong due to exhaustion or stupidity).

I think that all of the detections are getting blurred here:
There are 2 distinct types: Zoning and Warping. Look for the broadcast message when you trigger it and make sure that you're talking about the right one (as their detection methods are completely separate).

Warping detects based on the client's movement over time, so if you travel across the zone faster than should be possible - it will hit you.

Zoning detects based on the `zone_points` table for (major key word coming up) "UNSOLICITED" zone requests. If you gate, the server zones you as part of the spell effect. If you are inter-zone #summoned by a GM, then the server zones you as part of that command. These things do not set off the /MQZone detection.

What DOES get checked are requests that originate from the client. These requests happen naturally too, so that's why we have to see if the client zone request is valid. The best way to do that is to see if there's a zonepoint near the client when it's sending that zone request. We check that with the x, y, and z columns on the`zone_points` table in the database.

Example:

Legitimate Zone Request:

• Fault is running through the tunnel in East Commonlands to meet up with his guild, he hits the North Ro zone point line.
• Fault's client sends a zone request to the server.
• The server checks Fault's last player position update location (his x, y, and z in East Commonlands) for the closest zone point in the table for East Commonlands.
• The server sees that based on Fault's location of
  Code:

  ---

  (y, x, z = -2444, -62.5, 3.8)

  ---

  in the East Commons, the closest zone point is:
  
  Code:

  ---

  (id, zone, number, y, x, z, heading, target_y, target_x, target_z, target_heading, zoneinst, target_zone_id)
575, 'ecommons', 1, -2462, -105, 3.13, 0, 2604, 2903, 3.13, 999, 0, 34

  ---

• The server checks the distance between Fault and the zonepoint (sqrt(-2444 - -2462)^2 + (-62.5 - -105)^2). This answer is 2130.25.
• Since the distance between fault and the zoneline is less than 4000, the server determines that the zone request is valid, and processes it.

Illegitimate Zone Request:

• Fault is running through the tunnel in East Commonlands to meet up with his guild, is running late, so decides to use Macroquest /zone from the other side of the zone, near Nektulos forest.
• Fault's client sends a zone request to the server.
• The server checks Fault's last player position update location (his x, y, and z in East Commonlands) for the closest zone point in the table for East Commonlands.
• The server sees that based on Fault's location of
  Code:

  ---

  (y, x, z = -726, 736, 51)

  ---

  in the East Commons, the closest zone point is:
  
  Code:

  ---

  (id, zone, number, y, x, z, heading, target_y, target_x, target_z, target_heading, zoneinst, target_zone_id)
575, 'ecommons', 1, -2462, -105, 3.13, 0, 2604, 2903, 3.13, 999, 0, 34

  ---

• The server checks the distance between Fault and the zonepoint ( (-726 - -2462)^2 + (736 - -105)^2 ). This answer is 3720977
• Since the distance between fault and the zoneline is more than 4000, the server determines that the zone request is invalid, cancels the zone request, and responds to the player in the method that the ServerOp has specified in his rules (any combination of logging or stunning, reduced mana and hps, debuffing, or just a simple Worldwide emote).

So when you're saying does this code handle this, or that, it's helpful if you can specify which feature you've had issues with in the past.

Now, with that said, I feel like I've been a pretty good sport with humoring you. If you genuinely care about these things, and actually want the answers, then by all means, I'll continue fielding your questions, but if you're just a sore-assed player that's pissed off, because you're afraid of losing your ability to /zone or /warp (as you're coming across in your posts), then save us both the time, and pretend that the code doesn't exist. I'm not telling anyone that the have to put this on their servers. I'm simply trying to assist ServerOps by helping them to become empowered when dealing with these script kiddies (let's not over glorify these people by calling them hackers). If you're opposed to ServerOps having the option to prevent the use of Macroquest on their servers, then clearly you're at the wrong show.

Basically: If you're interested in helping debug the code, the I welcome it, but if you're just posting shit like this in an attempt to derail the code, save us both the time.

Thanks,
Dax

My edit timer ran out - in the first example:
should be:
There is no sqrt in that formula.

Dax

Remember, I LIKE you and anyone else working to better this project - You are helping this project greatly and I don't need you getting upset and quiting over someone giving you the run-around.
So if someone pisses you off, they will go before you do. We are not going to let these forums get out of control anymore, as its alienates us from the project when it does.

what he said!

This is a great thing, people hacking on a free server that someone took the time to build is pure crap. This is one of the greatest submissions to EQEmu I have seen, and most people feel that way.

Just remember the more script kiddies that complain the better it is!

:) I'm neither pissed off. upset, nor anywhere near quitting. I'm just trying to figure out if this Fault guy is actually asking questions because he's interested or trying to discredit the submission. If he's trying genuinely interested, then I want to help him, but if he's trying to be a dick, then I can save myself a lot of time and effort from trying to explain the code and just ignore him.

That's all I was trying to say. ;) If my post came across pissy, burnt out, jaded, or whiny, then I apologize, as that wasn't the intent. My sleep deprivation has a tendency to firewall my etiquette.

<3,
Dax

Actually I am getting irritated as it appears you are not correctly reading any of the posts. I clearly stated it is a good idea but have reservations on some issues, which I pointed out. You have repeatidly dismissed the Call of the hero Bug which is what I am trying to get you to realize will and does trigger the anti-cheat code.


the Spell ITSSELF does not trigger, the zoning AFTER the spell being cast on you does, the fact that you are dissmissing it has me concerned greatly, as this Is a critical bug in the code which it appears noone has been able to fix yet. I really Hate to see users falsly accused and banned from servers because they were cohed, then zoned then triggered the anti-cheat because the center of a zone is not defined anywhere.


Bug of COH was posted here: http://www.projecteq.net/phpBB2/viewtopic.php?t=4535


I keep saying great code, but get it somewhat stable/bug free before committing it, in my opinion if it detects the coh bug as a MQ2 hack then it isnt stable/bugfree and will cause more grief then good.


If you feel that you are being attacked or disrepected then like I said I am sorry ,this isnt about disrespect or being rude. It is an attempt to make sure and get a exception for a known bug untill such time the known bug is fixed core side.


AGAIn this isnt any type of *your code sucks dont use it post* this is a *Code is good however this bug will and does trigger the anti-cheat and shoul dbe looked at post*

After your post this morning about the CoH bug, I found it on the PEQ forums and tested it before I posted. From my tests, yes the CoH bug moves you to the safe spot after zoning, as described in the bug, but it does not trigger any of the hack detectors, as I said before.

Dax

sweetdeal. Now I support it fully. keep up the good work

http://ferncanyonpress.com/tombston/images/val1.jpg

There. Now we can be friends again.

<3,
Dax

Heh. Such a great movie.

Hahaha, well played.

any idea if this is going to official code or not ? =)

The key to something like this is not necessarily to autopunish for it, but simply to LOG it... so that the serverops can use it to decide whether they were cheating or not.

The fact is, no code like this will be perfect. Someone will figure out how to work around it--especially since it's open source. Then where would we be, artificially trusting code that is no longer doing what is intended?

I think, again, logging things that appear strange is the answer. Then ops can look for patterns and decide what, if any, actions to take that way.

That's essentially the aim on the latest submission build. By default it's disabled via the rules system, then if a ServerOp chooses to enable it, the ServerOp can choose to enable any parts of it that he wants.

Here are the new rules with it (the last 3 rules address your concerns):

I have a new problem, not sure where it's coming from; when i zone from Tox to Kerraridge, i get caught in a zoneing loop, where it repeats zoning tell I kill the client (never gets to Kerra) - Kerra to Tox works fine.
Last thing I did was add this code so I'm wondering if it might be related (all worked ok before code).
Also another question (probably a dumbass one); NPC zoners do not get affected by this code (Translocators)?

It's because the coords in zone_points for that zone line are 0. About 750 zone points are like this in PEQ... The problem is this issue occurs even if the system is disabled :( TheLieka goes into more detail of this in another post.

As for your other question, I have not been able to get quest teleportation to trigger this at all, so it appears to work correctly.

If you source in the zone_points that I included with the code submission (on the first page), it will fix the problem for old world zones - beyond that, we don't have a list of them yet.

Dax

Thanks for the help, i should have read that already.

Actually , it was originally Cavedudes EQ - then PEQ leached off EQ, I Leached off PEQ, and finally you leached from mine.
EQ, PEQ, AX_PEQ are all public property though.
Actually I leached off both PEQ and EQ because at the time, PEQ had cut out a lot of the higher zone/expansions, when they started the PEQ DB.

MQWarp/MQZone/MQGate Detector Discussion
 

Not sure if I understood this correctly or not, but when his distance is less than 4000 does the code check to make sure he's actually zoning into nro (zone_id 34) or could he stand near the nro zone and type /zone to get to nexus?

Well, if you want to get into the nuts and bolts of it, there are two types of unsolicited (client originating) zone requests: With or Without providing a destination zone to the server.

If the client specifies the target zone, then the zone server will check to make sure that a zone point exists for the requested zone, within the current zone, within a reasonable distance of the player's location. If it does, then the player's zone request will be processed. If there is no zone point for the requested zone within the specified zone, or the zone point is not within a reasonable distance, then the request will be cancelled, and the player will trigger the /MQZone detector.

If the client does not specify the target zone (this is the case with zone points built into many of the zone files), then it will basically just tell the server "Hey, I need to zone". The server will look for the closest zone point to the player's location, if it's within an acceptable distance, then the player's request will be processed for the zone that comes up. If not, then the request will be cancelled, and the player will trigger the /MQZone detector.

That's why it's so important to get x, y, z populated for your zone_points table. ;)

So, to answer your question, if you're standing in east commons beside the nektulos forest zone line, and send through a /zone nexus, then you will trigger the detector.

Dax

Funny story, now that most the other small nagging things are taken care of I can start looking at getting this and related things into source.

I <3 you =D Seriously thought this is great work so far Dax.

Take your time KLS. :) I think most of the people that were dying to get their hands on it are already running it. I am a little curious at the lack of feedback though. I assume that means that: it's flawless, it was so bad that they didn't even bother to post any bugs, or no one has done any testing with it. I'm curious to hear some solid feedback on it.

Dax

CD has told me after all the revisions it works quite well just that it uncovered some somewhat serious problems with the zone points table.

Well, I am waiting for this to go into the release since I seem to have trouble compiling sometimes. I know of at least a couple other popular servers that are waiting to use this as well.

I will definitely give you feedback once I get it running. I can't wait to try it out. Looks like you have made some amazing changes since the initial submission.

Preventing players from using /zone is actually pretty easy - what you do is code an internal server function that flips on when the player is "allowed" to zone (allowed_zone = true or whatever). Then you set this to true in all legitimate functions like server-called MovePC. When the player is zoning via a zoneline, check that he's feasibly close to it (like KLS is doing), and if he is, set to true.

If the player zones without having this permission flag enabled, you disconnect him or otherwise prevent him from zoning and log the incident. This way, instead of trying to figure out how to detect every time a player isn't allowed to zone, you just define the times he is allowed to zone (there isn't that many) and get him via method of exclusion.

We've caught a lot of MQ users on SoD with this.

That's what the code does. ;)

Dax

Ah, very nice. Good luck, always enjoy catching cheaters.

Well, I went through and finally added this code into my source manually. Took me a while to get all of that stuff in lol. Though, once I did, it seemed to compile perfectly as far as I can tell.

I disabled most rules accept for the warping and ghosting checks. Unfortunately, it still seems to be doing the /zone checks. I have gotten a ton of players reporting that they are getting stuck in infinite zone loops. I went ahead and added the PEQ Char Mover PHP script (thanks PEQ!) to allow players to unstuck themselves while I try to get this issue worked out. I am guessing that the rules to disable the zone checks aren't working or something else is causing the weird loops. Unless it is the warp detector that is causing it because I don't have my zone_points table updated. But, I am not getting any broadcasts of cheaters, so I don't think that is it. I do have the broadcast enabled, but penalties is disabled.

Other than that, I have had 0 reports of warping since I added it in. If I can get this zone loop issue worked out, it seems great! I haven't really noticed any other issues with it so far, but it has only been in for a few days now. I will update with any other issues I see. Thanks again for the code, Dax and the others that helped from TZ/VZ!

The zone looping is the zone_points problem ;)

Ya, I figured that, but should that matter if I have the zone detector disabled? Or am I just not understanding the problem? I am not getting any broadcasts of cheaters so far at all.

I am not 100% sure that this is related to the MQ code that I added in, but every since I added it I have been getting random crashes and my terminal window reports something like this:

*** glibc detected *** double free or corruption (!prev):

This causes all of my players to be disconnected and I think it crashes the world. It may be coincidence that this started after I added in the MQ code though. I have had a couple issues with my ISP connection and one of these glibc errors kicked out yesterday about the same time my internet went out. I have also had a bard problem where the bard crashes any zone it logs into and it just so happened that I was trying to log the bard in at the exact same time my internet and this error kicked out lol. So, it could be any of those 3 issues. But, I have had this a few times over the past few days that I have had the MQ code in and I don't think the others were during any ISP issues or issues with this bard.

After doing a bit of googling, I think this is a memory error and I believe it can be disabled by turning off that memory allocation check. Here is the command I issued to disable it:

export MALLOC_CHECK_=0

I am sorry if this is completely unrelated to the MQ code. I considered posting this in the Linux Support section, but it started almost right after I loaded the MQ source in and I never had it 1 time before that. Either way, I think this fix should resolve the problem for anyone who has it. I will post back here if the problem starts up again. Also, I don't know if I need to do that export each time I restart the server PC or if that changes the setting permanently.

Nevermind the post about the glibc issue. That was unrelated to this. Turns out that was the bard that was causing it. I am assuming it is some issue with AAs. Finally had to change their class to warrior and log them in and clear their AAs then back to bard. The "fix" I posted doesn't seem to work either lol. I will make a new thread on this issue if I have anymore problems with it.

The MQ warp detection doesn't seem to be working properly for me yet. I still haven't seen any broadcasts of cheaters or any entries in my hackers table, but I know for a fact people have been warping on my server... Maybe I missed something in the source before I compiled. Any chance someone has the 1108 source with the MQ stuff coded in them that they could host somewhere? I only need the files that were changed by the MQ code, but I would take the whole package if it is available.

Thanks.

The mark of a true software engineer. =)

Great work on this, man. I too look forward to getting my hands on it. My <locked> server is just sitting there, if anyone wants a clean, private server to run unbiased testing on.

While I support the OP in his endeavor, and having used MQ/2 myself on live for many years, and contributing largely to the MQ/2 community, I have to say that some people don't quite grasp MQ/2.

MacroQuest, developed over the course of many years, is nothing more than a character automation/assist tool which is almost infinitely customizable. Fair enough. You write scripts, it preforms them. For example, you want to see a mob's health? use /say ${Target.PctHPs} and it displays their health to everyone around. Similarly, it can do timed commands, such as /timed 600 /camp desktop, which would wait 600 MQticks and then camp out gracefully. Quite useful, actually (if you have to run but want full mana/hp when you return to the computer)

With certain (read: frowned upon by the MQ2 community) plugins you CAN warp and chainzone. These were developed by a group of griefers who have no connection to MQ2, with the exception that they know how to programming in the language and compile plugins, but thought it would be fun to mess around. On live, not surprisingly, these people were instantly banned due to the sheer audacity of warping/chainzoning- which was easily detected.

However, these plugins are primarily found on bittorrent searches for MQ2 or PRECOMPILED MQ2 which means that these 'hackers' are too lazy/stupid to compile MQ2 themselves, with the correct dates

However, I have never seen a MQ2 user able to summon items from thin air (with the exception of mages, and even then, only certain items) - that is preposterous. ( from another thread, but useful in my point)

Do I use MQ2?
On certain servers, i do - and find it useful.
Let me explain -
on krushers server and nonlegit #level 70 #si anything #kill enabled servers i have a nice little set of scripts called nonlegit_${Class.ShortName}.mac that i use to equip myself for whatever class i want to play, max level 70, max AA's, without having to spent 45 minutes searching for items i want, putting in and clicking hundreds of times to max my aa's,i have it layed out in a nice database and that is that.

I will like to emphasize that you cannot summon items on legit servers UNLESS YOU ALREADY HAVE GM PRIVVIES - but for things like krushers, it's perfect. I can have any character level 70/75 with the best gear i can find from lucy or the 13th floor, with max aa's in a little under 3 minutes.

Back to the point on hand,
/zone and /warp are seriously stupid things to do on a legit emu. It DOES ruin the game for people who enjoy the legitmacy (see: wizards and druids, pre PoK)

What do I think about the warp code?
Stellar, go for it! Just default it to a maximum value and allow other users to set it lower, if they want it in on their server.

As a rule, you should try to assume people DON'T cheat, and then be surprised and punish accordingly, instead of assuming everyone cheats and cracking down so hard the servers become no fun for anyone and the population drops even lower than it is.

my two cents.

You mention that MQ2 was meant as a means to help assist players. Yes, that is true, and some of the features like the /stick autofollow feature is nice. But, when it gets to the point where players are starting to use scripts for the command /tell options where they tell one of their characters something and it does whatever they tell them (heal, buff, etc), that alone is giving them a large advantage over players without MQ. Not to mention that if a server wanted to allow people to play their characters that way, they might as well enable the offline bots so all players can have a similar experience.

Then, you get into more advanced scripts where entire groups could be killing in an area for days to XP or farm cash or whatever, and that is just wrong and completely abusing the system. Combining these macros with warping ability makes MQ a huge threat to any legit server. Both of them give huge advantages over players who play legit and have caused endless drama between players. Not only that, but all server admins work hard to develop content and create balanced zones for character progression. By warping, players are negating all of that hard work and skipping straight to the reward. IMO, if a player wants to cheat, they should go to a non-legit server so there is no need to use MQ to do it.

I allow the use of MQ on my server for maps only. This is mainly because there is no way to ever detect it and it only gives a slight advantage over players that don't have it. Also, there is not much of a chance that seeing which spawns are up will cause any dispute between players like we get from players that warp or macro.

As for server admins with harsh punishment for being caught by MQ detection tools, there isn't really many other options. In the past, I used to give players every last chance to stop cheating and time and time again they just lied to me and continued cheating. I spent countless hours watching them to catch them with my own eyes when possible. I have MUCH better things to do with my time, so now I just rely on my detection tools and make a judgement call as to when to ban. If you see many character in the same guild all tripping MQ detection, then there is a good chance that they all have MQ and are abusing it. There are other ways to check into this as well. But, there is no reason why any server admin should have to spend so many hours just to keep their server free of cheaters. It is a slap in the face to any admin every time someone cheats. We make these servers for players to enjoy, so all of the hard work we put into them gets the middle finger when players can't follow the extremely simple rules and policies of the server.