[Brad]

Generally speaking, would you rather have a single feature-packed plugin or the same plugin that has a core plugin and then child plugins that provide the features above the core functionality? Please indicate why you'd prefer one over the other.

Obviously with the single plugin approach, you may have any number of features that you don't use or even want. With the multiple plugins approach, you pick which features to have but you ultimately end up with a large number of individual plugins loaded.


Single Plugin, named "Sexy"
--------------------------
sexy.amxx
* bring sexy back
* disco lights
* ants in the pants
* chatastic
* dun dun dun


Multiple Plugins for the "Sexy" System
------------------------------------
sexy.amxx
* core functionality

sexy_bringitback.amxx
* bring sexy back

sexy_discolights.amxx
* disco lights

sexy_antspants.amxx
* ants in the pants

sexy_chatastic.amxx
* chatastic

sexy_dundundun.amxx
* dun dun dun

[anakin_cstrike]

Obviously with the single plugin approach, you may have any number of features that you don't use or even

That's the reason why i'd like to have a plugin for each or more commands. If want to, i can do 2 or more in 1.
An example is Amx Super: a lot of commands wich people rarely uses.

[minimiller]

I prefer the single plugins seeing as though theres less set-up to do
Makes it easier
=]

[C.H.U.D.]

Multiple plugins because I use a lot of per map config and ini files and I don't think that you can do that having 1 big plugin.

[Brad]

I'm just talking out loud right now...

Assuming good programming practices are observed, having a single plugin with many features wouldn't necessarily be very CPU intensive, compared the multiple plugin approach, as the various features not being used shouldn't ever be run. You do run into the increased memory footprint though.

Having multiple plugins would probably increase CPU activity if you utilize most (really depends on where the breaking point is) features of a plugin, as compared to using a single plugin.

I'm not sure how much impact either of those two statements would really have in practice. Both might be negligible in terms of impact and thus, shouldn't be entered into the debate. I'll leave this decision to someone more knowledgeable than I about the costs of both approaches.

[Arkshine]

If it's coded intelligently ( meaning each feature are modular and doesn't need extra cpu/memory if not used ), I would prefer one plugin. Otherwise severals plugins don't hurt and can be in specific case more appropriate. So, depending how the plugin is coded and how are the importance of this feature.

[Edit] I don't want to vote 'no preference' because it's depending the situation.

[Brad]

Originally Posted by minimiller I prefer the single plugins seeing as though theres less set-up to do Makes it easier =]

I would argue that it's not easier, just different. Assuming a multiple plugin approach, the plugin author should make it easy to enable or disable the various addon features, much like is done with the ATAC system. The ATAC system uses it's own plugins.ini file in which you can comment or uncomment any of the punishments (features in terms of this thread) easily enough.

Originally Posted by C.H.U.D. Multiple plugins because I use a lot of per map config and ini files and I don't think that you can't do that having 1 big plugin.

Assuming the single plugin has been coded properly, you should be able to enable/disable individual features using per map config files right now.

[C.H.U.D.]

There will always be something/several things that someone wants that won't be in the "plugin" meaning there will always be multiple plugins being used.

I hope I got that right

[Brad]

The reminded me that, in theory, it'd be easier for people with a little know-how to add their own feature plugins to the multiple plugin approach if the hooks in the core plugin are intelligently placed.

[AntiBots]

I Start creating with multi plugin all with native & Forwards and then I Start to put all in one.