MQWarp/MQZone/MQGate Detector Discussion

[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

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

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.

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