Plugin System
 

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.

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

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.

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.

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.

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*

In the long run, I think a plugin system would be more extensible than using a svn branch.

Not to mention, do you know how often they update the SVN? I personally would not want to have to go through and manually update a lot of stuff.

And #IFDEF's would not be used. What would eventually happen is that the original functions would be pointed to instead of being directly called, and the plugins would have the option of loading from a shared library (dll or so) that would simply redirect the pointer. Like Trev said, changes to the emu code would not directly hurt the plugin unless certain elements of the function that were required for the emu were changed, such as added variables.

The reason I started the thread was to discuss the pros and cons, and to gauge current interest, as like I said before, the idea has been brought up in the past, :)

I'm personally still trying to find my "thing" to do for the emu, since I don't play live and don't know a lot of the new features that currently exist in SoF/Beyond. Hence, I really can't code new stuff directly related to the game, at least in a live sense.

Try fix this MQ nonesence it's breaking EQemu.

I haven't looked too much into the macroquest thing, but from what I have heard, you'd probably need an application running in the background of whoever is running the client that checks to see if Macroquest is running. Which means, you'd need an additional component to the world/zone server, and it would have to be closed source for it to work effectively.

Care to give me more exact details about what MacroQuest does that crashes the servers/causes grief?

From my understanding of MQ, you can crash people clients with it. This is a real pain for pvp servers. You can warp around and zone and use a dmg command to kill creatures. It lets people track anything including people and a map hack that shows where everything is.

You can also crash zones with it, So yea its a real pain. You can also instant camp with it. There's more i just don't know what they are.

For the warping around / zoning, advanced checks would need to be added to verify that the person trying to move/zone is capable of moving that far in a set period of time.

For the damage command, I would need to discect the packet that is being sent to see exactly what is being inserted into it. If the client has that much control over damage calculations, that would be really odd.

As for the map hack, there is nothing you can really do server side for that. The server constantly updates positions for all characters/npcs in the zone, so you would need a program that prevents macroquest from running.

I can make something like that, but it would have to be up to each individual server to use it. It would also have to remain closed source to prevent someone from simply establishing a wrapper for macroquest that would bypass the system.

anything close source that will work will be a great addon to the eqemu :D no one likes it.

Let me ask you this then. Are the MQ users using the latest versions of MQ, or far outdated versions?

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.

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.

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

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

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.

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

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.

I do have to say that if you make any third party app that interferes in any way with the normal intented operation of the eq client (which apparently the one you mentioned making people run to play on bane of life or what ever the server name was) then you are in violation of the eula same as mq2 is and you can get a c&D tossed at you from soe and or they can sue ya so one might take that into consideration before doing anything clientside that alters how the client behaves or communicates with any given server altering the client even with third party apps is expressly forbade in the eula and as i understand it a big no no within the eqemu community as well

PLEASE add some periods to this. I can't see where a sentence starts or stops.

And a program that checks for MQ2 would not modify or access Everquest information, so it would not be in violation of the EULA.

mq2 works by accessing and reading the memory blocks that the eq client does that is why it is against the eula so is showeq, so any program that would run checks on the same stuff would also be a violation and he stated that, users would be forced to use a third party program to connect to the server. That means it is screwing with how the client communicates to the server or there would be no way possible to stop anyone not using it from connecting to the server.

My program would not have used a third party program to access the server. Rather, you would have to log into a 3rd party app that would monitor your PC for MQ2. If it found MQ2 loading or loaded, it would send a message to the server to ban you. No touching the memory blocks of EQ at all.

would it be open source? I doubt you will find many who would trust a program that they dont knowprecisly what it does when it has to do with monitoring your local pc and sending data to an outside source.

that is still however interfering with the normal function of the communication between the client and server your best bet would be to contact soe and ask their oppinion on it.

As for the memory blocks if you are monitoring the blocks for mq2 it would invariably monitor the main client blocks as that is what mq2 attaches to in order to function within the eq client itself.

In theory it sounds like a good idea but in practice noone would have any idea what kind of information it is monitoring and or what data it is sending to a server. Thats like having a back door just sitting there wide open from a security standpoint.

FYI, MQ2 performs a full system hook to monitor for the launching of EQ. So you do not need to monitor EQ to check for the existence of MQ2. And no, it is not interfering with communications. It is not reading/modifying/blocking any packets associated with Everquest. It does not touch the memory of Everquest, or even look at EQ with a loving glance.

And I'm not actually going to build this, for as I said earlier, doing so would be pointless.

Personally, running a new Pvp server, I plan to look into a certain key features that really mess with PvP.

Warping isn't a gigantic issue, since the code in there seems to catch a lot, even some false positives. Should look at players running at ungodly speed (bard/gm speed) without bard in group, players "instant camping", players able to see the whole map (Not so upset about that since ranger track works the same way, if it could be coded where players didn't get updates on locations on creatures too far that'd be awesome), there's a handful of other hacks out there.

You can bypass the key check apparantly (It's done on client side I think..)

I plan to write some traps in the server source and if people exploit certain systems once or twice their chars will put on a list and banned at my leisure. *shrugs*.