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

[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

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

[TheLieka]

Originally Posted by 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.

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]

Originally Posted by 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.

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 different threads 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 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]

Originally Posted by So_1337

Actually, he did seem to have at least some legitimate sour grapes. There are two different threads 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 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