[KyleS]

Huge thanks to Berni's Snippet.

What does this do?
Depends on what you do with it. However, the only function I'm immediately aware of is suppressing selected ConVar changes from being printed to chat.

Oh? Is that all?
Yes. Thanks!

... Are there any commands?
Indeed there are. As a matter of fact, there is only one.

sm_suppressconvar <convar> <enabled|disabled> - Whether to display changes of this ConVar to Chat or not.

Can you give an example?
Sure! sm_suppressconvar sm_nextmap enabled

THIS ALREADY EXISTS
Oh. Ok. Sorry! At this present time I'm unaware of any that are not hard coded.

[Sreaper]

Thanks Kyle! I've wanted something like this for awhile!

[Powerlord]

It amuses me that your code only checks the first letter. So, if I were to write

sm_suppressconvar mp_restartgame do

it would disable mp_restartgame's reporting.

Having said that, I wasn't aware that there was a server_cvar event.

It seems like a lot more work to hook server_cvar and do it there rather than just stripping FCVAR_NOTIFY from the cvar, though...

Edit: Also, I'm disappointed to see a plugin approver reusing the same string buffer for three different arguments in the same function. While you could argue it's efficient, it's very hard to maintain later.

[thetwistedpanda]

*sigh*, refraining from the many negative comments the above poster really deserves, nice work Kyle. Didn't realize the server_cvar event existed either!

[Powerlord]

Originally Posted by thetwistedpanda *sigh*, refraining from the many negative comments the above poster really deserves, nice work Kyle. Didn't realize the server_cvar event existed either!

Feel free to leave me any negative comments that you want. It doesn't change the fact that the method this plugin author references in this post is likely more efficient than the way this plugin works.

[alongub]

Originally Posted by Powerlord Also, I'm disappointed to see a plugin approver reusing the same string buffer for three different arguments in the same function. While you could argue it's efficient, it's very hard to maintain later.

Since this is a rather small plugin, I think that the "hard to maintain" argument is not relevant here.

[asherkin]

Originally Posted by Powerlord It amuses me that your code only checks the first letter. So, if I were to write sm_suppressconvar mp_restartgame do it would disable mp_restartgame's reporting.

Awesome optimization there.

Originally Posted by Powerlord It seems like a lot more work to hook server_cvar and do it there rather than just stripping FCVAR_NOTIFY from the cvar, though...

Stripping FCVAR_NOTIFY would remove them from the A2S_RULES response.

[KyleS]

Originally Posted by Powerlord It amuses me that your code only checks the first letter. So, if I were to write sm_suppressconvar mp_restartgame do it would disable mp_restartgame's reporting.

Actually, you're incorrect, doing so would remove mp_restartgame from the trie. However, if you were to use the shorthand sm_suppressconvar mp_restartgame e , this would do what you're wanting. If it makes you happy I can totally check with StrEqual for disable and enable, as I do in some other plugins.

Originally Posted by Powerlord It seems like a lot more work to hook server_cvar and do it there rather than just stripping FCVAR_NOTIFY from the cvar, though...

As Asherkin pointed out in the 6th post, this causes A2S_Rules to become out of sync. I recently rewrote every single plugin I use (Came to about 30~, I'm still writing), which is why I posted this instead of going the incorrect route and stripping FVCAR_NOTIFY. Sure it's easier, but no one wants to be the cause of breakage on a server.

Originally Posted by Powerlord Edit: Also, I'm disappointed to see a plugin approver reusing the same string buffer for three different arguments in the same function. While you could argue it's efficient, it's very hard to maintain later.

I don't see this growing. I also didn't see a point in wasting arrays. If functionality has been lost as a result of this, please let me know. Upon request I can also totally add a verbose syntax checker.

If you have any further questions or concerns in regards to this plugin please let me know.

EDIT: Oops!

Originally Posted by Powerlord Feel free to leave me any negative comments that you want. It doesn't change the fact that the method this plugin author references in this post is likely more efficient than the way this plugin works.

I didn't say that! What I had said was I had made a mistake with said Snippet. Even looking at it now, CloseHandle shouldn't be there either. However, it has no effect on ConVars (As far as I'm aware), so it isn't unsafe or anything.

If I were to rewrite the above hard coded snippet, it would look something like this.

PHP Code:

#pragma semicolon 1
#include <sourcemod>

public OnPluginStart()
{
    new Handle:hCVarHandle = INVALID_HANDLE;
    new iFlags;
    
    new String:sCVars[][] = {"bot_quota", "mp_startmoney", "mp_flashlight", "sv_cheats"};
    for(new i = 0; i < sizeof(sCVars); i++)
    {
        hCVarHandle = FindConVar(sCVars[i]);
        if (hCVarHandle == INVALID_HANDLE)
        {
            LogError("Couldn't find %s. What sort of game is this?", sCVars[i]);
            continue;
        }
        
        iFlags = GetConVarFlags(hCVarHandle);
        if (!(iFlags & FCVAR_NOTIFY))
        {
            continue;
        }
        
        iFlags &= ~FCVAR_NOTIFY;
        SetConVarFlags(hCVarHandle, iFlags);
    }
} 


There's nothing stopping another plugin from re-adding FCVAR_NOTIFY back to those convars, which is another reason why this is a bad method.

[Powerlord]

Originally Posted by KyleS I don't see this growing. I also didn't see a point in wasting arrays. If functionality has been lost as a result of this, please let me know. Upon request I can also totally add a verbose syntax checker. If you have any further questions or concerns in regards to this plugin please let me know.

It's a matter of readability, not functionality. sCommand means 3 different things at different points:

1. The command name at the first ReplyToCommand.
2. The second argument at the StringToInt.
3. The first argument at the second, third, and fourth ReplyToCommands.

This is one of those things that makes maintenance programmers (want to) kill previous programmers.

Speaking of functionality, it might be a good idea to check if the ConVar exists (checking FindConVar against INVALID_HANDLE) before adding it to the trie, returning common.phrases's "Unable to find cvar" phrase if not found:

PHP Code:

// In OnPluginStart
    LoadTranslations("common.phrases");

// in OnSupressConVar's case 0:
            new Handle:convar = FindConVar(sCommand);
            
            if (convar == INVALID_HANDLE)
            {
                ReplyToCommand(client, "%s%t", PLUGIN_PREFIX, "Unable to find cvar", sCommand);
                return Plugin_Handled;
            }
            else
            {
                CloseHandle(convar);
            } 


[KyleS]

Originally Posted by Powerlord It's a matter of readability, not functionality. sCommand means 3 different things at different points:

I agree that separate variables would be awesome. However we don't have pointers in Pawn, so while it's an excuse for this, it's mine. If we could point to arrays with a single cell, that would make my day.

Originally Posted by Powerlord 1. The command name at the first ReplyToCommand.

Said buffer is only used when argc is < 2 (If memory serves me right). This is there so we're not hard coding command names. At the bottom of the if (argc < 2), there should be a return Plugin_Handled, otherwise you've found a major issue! If so, thanks! It's there so if someone adds the alias sm_powerlordcvarsuppressionsuperawesomecomman d and points it to the function, no changes will be required and the same will happen.

Originally Posted by Powerlord 2. The second argument at the StringToInt.

Totally! As you can see, the result of the operation on the buffer is stored to a cell with a value of 0 or 1. -1 if it's unknown or invalid.

Originally Posted by Powerlord 3. The first argument at the second, third, and fourth ReplyToCommands.

Second argument to the second, third, and fourth ReplyToCommand. In this case it's changed to the cvar that it is suppressing.

Originally Posted by Powerlord This is one of those things that makes maintenance programmers (want to) kill previous programmers.

A better fitting name for the Array would be Junk or something I suppose? sCommand made sense as it's the command name for the first, then turns into the 2nd arg, and then the first. If this was C, I'd have 3 char pointers to show this, but it isn't. If I add comments would it help you? I normally do, but this was more of a "Oh, this doesn't exist. I'll share it." thing.

Originally Posted by Powerlord Speaking of functionality, it might be a good idea to check if the ConVar exists (checking FindConVar against INVALID_HANDLE) before adding it to the trie, returning common.phrases's "Unable to find cvar" phrase if not found: PHP Code: // In OnPluginStart     LoadTranslations("common.phrases"); // in OnSupressConVar's case 0:             new Handle:convar = FindConVar(sCommand);                          if (convar == INVALID_HANDLE)             {                 ReplyToCommand(client, "%s%t", PLUGIN_PREFIX, "Unable to find cvar", sCommand);                 return Plugin_Handled;             }             else             {                 CloseHandle(convar);             }

Good idea! The only bad thing I can see coming from this is late loading a plugin then expecting the ConVar to be suppressed when this actually errored out.