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.

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!

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

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.

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?

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

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

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.

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.

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)

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.

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

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.

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.

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.

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

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

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

Dax

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

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!

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

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

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

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

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

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

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.

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

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.

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

Dax

Yayyy
 

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.

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

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.

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.

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.

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

Thanks Angelox. =)

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


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

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?