Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Development

Development::Development Forum for development topics and for those interested in EQEMu development. (Not a support forum)

Reply
 
Thread Tools Display Modes
  #1  
Old 04-02-2008, 03:18 AM
fault
Hill Giant
 
Join Date: Sep 2005
Posts: 114
Default

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.
Reply With Quote
  #2  
Old 04-02-2008, 06:38 AM
Angelox
AX Classic Developer
 
Join Date: May 2006
Location: filler
Posts: 2,049
Default

Quote:
Originally Posted by fault View Post
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.
Reply With Quote
  #3  
Old 04-02-2008, 09:04 AM
So_1337
Dragon
 
Join Date: May 2006
Location: Cincinnati, OH
Posts: 689
Default

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.
Reply With Quote
  #4  
Old 04-02-2008, 09:34 AM
cavedude's Avatar
cavedude
The PEQ Dude
 
Join Date: Apr 2003
Location: -
Posts: 1,988
Default

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)
Reply With Quote
  #5  
Old 04-02-2008, 01:06 PM
fault
Hill Giant
 
Join Date: Sep 2005
Posts: 114
Default

Quote:
Originally Posted by So_1337 View Post
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.
Reply With Quote
  #6  
Old 04-02-2008, 04:48 PM
TheLieka
Developer
 
Join Date: Oct 2004
Location: THE ATL (wut wut)
Posts: 325
Default

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
__________________
Daxum



Former ServerOp - Vallon Zek / Tallon Zek Emu Server - Legit / Guild PvP - (2007 - 2011 RIP)
Reply With Quote
  #7  
Old 04-02-2008, 05:50 PM
Angelox
AX Classic Developer
 
Join Date: May 2006
Location: filler
Posts: 2,049
Default

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.
Reply With Quote
  #8  
Old 04-02-2008, 06:35 PM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

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.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 10:48 AM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3