Kick and ban

/sfkick removes a player and blocks their address, for 10 minutes by default. /sfban removes them and writes the address to a file.

Neither command works without +exec storyforce_server.cfg. The compiled permission masks grant both to nobody, including leadership.

What it does

The difference that matters is where the block is kept.

A kick lives in memory. It expires on its own after sf_kickbantime minutes, and a server restart clears every kick on the spot. The person is told they were kicked, not banned.

A ban is written to bannedips.cfg in your server's writable folder. Every ban in that file is reapplied when the server process starts. Bans survive restarts, and container rebuilds too when the writable folder is on persistent storage. That file is also the record of who banned whom and why.

Both record the player's IP address and their GUID, the per-install id the game sends when connecting. A returning player is refused when either one matches, so changing address alone is not enough to get back in.

/sfkick sits at clerical admin in the shipped config and /sfban at leadership.

Finding the client number

Both commands take a client number and nothing else. Names and character ids are refused, so a name with colour codes or spaces can never be mistyped into a ban.

Run /whois to list who is connected with their slot numbers. Getting it wrong gives you a refusal rather than the wrong person:

Kicking someone

That line goes to everyone on the server. The minutes in brackets come from sf_kickbantime, and the kicked player sees the same figure and your reason on their disconnect screen. Set sf_kickbantime to 0 and the message drops the brackets, because there is no reconnect block at all.

Leaving the reason off gives the player Kicked by an admin, which tells them nothing. Write one.

Banning someone

The first line goes to you alone. The second goes to everyone on the server.

With the record list already full, the address is still blocked but nothing is written down, and the confirmation says which half worked:

Somebody who has already disconnected can still be banned. /sfban recent lists the most recent departures with a number against each, and /sfban recent <#> [reason] bans one of them:

Running /sfban with no arguments prints the 4 subcommands.

Reading and undoing bans

The number in the first column is what you pass to remove it, and a full address works too:

unban is an accepted alias for remove. Removing a ban also clears any kick block on the same address, so one command undoes both.

Settings

Things to note

• Kicks do not survive a restart. The block is held in memory only, so a restarted server lets the person straight back in.
• The ban file holds 512 entries. Past that, the player is still dropped and blocked until the next restart, but the record is lost, so the ban does not survive a restart and never expires. The confirmation says so, and the server console adds sf_bans: ban list full.
• Bots and local connections are never blocked. Banning one gives you No bannable IP for that client - kicking only.
• You cannot kick or ban yourself, in either command.
• Addresses are shared. 2 players behind the same connection share one block, so banning one can remove both.
• Addresses change. A returning player on a new address is still caught while their GUID matches. With a new address and a fresh GUID, nothing is left to match and they get back in.
• bannedips.cfg is read once per process. Editing it while the server runs changes nothing until the next restart, and the next in-game ban or unban overwrites your edit.
• The file is plain text, one ban per line, so it is readable and greppable. It holds the address, the name at ban time, the date, who banned them, the reason and the GUID. There is also an expiry column no command currently sets.

Next

• The audit trail: the account-change log kept alongside the ban file
• Managing accounts: quieter measures than removing someone