This is a follow-up to my previous feedback via the old tool:

"T200542 – Admin Tools and Options Expansion"
https://feedback.bistudio.com/T200542

Running larger public community servers exposes several limitations in Reforgers administration and RCon tools. Most of them come down to the same problem:

Server administrators often do not receive enough information to properly investigate incidents, automate moderation, or provide useful feedback to players. They have to rely on either receiving a qualified report from a player or by being online on the server and witnessing the situation directly.

1. Custom kick and ban messages

When a player is kicked or banned, they currently receive a generic session error instead of the actual moderation reason.

External tools such as BattleMetrics already allow us to enter information such as:

• Kick or ban reason

• Ban duration

• Appeal information

It would be very helpful if RCon could forward this information to the player when they are removed from the server.

For example:

You have been kicked. Reason: [Enter ban reason given via RCon]

This can result in messages like:

You have ben kicked. Reason: "Intentional Team Killing - Appeal: Discord.exd.gg - Expires: 30/08/2026 17:40"

This would make moderation more transparent and reduce unnecessary support requests and help players understand that their actions had a consequence - and that it wasn't just a bug in the game keeping them from playing.

2. More useful RCon data

RCon currently provides too little information for effective moderation on larger servers.

The following additions would make a significant difference:

Steam64 ID

For Steam players, please expose the Steam64 ID alongside the Reforger Identity ID through RCon.

This would allow external administration systems to reliably associate player identities and avoid duplicate or disconnected moderation records.

This is especially useful for communities operating servers across several games.

In our case, BattleMetrics creates a separate profile for a user for their ReforgerID, even though a profile was already existent for their Steam64 and EOS ID.
Chat logs

Please expose server chat through RCon, including:

• Player identity

• Message

• Chat channel

• Timestamp

A large number of reports involve slurs, harassment or other chat violations. Without logs, administrators have to rely almost entirely on screenshots, recordings or being present when the incident happens.

Kill and teamkill logs

Please expose kills and teamkills through RCon, ideally including:

• Killer and victim

• Player IDs

• Weapon or damage source

• Timestamp

• Whether the kill was a teamkill

Intentional teamkilling is one of the most common issues we deal with.

Having this information available would allow tools such as BattleMetrics to flag repeated teamkills, create reliable moderation records and automate some of the repetitive work currently done manually.

3. Logging for malicious server disruption

Recent incidents have shown that this is not only a moderation issue, but also a server security issue.

We have recently dealt with players using:

• Aimbots

• Task spam

• AI spam

• Other forms of deliberate server disruption

The biggest difficulty is often not recognising that something malicious is happening, but identifying which connected player caused it.

Where technically possible, server logs should therefore provide information about client-triggered actions relevant to security, for example:

• Task creation

• AI spawning

• Entity spawning

• Excessive or abnormal client requests

• Rejected or rate-limited requests

It would also be useful to have server-side rate limits or protections preventing a single client from flooding the server with AI, tasks or similar requests.

4. Stronger enforcement against confirmed cheaters

Community bans alone are limited because they ultimately ban the account or identity we can see.

That is normally sufficient for regular rule violations.

For confirmed cheaters or players deliberately attacking servers, it is not.

We can identify a player, record evidence, permanently ban them and submit a report, only for the same person to return using another account they bought on a dubious website.

Account switching and - historically - systems such as Steam Family Sharing also demonstrate the limitations of purely account-based bans.

I am not suggesting that community administrators should receive raw hardware identifiers or directly issue hardware bans.

Instead, it would be useful to have a clear escalation process where:

1. Community administrators identify and locally ban a suspected cheater.

2. Evidence is submitted to Bohemia Interactive/BattlEye.

3. The case is reviewed.

4. Confirmed cheating or malicious server attacks can result in stronger game-level enforcement.

5. Where appropriate, device/hardware-based enforcement can prevent straightforward ban evasion through another account.

Other multiplayer games already use this separation: community administrators handle immediate server moderation, while the developer or anti-cheat provider can take stronger action against confirmed cheaters when reported via their dedicated Discord for Server Hosts.

Community ban:
"This account cannot join our server."

Anti-cheat / publisher enforcement:
"A confirmed cheater cannot simply return using another account."

5. The overall goal

The goal is not to give community administrators excessive access or invasive player information.

The goal is to give us enough server-side information to properly moderate and protect the servers we operate.

A better RCon interface could provide a complete moderation chain:

Player identity --> Chat/Kill/Server events --> Evidence --> Moderation action --> Ban reason --> Appeal

This would allow communities to build better administration and automation around existing tools such as BattleMetrics instead of relying on administrators manually witnessing every incident - or using Mods.

I know it's a lot of text, so thank you for reading and considering this!

Previous feedback:
T200542 – Admin Tools and Options Expansion
https://feedback.bistudio.com/T200542