MQWarp/MQZone/MQGate Detector Discussion

[otheli89104]

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

[Angelox]

Originally Posted by otheli89104

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]

Originally Posted by fault

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]

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

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]

Originally Posted by fault

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

[cavedude]

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

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.

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