Plugin System

drakelord · #1 08-12-2009, 07:10 PM

So, over the years, I've heard mentions of people asking for a plugin system here and there. Obviously, such a system has yet to be added to the code, and in many cases, probably for good reason.

I have been contemplating coding a plugin system for the emu, as a separate branch at first (at least until it proved to be a worthwhile, bug free solution), but before I even start drafting such an idea, I must ask.

Who would use the system, and what would they use it for? Specifics would be nice here, as well as a voice on if you would or would not use it and why.

**trevius** · #2 08-12-2009, 09:02 PM

Can you explain more about what you mean by a "plugin system"? Maybe give an example or something?

Randymarsh9 · #3 08-12-2009, 10:42 PM

Yeah I don't get it either. Maybe it means something like how when you make custom content for Oblivion or Morrowind it saves it in a plug in which you can enable or disable to utilize it. That's my best guess, but I'm probably wrong.

drakelord · #4 08-12-2009, 10:59 PM

Quote:

Originally Posted by trevius

Can you explain more about what you mean by a "plugin system"? Maybe give an example or something?

Pretty much, a system that would allow you to modify current functions without having to rewrite the code directly. It would allow for easy distribution between developers for custom systems and what not.

Taurinus · #5 08-12-2009, 11:45 PM

I suppose it could be handy to be able to provide certain functions externally via a plugin, but I have to ask:

Who could write a plugin, compile it, and distribute it?

Out of those people, who cannot make changes to the server source, compile it, link it, and distribute it?

My guess is noone. Not hating on you, just pointing that out.

**trevius** · #6 08-13-2009, 08:22 AM

Quote:

Originally Posted by Taurinus

I suppose it could be handy to be able to provide certain functions externally via a plugin, but I have to ask:

Who could write a plugin, compile it, and distribute it?

Out of those people, who cannot make changes to the server source, compile it, link it, and distribute it?

My guess is noone. Not hating on you, just pointing that out.

His point is not to find alternative ways to add things we would normally just add directly to the source code, he is wanting the give the option of completely reworking how some systems are handled. So, if you wanted to add some new custom commands, or maybe change how some core systems work, you could do that and then still stay current with EQEmu, since the plugin will be compatible with the new version as well. I think this would allow for greater flexibility into the custom server world. At least that is if I am understanding the concept correctly.

**Shin Noir** · #7 08-13-2009, 10:07 AM

Though #IFDEF's aren't that tacky, like you use for the bot system. Each plugin may start adding a lot of them, in most cases you are likely better off to start a fork project of the PEQ source than you are to try to create a plugin system.

E.g. have your seperate source, with a bunch of options set via rule_values or something, to verify what kind of stuff you want "plugged" into the source.

Plugins are usually more for those who want to optionally have some sort of "add on" to the original code. And those add ons, if very customized, are probably easier to manage via a seperate SVN tree and just make it your responsibility to keep it up to date with the latest SVN branch than have plugins that need to keep compatible with the latest SVN as 3rd party mods to it essentially... not to mention you need to debug a plugin system, etc..

*shrugs*

pfyon · #8 08-13-2009, 03:17 PM

Disclaimer: I have no experience with MQ2 or the packets sent between the server and client. All of my responses are based off the assumption that eq was designed and programmed properly (ie, don't let your client choose how much dmg it wants to do).

As drakelord said, warping can be easily checked server-side (check locations of the player in a time frame, check buffs/effects and see if it's possible to move that far).

Damage should be calculated by the server anyway, and clients shouldn't be able to communicate directly, so I don't understand how dmg hacks work.

I did download the mq2 source the other day so I could look at how it works, but haven't gotten around to it.

drakelord · #9 08-13-2009, 05:06 PM

Quote:

Originally Posted by pfyon

Disclaimer: I have no experience with MQ2 or the packets sent between the server and client. All of my responses are based off the assumption that eq was designed and programmed properly (ie, don't let your client choose how much dmg it wants to do).

As drakelord said, warping can be easily checked server-side (check locations of the player in a time frame, check buffs/effects and see if it's possible to move that far).

Damage should be calculated by the server anyway, and clients shouldn't be able to communicate directly, so I don't understand how dmg hacks work.

I did download the mq2 source the other day so I could look at how it works, but haven't gotten around to it.

I actually found the version that is used on the current EMU. It works through applying hooks. So an application to block it would pretty much end up moving towards a hook war. Mmm, hooks.

Taurinus · #10 08-13-2009, 07:09 PM

Yea, and not to mention the fact that a user can rootkit their OS to determine a winner forever (MQ). Not even enforcing a hacked client (not possible) could get around this.

Tyen05 · #11 08-13-2009, 07:48 PM

If you can make it, than do it. If people have a need for it they will use it.

demonstar55 · #12 08-14-2009, 01:13 AM

There is no easy way to "fix" the MQ2 "problem"

and yes, anything that is done client side can be exploited

as far as I know, there are no dmg hacks for MQ2

Some odd things that can be hacked are safe fall, falling damage, encumbrance, vision (ultra vision etc), equipping items you can't and using their clickies etc (believe EQEmu code has pretty good protection against this, as in it reports it accurately), invis, sneak

Warping there isn't really a way to fix this, best thing to combat this is checking for change in loc, which the code is already doing, but it generates false positives :/

but of course this can be prevented by forcing the user to run an app on their computer like bane of life plans on doing

MQ2 is mainly a huge problem for PVP, which I understand completely, PVE it only adds problems from the active hacks, mostly

drakelord · #13 08-14-2009, 06:01 AM

Quote:

Originally Posted by Taurinus

Yea, and not to mention the fact that a user can rootkit their OS to determine a winner forever (MQ). Not even enforcing a hacked client (not possible) could get around this.

The MQ2 detector would essentially be an active running root kit that can be turned on and off. It would use the WH_DEBUG hook. Problem is, I'm not sure if two applications both have WH_DEBUG hooks, which will run first.

norsan · #14 08-14-2009, 08:53 AM

im sory but i would never play on any emu server that would force me to install a third party app in order to play on it call me paranoid but theres no telling what would be in it and if the source for such an app was released well then it would then become useless anyway... interesting connundrum

drakelord · #15 08-14-2009, 10:24 AM

Yea. Looking at the MQ source, even client side, there is only so much that can be done about this program.

MQ is completely open source, meaning anyone can make changes to the program and recompile it. It blocks itself from debugger checks by modifying assembly values in the first few sequences of code. Meaning, the only real easy way to check if MQ is running is to check the currently running modules (DLLs) and see if any of the MQ files are running.

One situation there is that someone could change the name of the DLLs. So, to do a further check at this point, you could obtain the memory address of the modules and check one of the functions based on the ordinal numbers, and see if it returns an expected value. But if someone were to find a way to decompile the checker and figure out what is being inspected, all they would have to do is change that function.

Client side checks are hard. It is why Everquest Live still has issues with MacroQuest, and why companies like GameGuard constantly have to update their programs.

In the end, the best we can do is just put in extra checks into the server code, to help prevent certain issues.