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.
Threaded Mode
