MQWarp/MQZone/MQGate Detector Discussion

[Angelox]

To me ( and a few others) These fixes to curb cheating are very important - they will start a new era of game play, and bring some very needed stability to EqEmu. I hope we can follow through with this and iron out any bugs it may have -
I Imagine player populations might drop some, since one player can't run numerous accounts, but it will improve game quality, and eventually attract legit players. Personally, I don't care to play on any server other than my own - because I always have the misfortune of someone approaching me, dragging 3-4 more characters and offering me anything I want, when i do play.

[Aramid]

Even though I only run a Server to amuse myself, I agree with you Angelox. What I really appreciate is that they were made into RULES so the ServerOp can make their own decision to use them or not.

Once again, THANKS to EVERYONE who has contributed to this Project!

[TheLieka]

Thanks for the catch Aramid, and yes, you're right, the second one was supposed to be MQGhost rather than MQGate.

Angelox:

I agree completely with your post, and I actually saw it first-hand from our server. When we first put in the limit on concurrent connections per IP address (we limit everyone to 2 sessions), our server population cut in half (from about 60 to 30), but within two months from that, we were up to 90 players. I honestly think this rule is a relief to the players. I don't think anyone enjoys playing 6 characters, but they feel like they must in order to compete. When you can put a ceiling on it (at 2 - 3 characters), then you relax the environment, FORCE people to be social (omg, imagine that) and build a community. It worked out very well for our server, and I wouldn't revert back for anything.

As far as the MQ code, we used to have issues with the MQWarp code generating false positives quite frequently, until (my own personal Jesus) Null came on-board. One of the major improvements that he added to the code was the warp_threshold and warp_threshold_timer. In essence, it allow a player to perform several small warps within a certain period of time without tripping the warp detector (the idea here is to account for reasonable amounts of lag); however, any large warps will automatically set off the detector.

I really hope that these last few submissions help to stimulate the development community. I know that I'm fired up about this project, and I'd love to see a new fire lit under some asses. ;)

Dax

[Secrets]

Stupid question, but...

I assume this won't work with perl inter-zone requests?
Such as movepc, movegrp, etc.

But hey, i'm not complaining, this is a huge leap for EQEmu.

[cavedude]

It may actually, and if it doesn't it shouldn't be hard to update. You'd just reset the timer when the function moves the player, correct TheLieka?

[KingMort]

Thank god !!!

Very excited about this , I have been plagued by Cheaters for the 7+ years that I have run my server.. It will be very nice to finally crack down on it.


Excellent work !

King Mortenson
www.raidaddicts.org

[TheLieka]

Stupid question, but...

I assume this won't work with perl inter-zone requests?
Such as movepc, movegrp, etc.

But hey, i'm not complaining, this is a huge leap for EQEmu.

These should work because the zone request is generated at the server rather than the client. The main thing that we're looking for (the thing that macroquest does) is unsolicited (client based) zone requests when the client shouldn't be requesting a zone change. So if the zone request takes place as a result of a server action, it should be exempt from the MQZone Detector.

Dax

[fault]

I would hope this is NOT going into EQEMU.


very unstable code, stops most dynamic zones from loading. Experienced it first on a server I roll on, then Compiled it myself and experienced the same issues. Also imo limiting connections On a private server is stupid, where you have very little users. and boxing doesn;t hurt anything.

[Angelox]

I would hope this is NOT going into EQEMU.
very unstable code, stops most dynamic zones from loading. Experienced it first on a server I roll on, then Compiled it myself and experienced the same issues. Also imo limiting connections On a private server is stupid, where you have very little users. and boxing doesn;t hurt anything.

I'm happy to hear negative input on this - this only tells me it really works and you (the player) can't do what you used to do.
As for the rest, we can let PEQ operators be the judge of that, as they already have it running on their server (haven't heard any complaints from them yet).
Also, these will be options you can choose from, when they do go to the source.

[So_1337]

Actually, he did seem to have at least some legitimate sour grapes. There are two (http://www.projecteq.net/phpBB2/viewtopic.php?t=4464) different threads (http://www.projecteq.net/phpBB2/viewtopic.php?t=4463) on the PEQ forums discussing the issues with the implementation of this code.

Where I disagree with Fault, however, is in saying that it should not be committed into the code. It absolutely should; all it needs is a little tweaking and debugging like most code submissions. They're submitted here so many different pairs of eyes can look things over and try them out, reporting back what needs fixed.

Oh, and limiting connections isn't part of this code, and should be taken to that thread (http://www.eqemulator.net/forums/showthread.php?t=24730) if you want to complain about it. However, complain about the code if it's broken. If you don't like what it does, then just turn the rule off. The server operators get their choice in the matter.

[cavedude]

The zoning difficulty I am pretty certain is related to the zone_points table, so that's a db issue and not one with the detection system.

However, PEQ did see several false positives of the warp system in times with no lag and low server load. It did get so bad, we had to remove the system. Players on PEQ are able to break anything ;) On the plus side, it DID catch several legitimate cheaters so that part certainly is working.

KLS and I both agreed that while the punishment system is fine and well, and can easily be changed if need be, it was missing one key, and to us logical feature. Simply, to put the player back at their previous pre-warp/zone spot. The hp/mana removal and rez effects may deter some players from using warp to travel, but it certainly won't prevent them from accessing areas of a zone they shouldn't be (like event areas in PoP zones)

[fault]

Actually, he did seem to have at least some legitimate sour grapes. There are two (http://www.projecteq.net/phpBB2/viewtopic.php?t=4464) different threads (http://www.projecteq.net/phpBB2/viewtopic.php?t=4463) on the PEQ forums discussing the issues with the implementation of this code.

Where I disagree with Fault, however, is in saying that it should not be committed into the code. It absolutely should; all it needs is a little tweaking and debugging like most code submissions. They're submitted here so many different pairs of eyes can look things over and try them out, reporting back what needs fixed.

Oh, and limiting connections isn't part of this code, and should be taken to that thread (http://www.eqemulator.net/forums/showthread.php?t=24730) if you want to complain about it. However, complain about the code if it's broken. If you don't like what it does, then just turn the rule off. The server operators get their choice in the matter.

I don't like it because it is to buggy at the moment(anti-hack). For those of us who don't cheat it made it really hard to play on PEQ. It seemed to detect NPC warping as cheat warping and punished everyone accordingly, making it hard to do stuff like hedge. And there was an issue with dynamic zones loading after it was implemented, which was fixed after they removed the code

thus Why I would suggest No commit to eqemu for a while atleast.


and yea cave the anticheat caught my guild leader and his 6 boxes, wierd I never knew he warped O_O I guess you just really don;t know who is using mq2 legitly and who isn't huh? Thus why I use wineq2 for boxingsimple effective and no possible way to cheat with it or be called a cheater.

[TheLieka]

I can take a look and see if integrating it into the rules system caused some wackiness, but I can tell you that we rarely have issues with false positives from the warp code. If the rules system is working correctly (which I will certainly check into), then you should be able to increase the threshold and make it more lenient, if that's a problem with it.

To address Fault's combative posts, the code isn't written in a shitty way, in fact, it's very straight forward (as far as detection is concerned): it checks the updated position point that the player sends to the server against where the server says the player is, then it checks the rules to see if that's an acceptable amount of movement or not. It's up to the ServerOp to decide what's acceptable for their servers, but the default values are the settings that we currently use.

As far as the 6 boxing thing is concerned, we don't allow that on our server, so it's not a problem for us, but yeah client lag can cause the client to not update its position with the server just as well as server lag can, so I can see that being an issue. If a ServerOp chooses to allow players to 6 box, then that will need to be taken into consideration when choosing the warp threshold values.

Cavedude:
I agree with your statement about moving the players back to his or her originating point (pre warp), and we've talked about doing that in the past, but haven't coded that in yet. It shouldn't be too hard to implement, and now that this code has been submitted to the community, if anyone else wants to code that up before we get a chance to do it, please post your update to it.

:)

Thanks,
Dax

[Angelox]

I know what you all need to do, and that is start a test server and invite some honest players to try all this out - I bet a lot of complainers just plain-assed don't like this idea and therefore are already prejudiced to it. I'd be willing to help test if you do.

[KLS]

Some concerns I have:

Cavedude already mentioned this but the built in punishments, need to either go or be able to be toggled on/off. False positives unjustly punish legitimate players in such a circumstances, just warping someone back to where they were is a pretty easy punishment and it doesn't really insult the players playing legitimatly. If they're lagging and get warped back a few times a play session it's not as big a deal as having to regen hp and mana and deal with res effects. Sorta leads into my next concern...

The warp system isn't perfect, it doesn't account for lag well and I've gotten quite a few reports of false positives from people who have used it. It could be tightened up a bit, and could account for lag. For example instead of measuring a set distance since the last update measure a variable distance since the last update based on the time between this update and the last.

I think outputting suspicious behavior to a .log file would be better than mysql, just because it takes some stress off of the mysql server and it's a lot easier to view and sent do someone else.

But like I said the first time, great initiative, it's something that was certainly needed.

[trevius]

For porting NPCs, maybe the code could get sent the port to location information when players are moved so it knows they aren't warping. Also, Mage CoH could maybe do something similar somehow?

I am mainly concerned with players jumping from one side of the zone to the other end. I imagine I could have thresholds set pretty high for that to account for lag. I guess that would also have to take bard speed into account (and probably GM speed too). Having it send the player back to where they started is a great way to deal with this. But it should also write to a log file similar to quest::write.

[TheLieka]

To allow spell effects, you just have to identify the spell effect to exempt it from setting off the hack detector. I don't believe Call of Hero's summon effect is in, but spell effects like shadowstep, succor, gate (for when the bindpoint is in the same zone) have been accounted for. I'm not sure how much time I'll have this week, but when I have time, I'll try to look into these concerns.

Dax

[trevius]

CoH does work just fine. I think it was fixed a while back.

[TheLieka]

I mean that I am not sure if it will be exempted by the warp detector. I'll have to check that.

Dax

[thepoetwarrior]

Please, made this part of the next release (specifically for binaries). Need to get rid of MQ2 users.

[thepoetwarrior]

Would make an excellent addon to the binaries since it doesn't change the way the game is played from live version, and Im sure people can config in ruleset if they want to enable/disable logging of MQ2 users. Please add to the binaries!

[otheli89104]

Please, made this part of the next release (specifically for binaries). Need to get rid of MQ2 users.

It doesnt work i added it to my source and it doesnt keep out the ip address im not sure why so far it seems to be that the best solution is to flag the accounts as -1

[otheli89104]

small update i have tried this on three different versions of the emu thusfar no success opon testing though i did notice a few typos that still didnt work oppon fixing

[otheli89104]

a few throughts all references to banned_ips shold be lowercased not uppercased, not sure how well this is going to work yet but i am changing int32 to a string as ip adresses have more then numbers in them wil post back when i test this

[otheli89104]

<<Take the attitude to another emulator, we don't owe you shit. -- matt

[Angelox]

is there some particular reason that my posts were deleted??
what kind of open source community is this the code doesnt work i am trying to fix it to help the community and you delete my posts showing the bugs?
dax ASKED the code BE tested and that he be told how it worked it does not as of yet and you deleting my posts was both rude and detrimental to the community as i am TRYING to get it working properly and WAS going to post the updated source but now i question whether i wish to help a community that deletes posts in such a manner for no apparent reason

If you would READ first, you would see where the Devs want that forum for SUBMISSIONS ONLY, But you insist on not only posting there, but spamming the thread too. I moved them anyways (didn't delete).

[fault]

it isnt *boxing* that lags. The detection doesn;t take into account the emu lag. Unless you have a beast of a box with each dynamic zone loaded on a different box you will have lag. I doubt anyone running eqemu would be running it on a beast.

being a dev for an RO emu I can already tell you, any typ eof *cheat* protection will not work, and only lead to buggy code, point proven with this being tested on PEQ for one day, just about everything set off the detection for honest players, I bet you cheaters * those with brains* got away from it and were not caught.

and when I mean just about everything I mean.

kedge quest
Zoning into dynamic zones
COH
gating
ghosts

[cavedude]

being a dev for an RO emu I can already tell you, any typ eof *cheat* protection will not work, and only lead to buggy code, point proven with this being tested on PEQ for one day, just about everything set off the detection for honest players, I bet you cheaters * those with brains* got away from it and were not caught.


Don't bash this code, that simply is not true. In the one day and a half it was on PEQ, we only had 5 unique cases of false positives, compared to 7 groups caught cheating. People exaggerate a lot on PEQ when a change goes in they don't favor. The code is stable, and it does work for the most part. I'm sure smaller populated servers would have no issue with it at all, I just feel it needs to be polished some before going into the official code base.

[TheLieka]

it isnt *boxing* that lags. The detection doesn;t take into account the emu lag. Unless you have a beast of a box with each dynamic zone loaded on a different box you will have lag. I doubt anyone running eqemu would be running it on a beast.

being a dev for an RO emu I can already tell you, any typ eof *cheat* protection will not work, and only lead to buggy code, point proven with this being tested on PEQ for one day, just about everything set off the detection for honest players, I bet you cheaters * those with brains* got away from it and were not caught.

and when I mean just about everything I mean.

kedge quest
Zoning into dynamic zones
COH
gating
ghosts

it isnt *boxing* that lags.
Bullshit - this was tested extensively, multiboxing does cause your client to update with the server more slowly. I'll show you my statistics after you show me yours.

I really don't know what crawled up your ass, but I wish you'd crawl out of mine. You clearly don't know what you're talking about and haven't read through the source. I have been slammed at work since about the time I posted the code, so I haven't had time to go in and make the adjustments that KLS and Cavedude recommended. I've posted what we've been using for everyone to see, if you're such a hardass, pick up a compiler and make the adjustments - otherwise unsaddle my nuts and I'll make the fixes when I get some time.

The reason that people had problems with it on PEQ (and I stated that I expected that this would be an issue before I posted the code) is because we've only tested through the scenarios that our server runs. We are Classic EQ only - zoning into dynamic zones doesn't set it off - zoning into non-Classic zones sets it off (because there are no source zonepoints in the database). Call of Hero - I already posted that no, we don't have it on our server and it was forgotten. Gating - if you're serious right now, then I don't think you actually used the code; we covered gating and pretty much all other spell related effects that cause movement. As I said, we run this code on our server with no problems, and though our server hardware is pretty good - I don't think it plays into why there were false triggers on PEQ whatsoever.

As I said, I have every intention of updating the code, per KLS and Cavedude's recommendations, as soon as I get some time.

Dax

[fault]

CD there were more then 5 the hedge event triggered it on my entire party of 6 as well as other full parties as posted on PEQ.

gate DID trigger it, My cleric got hit with the punishments after he gated from one end of gunthak (fort) to the beach where I forgot I bound when doing the temp quest.

Your code has good intentions, but the points I am trying to make is, It won;t take coders long to find a way to fool it and get past it, there isn't any anti-cheat that is 100% effective and safe, remember the developers of trackmania said their use of starforce would 100% prevent any pirating/cracks of it, the same day it was released there were cracks for it. This is something you will have to always be on top of, constantly checking MQ2 source sites looking for modifications that get through the detection and modify it accordingly. I am personally against botting period, I think it takes away from the hardwork developers do, and would actually welcome something that auto rejected anyone using MQ2 immediately on connection.


I apologize if you feel I am bashing you.

[TheLieka]

gate DID trigger it, My cleric got hit with the punishments after he gated from one end of gunthak (fort) to the beach where I forgot I bound when doing the temp quest.

Gate did not trigger it. Zoning into Gunthak, a non-classic zone without source zonepoints in the database triggered it.

Dax

[Seksor]

I'm glad to see this initiative moving forward. I have a suspicion that there aren't many coders out there waiting to unleash new cheats for eqemu. Meaning, if the current cheats become obsolete, there won't, for time at least, be new cheats available. From what I understand the cheats that are available are old binaries that get passed around between users. For example, pre-built MQ2 installations that include warping and zoning functionalities. My next suspicion is that if these mq builds suddenly stopped working, most "polyboxers" would lack both the resolve to code workarounds and the money pay someone else to do it for them. When I played PEQ I felt like the majority of cheaters were using these hand-me-down binaries, and I'd love to see that age pass.

I don't play eq(emu) any more, but I still read up on the community. I love you guys. Seriously. Keep up the good work.

[Angelox]

I sort of knew it would come to this - I figure who ever multiboxes, also has multi forum accounts and friends that multi-box with multi forum accounts. So, you got 10 people whining over the same change, and it probably is the same guy!
You can pretty much control a game server like this too, and is why these fixes are urgent.
Something like this happened in the SOE EQ forums, where guilds would get together and bitch/bash everyone over anything they didn't like. It got so out of hand, one day I went to browse the forums, they were gone! hehe!
The forums came back, but when they did, the requirements changed, and all that crap was stopped.
It ain't gonna happen in these forums though :)

[cavedude]

CD there were more then 5 the hedge event triggered it on my entire party of 6 as well as other full parties as posted on PEQ.


I said 5 unique cases, not players. All together, about 40 players or so were effected. (including legitimate cheaters) A pair of players looked to be caught in a loop at one point, that's why I decided to pull the code. However, there was only one instance of the hedge event in the log table, and only 2 full groups were logged overall. If a third group claims they triggered the detector, they are lying. The logs don't lie.

We didn't get any log notifications for MQ2Gate, they were all MQ2Warp. But, could it be since he used Gate in his bind zone, that could have triggered the warp detector? I know Wild not too long ago changed how zoning works... does the detector take those alterations in account in this case? Perhaps it didn't realize he zoned, and so the gate registered as a false positive warp?

I do have a question, what is your code looking for exactly in zone_points? To use the example above, Gunthak does have 5 entries in zone_points, which represents the 5 zone-in points, pok, stonebrunt, dulak, and nadox x2. If you can offer suggestions, I'll have no problem updating PEQ's points to accommodate.

[Gonner]

I am all for this code being put in but I remember when it was on PEQ and it was horible. I play one toon, sometimes 2, and don't use MQ2 or WinEQ.

For the time it was implimented I was unable to really do anything. Now I am not saying it was just the code, could of been other factors but ever sense the code was placed in and even up to current PEQ has been unstable. Zone crashes, disconnects, random zone transport (like try zoning into FoB from Cabilis and ending up in Butcherblock), world server lost.

I am all for stopping warping, and other *cheats* but not at the cost of normal playablility.

[Angelox]

I am all for this code being put in but I remember when it was on PEQ and it was horible. I play one toon, sometimes 2, and don't use MQ2 or WinEQ.

For the time it was implimented I was unable to really do anything. Now I am not saying it was just the code, could of been other factors but ever sense the code was placed in and even up to current PEQ has been unstable. Zone crashes, disconnects, random zone transport (like try zoning into FoB from Cabilis and ending up in Butcherblock), world server lost.

I am all for stopping warping, and other *cheats* but not at the cost of normal playablility.

Primary goal of PEQ is to apply/test all reasonable code presented to them. You as a player are helping by posting bugs, or things you notice while playing, so they can get corrected. You will always be seeing problems, so long as they are always adding new code, but you also will see they get fixed.
There's no stopping or changing this policy, as someone has to test everything, and PEQ is that someone.

[fault]

are you taking into account selo/selo horse/run3 in that? as well as the COh bug? that will set off this quit a bit untill COH is fixed.


COH bug = if you COH someone and they don;t /camp before zoning, the next zone they do zones them into the center of the zone, since the person isnt zoning in on an actual zone point, poof it triggers this code.(this bug has been posted on the PEQ forums.

[Angelox]

I moved your updates and unlocked thread (incase you have more), Thanks again for your help!

[TheLieka]

Thanks Angelox. =)

are you taking into account selo/selo horse/run3 in that?

It's up to the ServerOp to decide what velocity they want to allow, as I just posted.


as well as the COh bug? that will set off this quit a bit untill COH is fixed.


COH bug = if you COH someone and they don;t /camp before zoning, the next zone they do zones them into the center of the zone, since the person isnt zoning in on an actual zone point, poof it triggers this code.(this bug has been posted on the PEQ forums.
There is no code that I can think of that should trigger this. Also, when I said that CoH wasn't covered before, I was mistaken. CoH does create an exemption on the server; not as a spell, but when it calls the MovePC (used by GMSummon, and others) function, it places the exempt on the player in the same way as a spell exemption.

Try out the code, if you actually experience issues, then feel free to post about them, and I'll see what I can do to help you with you issue.

Dax

[fault]

I am not talking about COH the spell.

you said in an earlier post, zones for which you have no zonepoint data on *like gunthak* would trigger the anti-cheat because it isnt taking it into accoutn and thinks the person is cheating.


So you have the bug where if you get cohed and dont /camp before you zone into a new zone, you zone into the zone dead center, where there is no zonepoint, therefore making the code believe you just used a cheat such as /warp or /zone in which case triggers the anti-cheat

See where Im getting at?

[TheLieka]

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

Dax

[TheLieka]

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 (y, x, z = -2444, -62.5, 3.8) in the East Commons, the closest zone point is:
(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 (y, x, z = -726, 736, 51) in the East Commons, the closest zone point is:
(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

[TheLieka]

My edit timer ran out - in the first example:
The server checks the distance between Fault and the zonepoint (sqrt(-2444 - -2462)^2 + (-62.5 - -105)^2). This answer is 2130.25.

should be:
The server checks the distance between Fault and the zonepoint ((-2444 - -2462)^2 + (-62.5 - -105)^2). This answer is 2130.25.

There is no sqrt in that formula.

Dax

[Angelox]

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


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

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.

[mattmeck]

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!

[TheLieka]

:) 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

[fault]

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*

[TheLieka]

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

[fault]

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

[TheLieka]

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

There. Now we can be friends again.

<3,
Dax

[So_1337]

fault: What makes a man like Dax, Angelox? What makes him do the things he does?
Angelox: A man like Dax has got a great big hole, right in the middle of him. He can never code enough, or debug enough, or compile enough to ever fill it.
fault: What does he need?
Angelox: Revenge.
fault: For what?
Angelox: Bein' born.
Heh. Such a great movie.

[TheLieka]

Hahaha, well played.

[jenco420]

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

[gernblan]

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.

[TheLieka]

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):

insert into rule_values values (0, 'Zone:MQWarpExemptStatus', 50);
insert into rule_values values (0, 'Zone:MQZoneExemptStatus', 50);
insert into rule_values values (0, 'Zone:MQGateExemptStatus', 50);
insert into rule_values values (0, 'Zone:MQGhostExemptStatus', 50);
insert into rule_values values (0, 'Zone:EnableMQWarpDetector', 'false');
insert into rule_values values (0, 'Zone:EnableMQZoneDetector', 'false');
insert into rule_values values (0, 'Zone:EnableMQGateDetector', 'false');
insert into rule_values values (0, 'Zone:EnableMQGhostDetector', 'false');
insert into rule_values values (0, 'Zone:MQWarpSpeedLimit', 30);
insert into rule_values values (0, 'Zone:MQWarpDetectionSpellID', 757);
insert into rule_values values (0, 'Zone:MQGateDetectionSpellID', 757);
insert into rule_values values (0, 'Zone:MQZoneDetectionSpellID', 757);
insert into rule_values values (0, 'Zone:MQGhostDetectionSpellID', 757);
insert into rule_values values (0, 'Zone:MQDetectorDisablePenalties', 'false');
insert into rule_values values (0, 'Zone:MQDetectorDisableBroadcast', 'false');
insert into rule_values values (0, 'Zone:MQDetectorDisableSQLLogging', 'false');

[Angelox]

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)?

[cavedude]

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.

[TheLieka]

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

[Angelox]

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

[Angelox]

SQL Step 1: Wipe your old world zone lines (I'm assuming that we're all based off of PEQ originally (mine is based from Angelox, but originally still it was PEQ)).


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.

[zydria]

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 (y, x, z = -2444, -62.5, 3.8) in the East Commons, the closest zone point is:
(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.



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?

[TheLieka]

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

[KLS]

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.

[jenco420]

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.

[TheLieka]

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

[KLS]

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.

[trevius]

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.

[Wiz]

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.

[TheLieka]

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

[Wiz]

That's what the code does. ;)

Dax

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

[trevius]

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!

[cavedude]

The zone looping is the zone_points problem ;)

[trevius]

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.

[trevius]

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.

[trevius]

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.

[John Adams]

I assume that means that: it's flawless
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.

[LordAdakos]

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.

[trevius]

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.