AlliedModders - Adding additional custom flags to Sourcemod

AlliedModders (https://forums.alliedmods.net/index.php)

- General (https://forums.alliedmods.net/forumdisplay.php?f=58)

- - Adding additional custom flags to Sourcemod (https://forums.alliedmods.net/showthread.php?t=183079)

Re: Adding additional custom flags to Sourcemod

Just use the admin overrides file to make commands for custom flags, I use one to make skins available to public players by using the 'p' flag and then just assign the flag to the player (or group) on sourcebans.

Your admin overrides text file would look like this..

Quote:

Overrides
{
/**
* By default, commands are registered with three pieces of information:
* 1)Command Name (for example, "csdm_enable")
* 2)Command Group Name (for example, "CSDM")
* 3)Command Level (for example, "changemap")
*
* You can override the default flags assigned to individual commands or command groups in this way.
* To override a group, use the "@" character before the name. Example:
* Examples:
* "@CSDM" "b" // Override the CSDM group to 'b' flag
* "csdm_enable" "bgi" // Override the csdm_enable command to 'bgi' flags
*
* Note that for overrides, order is important. In the above example, csdm_enable overwrites
* any setting that csdm_enable previously had.
*
* You can make a command completely public by using an empty flag string.
*/

"sm_admins" "b,z" //Only admins & owners to view online admins
"om_admin_credits" "z" //Owners only
"sm_god" "z" //godmode
"sm_noclip" "z" //noclip
"sm_models" "b,p" //skins
}

Re: Adding additional custom flags to Sourcemod

Perhaps it's suitable for commands, but some plugins also have actions or events and need to implement their own set of permissions.

Plugins could just use custom flags to control permissions to specific features, but that may conflict with the same flag in other plugins where you want access to one feature in one plugin, but not in another plugin.

Re: Adding additional custom flags to Sourcemod

Quote:

Originally Posted by rhelgeby (Post 1743781)

Perhaps it's suitable for commands, but some plugins also have actions or events and need to implement their own set of permissions.

Which should be mapped to a string that can be used with both regular and admin group overrides (which allow both a flag as in regular overrides, along with specific "allow" or "deny" access) with CheckCommandAccess.

Re: Adding additional custom flags to Sourcemod

So we could just make fake command strings like "myPlugin.myFeature" and override those instead? Though they would still need to be mapped to flags. In some cases it would be enough to just be a member of a group.

Re: Adding additional custom flags to Sourcemod

Quote:

Originally Posted by rhelgeby (Post 1743786)

Yes, although I'd advise using all lowercase and underscores to fit in with everything else (although then they might be confused with commands).

As for default flag mapping, it's just a matter of making sane choices (if it's a public plugin, else just go wild as you know how you'll be setting up overrides).

Some simple default recommendations (for things that don't have a sane equivalent flag of their own):
Public: 0
Any admin: Generic
No-one: Root

One silly thing some people do that could screw this up: Give other people the Root flag.
It's basically designed as a complete override to the admin system, for the server console.

Re: Adding additional custom flags to Sourcemod

Quote:

Originally Posted by asherkin (Post 1743791)

One silly thing some people do that could screw this up: Give other people the Root flag.
It's basically designed as a complete override to the admin system, for the server console.

It amazes me when people post here saying that they give all their admins root because they don't want to set up permissions then they ask how to prevent admins from doing x or y.

Re: Adding additional custom flags to Sourcemod

Quote:

Originally Posted by Dr. McKay (Post 1743942)

It amazes me when people post here saying that they give all their admins root because they don't want to set up permissions then they ask how to prevent admins from doing x or y.

It's like the process of elimination, done admin permissions style.

Give everyone all permissions and then find out who will abuse what and only remove those permissions from said abusive admins.