[fysiks]

If you wanted to put "everything in one 'plugin'" to be most efficient, you would need to put the content of all plugins and the entirety of AMX Mod X in a single module written in C++. This would make it impractical and extremely hard, for most people, to add or remove functionality.

So, adding modularity and simplification (which is the purpose of AMX Mod X) for adding and removing functionality, requires a little bit of overhead but the overall benefit is so massive that it is worth it.

Originally Posted by Spirit_12 I would always structure everything in one plugin simply because Natives will create overhead that can be avoided. Organization can be handled in different ways. For example, a comment block to specify what section you are working on works the same as having the code in different files.

Calling natives is not that big of deal and they create flexibility. Granted, if there is a simple way to avoid it in a for loop for example, then yeah, you would avoid it. But, on the whole, they are not that bad.

The only logical conclusion to your suggestion is that you should include all plugins in a single code block (including the entirety of AMX Mod X) making the system of adding and removing functionality untenable.

[HamletEagle]

Originally Posted by Spirit_12 I would always structure everything in one plugin simply because Natives will create overhead that can be avoided. Organization can be handled in different ways. For example, a comment block to specify what section you are working on works the same as having the code in different files.

Let's say I have a custom gun plugin and I hook Ham_Spawn in it to give the gun to everyone. Then I have a spawn protection plugin where I also hook Ham_Spawn. But I also have a plugin for player models where I use Ham_Spawn to set some models. And one more money system plugin where I also need to use Ham_Spawn.

According to your logic the best thing to do is copy paste 4 totally different plugins in the same file where the single connection between them is that all hook Ham_Spawn for the questionable advantage of not hooking Ham_Spawn 4 times.
And you are going to add comments everywhere stating that this function is from plugin x, this other function is from plugin y, this piece of code from function z is from plugin a, the other piece of code from z is from plugin b and so on.

If you honestly think that this is fine and not asking for troubles then I'm speechless. Are you programming for micro controllers where you lack the processing power/memory to store a few stack frames? Does calling a native require O(n^3) or something?

[CrazY.]

Have you ever think if hlsdk were made in a single file? It would be chaotic. Thanks to AMX Mod X developers for this API system.

[Spirit_12]

It seems my comment was taken out of context and the thing just went on a slippery slide.

All I was trying to say that instead of hooking the same function in multiple plugins just combine them to avoid redundancy. Here is an example, I use a plugin to change tank's health, make tank rocks burn and add force to tank's punch based on the number of survivors. It would be redundant to hook tank spawn 3 times, instead I can write code for all 3 features in the same plugin.

Nobody is saying that natives don't have their use, but they do add little overhead which is very much unnoticeable in all situations, but the initial question was about optimization.

[fysiks]

Originally Posted by Spirit_12 It seems my comment was taken out of context and the thing just went on a slippery slide. All I was trying to say that instead of hooking the same function in multiple plugins just combine them to avoid redundancy. Here is an example, I use a plugin to change tank's health, make tank rocks burn and add force to tank's punch based on the number of survivors. It would be redundant to hook tank spawn 3 times, instead I can write code for all 3 features in the same plugin. Nobody is saying that natives don't have their use, but they do add little overhead which is very much unnoticeable in all situations, but the initial question was about optimization.

If you are writing a new plugin that has multiple features that use the same forward then obviously you would put them in that single plugin.

However, there is no good reason to "optimize" by merging plugins.

[Spirit_12]

Originally Posted by fysiks However, there is no good reason to "optimize" by merging plugins.

I never said anything about merging. That was something that people assumed.

[HamletEagle]

Originally Posted by Spirit_12 I never said anything about merging. That was something that people assumed.

It really sounded like you were encouraging merging totally different plugins because this is what op was asking.
My bad.

[shadowcs1]

Originally Posted by HamletEagle It does not matter. Having clear and well structured code is way more important. If you just copy paste everything together you are only going to get a terrible mess that breaks at the smallest change.

That's not everything... At start when I started to program in C++ I've done a lot of things like this. Creating a program and another but which haves some relevance with the other one and I started to just copy paste the entire code (because at that time I didn't know how to include another program in my program). What do you think happened? Overload of course.

That can actually happen in pawn too. Never experienced, but it's possible. If the plugin consume like all modules and you script around 5-6 k line codes at least, I'm not sure if it will support. At some point it will break

[fysiks]

Originally Posted by Spirit_12 I never said anything about merging. That was something that people assumed.

Then I don't understand why you asked the question. If you are not merging plugins then you have to put all code that depends on a particular forward in that forward.