[KissLick]

Ciao guys,

I am not sure if this is the right section... I forked SourceMod on GitHub and made a new native

PHP Code:

// Searches for console variables created by given plugin
//
// @param plugin        Plugin Handle (INVALID_HANDLE uses the calling plugin).
// @return                Adt array Handle on success, INVALID_HANDLE otherwise.
// @error                Invalid plugin handle or plugin was not found.
native ArrayList GetPluginConVars(Handle plugin); 


Can you please check if the code is correct and as it should be?
I am not very good with this yet... comparsion

P.S.: I made a little testing plugin and everything seems to work fine.

PHP Code:

#include <sourcemod>

public Plugin:myinfo =
{
    name = "Test-GetPluginConVars",
    author = "Raska",
    description = "Test GetPluginConVars",
    version = "0.1",
    url = ""
}

public OnPluginStart()
{
    new Handle:hArray = GetPluginConVars(FindPluginByFile("SomePlugin.smx"));
    // new Handle:hArray = GetPluginConVars(INVALID_HANDLE);
    
    if (hArray == INVALID_HANDLE) {
        LogMessage("hArray = INVALID_HANDLE");
        return;
    }
    
    new String:sCvarName[64];
    
    for (new i = 0; i < GetArraySize(hArray); i++) {
        GetConVarName(GetArrayCell(hArray, i), sCvarName, sizeof(sCvarName));
        LogMessage("Array[%d] = '%s'", i, sCvarName);
    }
    
    CloseHandle(hArray);
} 


[Powerlord]

Generally, if you want the SourceMod staff to review it, you'd create a Pull Request for it.

Having said that, I've only glanced at it, but you might want to call pContext->ThrowNativeError instead of logger->LogError. ThrowNativeError makes the SourceMod error log show a stack trace of the calling plugin.

[psychonic]

What is the intended use case for getting another or own plugin's convars?

[KissLick]

Originally Posted by Powerlord Having said that, I've only glanced at it, but you might want to call pContext->ThrowNativeError instead of logger->LogError. ThrowNativeError makes the SourceMod error log show a stack trace of the calling plugin.

Ok, thanks! :-)

Originally Posted by psychonic What is the intended use case for getting another or own plugin's convars?

So we can easily do something like:

• [INCLUDE] AutoExecConfig: Read and append to auto configs
• [INC] Copycfg
• [INC] Append new ConVars to plugin config v2.1

If it's not a part of the core.

And if we would have a way to get our own plugin's convars, why not to be able to get convars of any other plugin?

[psychonic]

Originally Posted by KissLick So we can easily do something like: [INCLUDE] AutoExecConfig: Read and append to auto configs [INC] Copycfg [INC] Append new ConVars to plugin config v2.1 If it's not a part of the core.

I think that it would be great if something like that were supported, but I also think that it would be better to implement it directly in core, which already has access to the plugins' var and the configs.

[KissLick]

Originally Posted by psychonic I think that it would be great if something like that were supported, but I also think that it would be better to implement it directly in core, which already has access to the plugins' var and the configs.

Should I try to do this as a part of core? Or you (sm team) would start something else like this?

[psychonic]

Originally Posted by KissLick Should I try to do this as a part of core? Or you (sm team) would start something else like this?

At the very least, I think that the existing AutoExecConfig should handle the appending of vars that are not already in the file, and possibly automatically add a comment noting any that are in an existing file but no longer in the plugin. I'm not sure if any further options are needed/wanted. I'm curious as to what the rest of the team thinks.

[asherkin]

Originally Posted by psychonic At the very least, I think that the existing AutoExecConfig should handle the appending of vars that are not already in the file, and possibly automatically add a comment noting any that are in an existing file but no longer in the plugin. I'm not sure if any further options are needed/wanted. I'm curious as to what the rest of the team thinks.

I'm definitely up for making AutoExecConfig smarter, but it's gonna need some hard thinking and proposals to build something future-proof that can survive sloppy editing (which is definitely a must when not just creating new files).

[KissLick]

So, can I pull request that native? Improving AutoExecConfig gonna take some time...

[psychonic]

While it's better than what's there now, I don't think that it makes sense to add something with planned obsolescence.