How to Ban Players From a Soulmask Server (Admin Commands and Persistence)

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Prefer not to run the server on your own PC? Godlike.Host offers hosted Soulmask servers with free DDoS protection and up to three free backups a day.

To ban a player from a Soulmask dedicated server, authenticate as an administrator, enable permission list 1, then add the player’s SteamID64: gm key YOURPASSWORD, gm EnableServerPermissionList 1 1, and gm AddServerPermissionList 1 <SteamID64>. The add command is reported to kick and ban the player when it is accepted. Remove a ban with gm RemoveServerPermissionList 1 <SteamID64>.

What you need before issuing a ban

Soulmask server moderation depends on the server’s administrator console and permission-list commands. There is no documented in-game way to create an administrator password after the server has started. The dedicated server therefore has to be launched with an administrator password in the -adminpsw launch argument.

#	Preview	Product	Price
1		THE SOUL GAME	$2.99	Buy on Amazon

For example, the launch configuration must contain an argument in this form:

-adminpsw=YOURPASSWORD

Use the exact password configured by the host. If the argument was omitted, changing a setting inside the running game will not add administrator access; stop the server, add the launch argument through the host’s startup settings, and start it again.

#1 Best Overall

THE SOUL GAME

$2.99

Buy on Amazon

Administrator authentication is session-based. Run gm key again whenever you rejoin or reconnect to the server, even if you authenticated during an earlier session. Keep the password private: anyone who can use it may be able to run administrative commands.

How Soulmask’s permission list ban works

The ban procedure uses a server permission list rather than a player name. In the commonly documented command sequence, list ID 1 is enabled, and a player’s SteamID64 is added to that list. A SteamID64 is the long numeric identifier associated with a Steam account; it is not the player’s display name, character name, or a short SteamID.

Enabling the list and adding an entry are separate operations. If the list is disabled, adding an identifier may not enforce the restriction. The enable command’s second argument is a switch: 1 turns the list on and 0 turns it off.

Community command references agree on the following syntax, but the official CampFire Studio reference should be treated as the final authority for the server build you operate:

Step-by-step: ban a player from the server

1. Obtain the player’s SteamID64

Before opening the console, identify the account that should be blocked. A profile URL or username can be converted to a SteamID64 with a third-party lookup service such as steamid.io, which is named in community guides. That lookup was not independently verified here, so check the result carefully before applying a permanent moderation action.

• Prefer the player’s Steam profile URL over a display name when possible; names can change or be duplicated.
• Copy the full SteamID64 as one uninterrupted number.
• Check that you did not copy a profile name, vanity URL, SteamID32, or another identifier format.
• Record the identifier with the reason and date of the action so another administrator can audit it later.

If you cannot confidently associate the number with the offending account, pause the ban rather than risk blocking the wrong player. A SteamID-based ban is only as accurate as the identifier supplied to the command.

2. Open the server console and authenticate

Join the server with the account that has administrative responsibility and open the console with the tilde (~) key. Enter:

gm key YOURPASSWORD

Replace YOURPASSWORD with the value supplied in the server’s -adminpsw launch argument. Authentication is not permanent; repeat this step after reconnecting, restarting your client, or otherwise beginning a new session.

If the command is rejected, first verify that the server was actually started with -adminpsw. A password typed into the console cannot retroactively create administrator access when the launch argument was absent.

3. Enable permission list 1

With administrator access active, submit:

gm EnableServerPermissionList 1 1

Here, the first 1 identifies the permission list and the second 1 enables it. Do not replace the second value with a player ID. The list has to be enabled before its entries can enforce the ban.

4. Add the SteamID64 to the list

Submit the ban command, replacing the placeholder:

gm AddServerPermissionList 1 <SteamID64>

For example, the command structure is the same whether the identifier is copied from a profile URL or another lookup result; only the numeric value changes. Community guides report that submitting this command kicks the player and bans the account. Watch the console response and the player roster rather than assuming that a mistyped number succeeded.

Do not include angle brackets in the real command. They indicate a value that you must replace. Avoid adding a display name, quotation marks, commas, or explanatory text to the line.

5. Confirm the result

After submitting the add command, check that the intended player was removed and cannot reconnect. If the player remains present, authenticate again and repeat the list-enable command before investigating syntax or persistence. Also compare the SteamID64 in your record with the value you actually entered.

A successful kick is not, by itself, proof that the long-term ban was stored. The list’s persistence depends on server startup configuration, described below, so verify both immediate enforcement and behavior after a controlled restart.

How to unban a player

To remove an entry from the commonly documented list 1, authenticate in the console and submit:

gm RemoveServerPermissionList 1 <SteamID64>

Use the same SteamID64 that was banned. Removing a display name or a different account identifier will not remove the original entry. If the player still cannot connect, confirm that the list is enabled as intended, check whether the server uses a different list ID, and restart only after recording the current configuration.

GameServerKings is cited as checking its command list against CampFire’s source and shows RemoveServerPermissionList 4 [steamID] for an unmute operation. That example demonstrates that list IDs are not necessarily universal across every permission-list function or server configuration. The ban guides summarized here use list ID 1; if your server documentation or command response identifies another list, follow that documented ID rather than blindly substituting 1.

Making a ban survive a server restart

The permission-list enable command is reported to lose its effect when the server restarts. To preserve permission-list behavior, community guides point to the -serverpm launch argument. One guide gives the form -serverpm=2, but that value has not been confirmed against CampFire Studio’s documentation.

Because the correct value is unresolved, do not treat -serverpm=2 as a guaranteed universal setting. Check the current CampFire private-server documentation or the instructions supplied by your hosting provider for the build you run. After changing startup arguments:

1. Stop the server cleanly.
2. Add the documented -serverpm setting in the host’s launch-argument field or startup script.
3. Start the server and authenticate with gm key YOURPASSWORD.
4. Run gm EnableServerPermissionList 1 1 if the server requires the list to be enabled in the current session.
5. Test with a controlled account or have the affected player attempt a reconnect, while keeping the ban record available.

If a restart causes a previously blocked account to return, the ban entry may still exist while enforcement is disabled, or the persistence argument may be missing or incorrect. Do not infer the proper -serverpm value from an unrelated host’s guide.

Console syntax: what is established and what is not

The gm-prefixed commands above are the syntax repeated by the permission-list guides summarized for this procedure. Some guides omit the gm prefix and suggest trying both forms if one is rejected. Treat that as a compatibility troubleshooting step, not as proof that both forms are supported on every build.

Other 2026 pages list slash-style or name-based examples such as /kick [player_name], /ban [player_id], kick [PlayerName], or ban [PlayerName]. Those examples do not match the permission-list syntax and were not confirmed. Do not publish or rely on them as working Soulmask commands without validating them against the official documentation for your server version.

Command behavior can vary with server build, host wrapper, or permission-list configuration. A command that produces no visible response is not necessarily successful. Record the exact line entered and the server’s response, then verify the player’s connection state and the list configuration.

Troubleshooting failed bans

The console says the command is unknown

• Confirm that you opened the actual server console, not a normal chat box.
• Run gm key YOURPASSWORD again; admin status does not persist between sessions.
• Check that the server was launched with -adminpsw.
• Try the documented gm form first. If a community guide for your host explicitly supports an unprefixed form, test that form separately.
• Check the current CampFire documentation for your server build before switching to slash or name-based commands.

The player was kicked but can reconnect

• Verify the SteamID64 character by character.
• Run gm EnableServerPermissionList 1 1 and then add the identifier again.
• Check whether your host uses a different permission-list ID.
• Inspect startup settings for the documented -serverpm argument; the persistence value is not established by the community summaries.
• Have the player reconnect after the command is accepted, rather than testing only whether the initial kick occurred.

The wrong account appears to be banned

Stop and remove the mistaken entry with the same list ID and SteamID64, then verify the intended account independently before adding it. Display names and character names are not reliable substitutes for SteamID64 values. Keep a written mapping of identifier, profile, reason, and administrator so the correction is auditable.

The character still appears after removal

An older community guide reported a bug in which a banned player’s character could remain visible in-game after removal. That report is roughly 700 days old, so it may no longer apply to current builds. If you encounter it, distinguish a visual leftover from an active connection: check whether the account can reconnect, restart the server during a maintenance window, and consult current CampFire documentation or host support before declaring the ban ineffective.

SteamID64 bans and alternate accounts

A SteamID64 ban targets one Steam account. Community guidance warns that an alternate account can evade it, so a successful identifier ban is not an absolute guarantee that the same person will never return. If evasion is a concern, document the behavior, review new accounts carefully, and apply your server’s published rules consistently. Do not claim that a SteamID64 ban blocks every account controlled by the same person.

Avoid posting full identifiers in public moderation channels unless your server policy permits it. Store the value where the administrator team can retrieve it without exposing unnecessary personal or account information.

Self-hosted and rented servers

Self-hosted server

On a self-hosted installation, you control the startup command or script. Add -adminpsw before starting the server, and place the documented -serverpm option in the same startup configuration when persistence is required. Keep a copy of the exact launch line so a restart does not silently drop either argument.

Rented game server

Rented hosts commonly expose launch arguments in a control panel rather than a shell. Look for fields labeled startup parameters, additional arguments, command line, or server settings. The host may also publish its own Soulmask administration guide. Enter only the arguments supported by that host, restart the service after saving, and then perform the console authentication and permission-list steps.

If the panel hides the launch command or strips an argument, ask the host which CampFire-supported setting enables permission-list persistence. Do not assume that a parameter accepted by one provider is accepted by another.

Recommended moderation record

For each action, keep a concise record outside the game console:

• UTC date and time of the action.
• Administrator who authenticated and issued the command.
• Player name as displayed at the time.
• Complete SteamID64 and the profile used to verify it.
• Rule or incident that prompted the action.
• Exact command sequence, including the permission-list ID.
• Whether the player was kicked immediately and whether a reconnect test was performed.
• Startup settings relevant to persistence, without publishing the administrator password.

This record makes it possible to reverse an accidental ban, identify an account that changes its display name, and explain why a restart changed enforcement behavior.

Ban and unban checklist

1. Confirm that the server launch configuration contains -adminpsw.
2. Join with the responsible administrator account and open the tilde console.
3. Run gm key YOURPASSWORD for the current session.
4. Verify the player’s SteamID64, not merely a name.
5. Enable list 1 with gm EnableServerPermissionList 1 1.
6. Add the account with gm AddServerPermissionList 1 <SteamID64>.
7. Confirm the kick and test whether the account can reconnect.
8. Check the documented -serverpm setting if the ban must survive restarts; do not assume the unverified value.
9. Record the action and keep the identifier for a future unban.

To reverse the action, authenticate again, use gm RemoveServerPermissionList 1 <SteamID64> unless your server documentation specifies another list ID, and verify the result with a reconnect test.

What to verify against official documentation

Community guides provide a consistent starting sequence, but several details remain unresolved: whether CampFire’s current documentation uses exactly the same gm syntax, what value -serverpm requires, whether list IDs differ by operation, and whether any current build supports slash or name-based commands. Verify those points against CampFire Studio’s private-server documentation or your host’s current instructions before changing production settings. This is especially important after a game update or host migration.

Quick Recap

Bestseller No. 1

THE SOUL GAME

$2.99

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.