[shavit]

In what cases would the use of stock benefit me over the use of a function, if both do the exact same thing?

Sorry for the stupid question, I'm trying to optimize a few plugins and figured this might be a problem in OnGameFrame or OnPlayerRunCmd if functions will be more expensive in terms of resource hogging

[ddhoward]

stock functions are functions.

Can you give more detail as to what exactly you mean?

[shavit]

Originally Posted by ddhoward stock functions are functions. Can you give more detail as to exactly you mean?

I'm probably wrong, but what I remember is stock essentially 'pasting' the lines of code inside the stock to where ever I use it, so I assume that calling a function will take more time to process on the server side

[Impact123]

This has recently been discussed in this thread.

[ddhoward]

You are confusing stock and #define.

Labeling a function as "stock" merely tells the compiler to NOT compile the function into the plugin if the function isn't called anywhere. This is useful especially in include files where the plugin author may not have a need for every single function within the include.

#define'd functions, also called macro-functions, involve the compiler copy/pasting code. This functionality is slated for removal in future versions of Sourcemod, and should not be used.

[shavit]

Originally Posted by Impact123 This has recently been discussed in this thread.

Originally Posted by ddhoward You are confusing stock and #define. Labeling a function as "stock" merely tells the compiler to NOT compile the function into the plugin if the function isn't called anywhere. This is useful especially in include files where the plugin author may not have a need for every single function within the include. #define'd functions, also called macro-functions, involve the compiler copy/pasting code. This functionality is slated for removal in future versions of Sourcemod, and should not be used.

Thanks for explaining!

Another thing, in SourcePawn, if I don't add the public prefix, what does it actually change? We don't have object-orientation yet so I'm confused

[ddhoward]

A function that is not marked as "public" cannot be directly called by Sourcemod; only other functions within the plugin can call the function.

Timers, forwards like OnGameFrame()/OnClientConnect()/OnPluginStart(), or players using commands, are all things that require Sourcemod to be able to run a function at the given moment. Hence, these functions should all be marked as public by the plugin author.

https://wiki.alliedmods.net/Introduc...wn#Functions_2

[shavit]

Originally Posted by ddhoward A function that is not marked as "public" cannot be directly called by Sourcemod; only other functions within the plugin can call the function. Timers, forwards like OnGameFrame()/OnClientConnect()/OnPluginStart(), or players using commands, are all things that require Sourcemod to be able to run a function at the given moment. Hence, these functions should all be marked as public by the plugin author. https://wiki.alliedmods.net/Introduc...wn#Functions_2

So unless it's a global forward I don't need to add public, correct?

[ddhoward]

There is no reason to add public to a function's header unless the function needs to be called by something outside of the plugin. If the function only ever runs because it's being called by other functions within the same plugin, then leave it out.

[shavit]

Originally Posted by ddhoward There is no reason to add public to a function's header unless the function needs to be called by something outside of the plugin. If the function only ever runs because it's being called by other functions within the same plugin, then leave it out.

Thanks!