[Darkwaltz4]

very glad you understood it as a beginner - I really didn't want to explain every little detail as the big picture is a little abstract itself.

You have it down pretty well! Again if you want to see real application of this, look at my demo links of hacks I've used it with.

This actually wouldn't be necessary if vBulletin reported the hook that is currently executing, but it doesn't, and the hook class needs to be edited to do so. My other goal I guess, was to provide a solution that end-users wouldnt have to do anything out of the ordinary to install, and certainly not do any file edits.

As for the minimum number of plugins "needed" is kind of blurry. One of the things this allows you to do is work on your plugins all at once in your favorite code editor. You could have one huge plugin in total, but would still be really useful to not copy/paste between the vB Plugin system. Of course, any extras like that would simply compound the problem. Then there is the fact that vB caches ALL active plugins in the datastore which are loaded on every single page as text stored in memory. You help your end-users with database memory, RAM, and speed by using this system, that much more so when they have dozens of hacks installed at once (One site in particular had over 250 hacks installed, and getting anything to load was a ten minute affair - imagine if all of his 1,000 plugins weren't sitting in memory in all their glory?)

About the only time you shouldn't bother putting plugin code in this system is if the line of code is one line long anyway and you don't intend to change it very often. About the only thing I can think of like that is the templategroup definition plugin :-p Finally, if at the end of development you see some plugins ended up as one line, then move those ones back into the vb plugin space

Thanks for reading!