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, 11:06 AM

Quote:

Originally Posted by Shin Noir

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.

drakelord · #9 08-13-2009, 11:44 AM

Quote:

Originally Posted by Shin Noir

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*

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.

Zlandicar · #10 08-13-2009, 12:32 PM

Quote:

Originally Posted by drakelord

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.

drakelord · #11 08-13-2009, 01:33 PM

Quote:

Originally Posted by Zlandicar

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?

Zlandicar · #12 08-13-2009, 01:44 PM

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.

drakelord · #13 08-13-2009, 02:16 PM

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.

Zlandicar · #14 08-13-2009, 02:32 PM

anything close source that will work will be a great addon to the eqemu

no one likes it.

drakelord · #15 08-13-2009, 02:49 PM

Quote:

Originally Posted by Zlandicar

anything close source that will work will be a great addon to the eqemu

no one likes it.

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