AlliedModders Wiki - User contributions [en]

Reserved Slots (SourceMod)

2010-08-29T15:47:49Z

Kilandor: /* Reserve Slots */ fixed incorrect cvar

==Cvars==

*[[#Reserve Type|sm_reserve_type <0|1|2>]]
*[[#Reserve Slots|sm_reserve_slots <#>]]
*[[#Hidden Slots|sm_hide_slots <0|1>]]
*[[#Max Admins|sm_reserve_maxadmins <#>]]
*[[#Kick Type|sm_reserve_kicktype <0|1|2>]]

==Reserve Type==

sm_reserve_type <0|1|2>

This controls how reserve slots work on the server (the default is 0).

* <tt>sm_reserve_type 0</tt>

Public slots are used in preference to reserved slots. Reserved slots are freed before public slots.
No players are ever kicked and once reserved slots are filled by a reserve slot player (and the rest of the server is full) they will remain occupied until a player leaves.
The use of this is that there can always be at least one admin (assuming you only give reserved slots to admins) on the server at any time. If players inform you that there is a hacker on the server, at least one admin should be able to get it and do something about it.
If a player without reserve slot access joins when there are only reserved spaces remaining they will be kicked from the server.

* <tt>sm_reserve_type 1</tt>

If someone with reserve access joins into a reserved slot, the player with the highest latency and without reserve access (spectator players are selected first) is kicked to make room. Thus, the reserved slots always remain free. The only situation where the reserved slot(s) can become properly occupied is if the server is full with reserve slot access clients.
This is for servers that want some people to have playing preference over other. With this method admins could one by one join a full server until they all get in.

* <tt>sm_reserve_type 2</tt> - Only available in SourceMod 1.1 or higher.

The same as sm_reserve_type 1 except once a certain number of admins have been reached the reserve slot stops kicking people and anyone can join to fill the server.
You can use this to simulate having a large number of reserved slots with sm_reserve_type 0 but with only need to have 1 slot unavailable when there are less admins connected.

==Reserve Slots==

sm_reserved_slots <#>

This controls how many slots get reserved by the plugin (the default is 0).

Using sm_reserve_type 0 this is how many admins can join the server after it appears full to the public.
Using sm_reserve_type 1 this is how many slots are saved for swapping admins in (you shouldn't need more than one)

==Hidden Slots==

sm_hide_slots <0|1>

This controls the plugin hides the reserved slots (the default is 0).

If enabled (1) reserve slots are hidden in the server browser window when they are not in use. For example a 24 player server with 2 reserved slots will show as a 22 player server (until the reserved slots are occupied).
To connect to the reserved slot of a server that shows as full you will need to use 'connect ip:port' in console. (e.g. 'connect 192.168.1.100:27015')

There is no possible way for the reserved slots to be visible to admins and hidden from normal users. Admin authentication can only happen after the user is fully connected to the server and their steam id is available to SourceMod. For this reason it is often better to hide the slots otherwise public users will attempt to join the server and will get kicked again (rendering the ‘autojoin’ feature useless)

==Max Admins==

sm_reserve_maxadmins <#> - Only available in SourceMod 1.1 or higher.

This controls how many admins can join the server before the reserved slots are made public (only relevant to sm_reserve_type 2)

==Kick Type==

sm_reserve_kicktype <0|1|2> - Only available in SourceMod 1.1 or higher.

This controls how a client is selected to be kicked (only relevant to sm_reserve_type 1/2)

Clients with reserve slot access or the override 'sm_reskick_immunity' are always immune to being kicked. Spectating clients are chosen before playing clients.

0 - Highest Ping<br>
1 - Highest Connection Time<br>
2 - Random Player<br>

==Immunity==

To make players immune from being kicked by the reserved slots plugin they need to have access to the override 'sm_reskick_immunity' (users with root or reserved slot access are already immune).

NB: This is only relevant when using sm_reserve_type 1/2.

You can either assign this override to a flag using admin_overrides.cfg (e.g. "sm_reskick_immunity" "o" - to give all users with flag 'o' (custom flag 1) immunity from being kicked)

Or

Give groups access to the overrides in admin_groups.cfg (e.g. "sm_reskick_immunity" "allow")

Then add your VIP members or other users you wish to be immune from being kicked as admins with either the flag you specified or as members of the group you gave access to. (You can create a group with 0 flags and ‘0’ normal immunity and only this override if you don't want them to have any other privileges)

Full details on overriding command access can be found at [[Overriding Command Access (SourceMod)]]

==Possible Future Additions==

These are possible feature additions that have been requested and are under consideration for inclusion in later versions of SourceMod

*Choice to redirect players instead of kicking.

[[Category:SourceMod Documentation|Categories]]

Admin API (SourceMod)

2010-07-18T01:28:05Z

Kilandor: Undo revision 7777 by Kilandor (Talk) - I was completley wrong

The SourceMod Administration API abstracts user permissions for administration actions. Permissions are stored across two primary object types: ''Admins'', which define per-user permission sets, and ''Groups'', which define permission sets that are meant to be inherited by one or more users.

=Introduction=
It is important to note the purpose of the Administration API: '''It is a cache, not a permanent data store'''. It is designed such that external data sources can load objects into the cache for optimizing in two different ways: Fast Lookup, and On-Demand Lookup

Fast Lookup is ideal for storage methods which do not have inherently fast lookup, but are small enough to be easily cached in memory. The flat file implementation admin format of SourceMod fits this scenario. The entire file is read and stored in the cache.

On-Demand Lookup is ideal for storage methods which work over a network, or contain a large number of entries unsuitable for full retrieval, but fast atomic lookup. This is what SQL is good at. The SQL implementation of the SourceMod admin reader only stores admins in the cache once they have connected.

Note the difference between the two: In the first example, the cache is being used as a lookup mechanism itself, as well as storing the permissions. In the second example, the cache is being used ''only'' to store permissions, since lookup was done by the SQL server.

=Permissions=
==Admin Flags==
Permissions are granted through the ''AdminFlag'' data type. Each flag specifies an action or permission type that requires administrative access. For each admin, the set of flags which are enabled is called the admin's ''effective permissions''.

AdminFlags are stored in a variety of ways to account for various coding flexibilities. Functions to convert in between these storage methods are available in the administration APIs for both C++ extensions and Pawn scripts.
*<tt>AdminFlag</tt>: Represents a single admin permission as part of an enumeration.
*<tt>AdminFlag[]</tt>: Represents an array of AdminFlags in no specific order, each member being a different flag enabled.
*<tt>bool[]</tt>: Represents a bit array, where each index <tt>i</tt> of the array specifies whether AdminFlag <tt>i</tt> is enabled (true) or disabled (false).
*<tt>FlagBits</tt>: Represents an unsigned 32bit integer, where each bit <tt>n</tt> of the integer specifies whether AdminFlag <tt>n</tt> is enabled (bit 1) or disabled (bit 0). Convenience macros are available for dealing with bitwise numbers. They are found in <tt>IAdminSystem.h</tt> and each start with <tt>ADMFLAG</tt> instead of <tt>Admin</tt>.

==Overrides==
Permissions can also be granted through ''overrides''. Overrides are specific permissions that override the default effective permissions. They can act on both commands and command groups (a command group is a set of commands under a common name). There are two types of overrides:
*'''Global Overrides''': These override the default admin flag(s) required for a given command or command group.
*'''Group Overrides''': These override whether members of the group can or cannot access a given command.

==Immunity==
Immunity in SourceMod is based on ''immunity levels'', which are arbitrary numbers greater than or equal to zero. If an admin has an immunity level of 0, that admin has no immunity. An admin can only target other admins if their immunity level is greater than or equal to the target's immunity level. This functionality can be tweaked via <tt>sm_immunity_mode</tt> in <tt>cfg/sourcemod.cfg</tt>.

<ol>
<li>If the targeting AdminId is <tt>INVALID_ADMIN_ID</tt> (not an admin), targeting fails.</li>
<li>If the targeted AdminId is <tt>INVALID_ADMIN_ID</tt> (not an admin), targeting succeeds.</li>
<li>If the targeted AdminId is the same as the targeting AdminId (i.e. self-targeting), then targeting succeeds.</li>
<li>If the targeting admin is root, targeting succeeds.</li>
<li>If the targeted admin has access higher than the targeting admin (determined by the <tt>sm_immunity_mode</tt> rules), then targeting fails.</li>
<li>If the targeted admin has specific immunity from the targeting admin via group immunities, targeting fails.</li>
<li>Targeting succeeds.</li>
</ol>

The primary function for computing immunity is <tt>CanUserTarget()</tt> (clients.inc).

=Cache Types=
There are three cache types in the Administration API. To ''invalidate'' a cache means to entirely delete it and rebuild it from scratch. Rebuilding a cache means requesting each IAdminListener to rebuild that portion of the cache. Aside from rebuilding a cache, there are generally three major operations to each cache: Reading, Appending (adding new settings), and Deleting (deleting individual records).

*'''Global Override Cache''': Holds global overrides.
**Invalidation: Atomic
**Readable: Yes
**Appendable: Yes
**Deletable: Yes
*'''User Cache''': Holds Admin User objects.
**Invalidation: Atomic
**Readable: Yes
**Appendable: Yes
**Deletable: Yes
*'''Group Cache''': Holds Admin Group objects.
**Invalidation: Invalidates self and Admin Cache.
**Readable: Yes
**Appendable: Yes
**Deletable: No

==Global Override Cache==
The global override cache stores information about global overrides. Every operation to this cache occurs both retroactively and for future command creations. An override need not be tied to a command; however, if a command has the same name, the command will inherit that override's permissions.

===Writing/Appending===
New entries to the global override cache will affect both already existing commands and future commands registered during the cache's lifetime.

Each command can be assigned any or no access flags.

===Deleting/Invalidation===
Deleting a part or the whole of the global override cache will cause affected commands to revert to their original access behavior.

==Group Cache==
The group cache scores all information about current groups. It is designed to be quite static, and thus modifying groups in memory is not very flexible.

Groups have a few important properties:
*'''Add Flags''': These are flags added to any user who inherits the group.
*'''Immunity''': Specifies rules for which admins cannot target this group.
*'''Immunity Level''': If a user inheriting the group has a lower immunity level than this number, they inherit the new higher value from the group.
*'''Specific''': Immunity from a list of specific groups.
*'''Overrides''': Allows commands or command groups to be allowed or denied to this group.

===Writing/Appending===
*'''Add Flags''': These can be modified at any time. However, users which inherit the group will not have their member permissions updated for performance reasons.
*'''Immunity''': Default and global immunity can be changed at any time. Users inheriting the group will be affected by the changes. Specific immunity can have new groups added (and it will affect member admins).
*'''Overrides''': Overrides can be changed between allow or deny at any time.

===Deleting/Invalidation===
Per-group immunities cannot be removed once added. Groups themselves cannot be removed either, as this would be a potentially expensive operation. Instead, the entire group cache must be rebuilt (and with it, the admin cache). The goal with this design decision is to make group invalidations rare. In order to change a group fully, the entire admin cache must be "refreshed."

==Admin/User Cache==
The user cache stores all information about currently known admins. Users stored can either be ''live'' (as in, their permissions are currently in use by a player), or ''idle'' (cached for future lookup).

Users have the following properties:
*'''Flags''': These are the permission flags the admin inherits by default.
*'''Effective Flags''': These are the permission flags the admin has at runtime. They are a combination of the base flags and the flags inherited from groups.
*'''Groups''': The groups the admin is a member of.
*'''Password''': A generic password that an authentication method might require.
*'''Identities''': One or more mappings between authentication methods and unique identification strings.

===Writing/Appending===
*'''Flags''': Flags can be changed at any time. Changing flags will affect effective flags, even if done after groups are inherited.
*'''Groups''': Groups can be inherited at any time, although a group cannot be inherited twice. Permissions inherited from groups cannot be updated (yet).
*'''Password''': Passwords can be changed at any time.
*'''Identities''': Identities can be added, but not changed or removed.

===Deleting/Invalidation===
Groups cannot be removed from an admin's inherited group list. However, admins can be invalidated. This lets an authentication system, such as SQL, remove individual admins to refresh their privileges. Resources used by an admin object are always reclaimed efficiently.

[[Category:SourceMod Development]]
[[Category:SourceMod Scripting]]

Admin API (SourceMod)

2010-07-18T01:06:34Z

Kilandor: /* Admin Flags */ added list of flags, since they are not found in api, and require digging into source files

The SourceMod Administration API abstracts user permissions for administration actions. Permissions are stored across two primary object types: ''Admins'', which define per-user permission sets, and ''Groups'', which define permission sets that are meant to be inherited by one or more users.

=Introduction=
It is important to note the purpose of the Administration API: '''It is a cache, not a permanent data store'''. It is designed such that external data sources can load objects into the cache for optimizing in two different ways: Fast Lookup, and On-Demand Lookup

Fast Lookup is ideal for storage methods which do not have inherently fast lookup, but are small enough to be easily cached in memory. The flat file implementation admin format of SourceMod fits this scenario. The entire file is read and stored in the cache.

On-Demand Lookup is ideal for storage methods which work over a network, or contain a large number of entries unsuitable for full retrieval, but fast atomic lookup. This is what SQL is good at. The SQL implementation of the SourceMod admin reader only stores admins in the cache once they have connected.

Note the difference between the two: In the first example, the cache is being used as a lookup mechanism itself, as well as storing the permissions. In the second example, the cache is being used ''only'' to store permissions, since lookup was done by the SQL server.

=Permissions=
==Admin Flags==
Permissions are granted through the ''AdminFlag'' data type. Each flag specifies an action or permission type that requires administrative access. For each admin, the set of flags which are enabled is called the admin's ''effective permissions''.

AdminFlags are stored in a variety of ways to account for various coding flexibilities. Functions to convert in between these storage methods are available in the administration APIs for both C++ extensions and Pawn scripts.
*<tt>AdminFlag</tt>: Represents a single admin permission as part of an enumeration.
*<tt>AdminFlag[]</tt>: Represents an array of AdminFlags in no specific order, each member being a different flag enabled.
*<tt>bool[]</tt>: Represents a bit array, where each index <tt>i</tt> of the array specifies whether AdminFlag <tt>i</tt> is enabled (true) or disabled (false).
*<tt>FlagBits</tt>: Represents an unsigned 32bit integer, where each bit <tt>n</tt> of the integer specifies whether AdminFlag <tt>n</tt> is enabled (bit 1) or disabled (bit 0). Convenience macros are available for dealing with bitwise numbers. They are found in <tt>IAdminSystem.h</tt> and each start with <tt>ADMFLAG</tt> instead of <tt>Admin</tt>.
**<tt>ADMFLAG_RESERVATION</tt>
**<tt>ADMFLAG_GENERIC</tt>
**<tt>ADMFLAG_KICK</tt>
**<tt>ADMFLAG_BAN</tt>
**<tt>ADMFLAG_UNBAN</tt>
**<tt>ADMFLAG_SLAY</tt>
**<tt>ADMFLAG_CHANGEMAP</tt>
**<tt>ADMFLAG_CONVARS</tt>
**<tt>ADMFLAG_CONFIG</tt>
**<tt>ADMFLAG_CHAT</tt>
**<tt>ADMFLAG_VOTE</tt>
**<tt>ADMFLAG_PASSWORD</tt>
**<tt>ADMFLAG_RCON</tt>
**<tt>ADMFLAG_CHEATS</tt>
**<tt>ADMFLAG_ROOT</tt>
**<tt>ADMFLAG_CUSTOM1</tt>
**<tt>ADMFLAG_CUSTOM2</tt>
**<tt>ADMFLAG_CUSTOM3</tt>
**<tt>ADMFLAG_CUSTOM4</tt>
**<tt>ADMFLAG_CUSTOM5</tt>
**<tt>ADMFLAG_CUSTOM6</tt>

==Overrides==
Permissions can also be granted through ''overrides''. Overrides are specific permissions that override the default effective permissions. They can act on both commands and command groups (a command group is a set of commands under a common name). There are two types of overrides:
*'''Global Overrides''': These override the default admin flag(s) required for a given command or command group.
*'''Group Overrides''': These override whether members of the group can or cannot access a given command.

==Immunity==
Immunity in SourceMod is based on ''immunity levels'', which are arbitrary numbers greater than or equal to zero. If an admin has an immunity level of 0, that admin has no immunity. An admin can only target other admins if their immunity level is greater than or equal to the target's immunity level. This functionality can be tweaked via <tt>sm_immunity_mode</tt> in <tt>cfg/sourcemod.cfg</tt>.

<ol>
<li>If the targeting AdminId is <tt>INVALID_ADMIN_ID</tt> (not an admin), targeting fails.</li>
<li>If the targeted AdminId is <tt>INVALID_ADMIN_ID</tt> (not an admin), targeting succeeds.</li>
<li>If the targeted AdminId is the same as the targeting AdminId (i.e. self-targeting), then targeting succeeds.</li>
<li>If the targeting admin is root, targeting succeeds.</li>
<li>If the targeted admin has access higher than the targeting admin (determined by the <tt>sm_immunity_mode</tt> rules), then targeting fails.</li>
<li>If the targeted admin has specific immunity from the targeting admin via group immunities, targeting fails.</li>
<li>Targeting succeeds.</li>
</ol>

The primary function for computing immunity is <tt>CanUserTarget()</tt> (clients.inc).

=Cache Types=
There are three cache types in the Administration API. To ''invalidate'' a cache means to entirely delete it and rebuild it from scratch. Rebuilding a cache means requesting each IAdminListener to rebuild that portion of the cache. Aside from rebuilding a cache, there are generally three major operations to each cache: Reading, Appending (adding new settings), and Deleting (deleting individual records).

*'''Global Override Cache''': Holds global overrides.
**Invalidation: Atomic
**Readable: Yes
**Appendable: Yes
**Deletable: Yes
*'''User Cache''': Holds Admin User objects.
**Invalidation: Atomic
**Readable: Yes
**Appendable: Yes
**Deletable: Yes
*'''Group Cache''': Holds Admin Group objects.
**Invalidation: Invalidates self and Admin Cache.
**Readable: Yes
**Appendable: Yes
**Deletable: No

==Global Override Cache==
The global override cache stores information about global overrides. Every operation to this cache occurs both retroactively and for future command creations. An override need not be tied to a command; however, if a command has the same name, the command will inherit that override's permissions.

===Writing/Appending===
New entries to the global override cache will affect both already existing commands and future commands registered during the cache's lifetime.

Each command can be assigned any or no access flags.

===Deleting/Invalidation===
Deleting a part or the whole of the global override cache will cause affected commands to revert to their original access behavior.

==Group Cache==
The group cache scores all information about current groups. It is designed to be quite static, and thus modifying groups in memory is not very flexible.

Groups have a few important properties:
*'''Add Flags''': These are flags added to any user who inherits the group.
*'''Immunity''': Specifies rules for which admins cannot target this group.
*'''Immunity Level''': If a user inheriting the group has a lower immunity level than this number, they inherit the new higher value from the group.
*'''Specific''': Immunity from a list of specific groups.
*'''Overrides''': Allows commands or command groups to be allowed or denied to this group.

===Writing/Appending===
*'''Add Flags''': These can be modified at any time. However, users which inherit the group will not have their member permissions updated for performance reasons.
*'''Immunity''': Default and global immunity can be changed at any time. Users inheriting the group will be affected by the changes. Specific immunity can have new groups added (and it will affect member admins).
*'''Overrides''': Overrides can be changed between allow or deny at any time.

===Deleting/Invalidation===
Per-group immunities cannot be removed once added. Groups themselves cannot be removed either, as this would be a potentially expensive operation. Instead, the entire group cache must be rebuilt (and with it, the admin cache). The goal with this design decision is to make group invalidations rare. In order to change a group fully, the entire admin cache must be "refreshed."

==Admin/User Cache==
The user cache stores all information about currently known admins. Users stored can either be ''live'' (as in, their permissions are currently in use by a player), or ''idle'' (cached for future lookup).

Users have the following properties:
*'''Flags''': These are the permission flags the admin inherits by default.
*'''Effective Flags''': These are the permission flags the admin has at runtime. They are a combination of the base flags and the flags inherited from groups.
*'''Groups''': The groups the admin is a member of.
*'''Password''': A generic password that an authentication method might require.
*'''Identities''': One or more mappings between authentication methods and unique identification strings.

===Writing/Appending===
*'''Flags''': Flags can be changed at any time. Changing flags will affect effective flags, even if done after groups are inherited.
*'''Groups''': Groups can be inherited at any time, although a group cannot be inherited twice. Permissions inherited from groups cannot be updated (yet).
*'''Password''': Passwords can be changed at any time.
*'''Identities''': Identities can be added, but not changed or removed.

===Deleting/Invalidation===
Groups cannot be removed from an admin's inherited group list. However, admins can be invalidated. This lets an authentication system, such as SQL, remove individual admins to refresh their privileges. Resources used by an admin object are always reclaimed efficiently.

[[Category:SourceMod Development]]
[[Category:SourceMod Scripting]]