Project Zomboid Server Chat Settings: Test Visibility

Project Zomboid server chat settings are documented as option fields, but their names do not tell you exactly which players receive each message. Use the current server build, the settings source it actually reads, and two ordinary player accounts to test the visibility your community needs. This guide shows what the official reference confirms, how to record a controlled test, and which assumptions to avoid. It does not provide a universal channel-permission matrix or promise that any stream is private.

Separate documented fields from tested behavior#

The official ServerOptions API lists chat-related options and their types. That is useful for identifying configuration controls, but it is not a guide to message routing. A field name does not establish its default, accepted values, effect on other streams, or who can read a message.

The official 42.21 Stable release notes establish the current Stable baseline as of this review, but do not describe chat recipients or privacy behavior. Older descriptions of the chat interface can help explain its history; they cannot confirm a current menu or visibility rule. Keep those questions in the “test on this server” column until you have observed the exact build you run.

Identify the active build and settings source#

Before reading a configuration file, record the server’s displayed or logged build and branch. Project Zomboid can have multiple profiles or settings copies, and the file named servertest.ini is only the active source when the running server actually uses that profile. Do not assume the example filename or path below belongs to your installation.

Use the server manager, startup definition, or provider instructions that already control your deployment to locate its active options source. If you need a general method for identifying the profile and validating a harmless edit, follow the server INI edit and verification guide. Do not change startup arguments just to make the filename match this example.

Write down the build, branch, profile name, source path or panel field, and the date of your test. If a panel generates the file, note which panel field owns it and check the saved value through that supported interface. A file that looks right but is not read by the running process tells you nothing about live chat. If you cannot identify the active source, pause and ask the server owner or provider before editing multiple copies.

Read chat controls without guessing their effects#

The API gives you the field names and types; a generated file can show one configuration sample. In a read-only inspection of a 42.21.0 server profile, this sample was present:

GlobalChat=true
ChatStreams=s,r,a,w,y,sh,f,all
DisplayUserName=true

Treat those lines as one observed profile, not universal defaults or a recommendation to copy. The official API names its properties in lower camel case, while an INI file can use capitalization such as the sample above. Confirm current values using the active server’s own source. Do not infer that f, w, a, or any other token maps to a particular group, guarantees delivery, or limits access based on the string alone.

The sample also does not establish how showFirstAndLastName interacts with DisplayUserName, what a particular player sees, or whether every option is exposed by your provider. Avoid pasting a vendor’s path or values into a different panel. Record a field only after you have confirmed that it belongs to your build and active profile; leave unsupported fields untouched.

Define a two-account visibility test#

Use two ordinary accounts that represent the real distinction you want to check, such as members who already belong to different groups. Avoid administrator accounts for the first pass: elevated access could produce a view ordinary players do not have. If you cannot safely create two test accounts, arrange a quiet test with two trusted members and tell them not to send real personal information.

Before opening chat, make a small matrix. Do not label a stream “private” in advance; write down the expectation as a question, then fill in the observed result:

Keep the markers disposable, such as CHAT-CHECK-01, and remove them if your server offers a documented way to do so. Do not use a real private conversation as a test. If the interface does not clearly label the selected stream, record that limitation rather than assigning a meaning from memory or a third-party list.

Change one supported option and observe the result#

Start with a baseline before changing anything. Capture the current values without sharing passwords, tokens, or player identifiers. Change one documented option through the source that owns it, using the current procedure for your setup. Do not edit several chat settings together: if a result changes, you would not know which change caused it.

After applying the change using the documented method for your server, reconnect both ordinary accounts if that method requires it. Send a new harmless marker and record the sender, selected stream as shown by the current client, each recipient’s observation, and any error. Repeat in the reverse direction. A saved file proves only that the source changed; it does not prove what connected players can read.

Restore the original value after the test unless the operator has approved the new behavior. Then run the same observation again to check that the outcome returns to its baseline. If the setting is ignored, overwritten, or produces a different view than expected, stop rather than adding more guessed tokens. Confirm the active profile and consult current official documentation for the exact build before trying another change.

Check displayed identity separately from channel access#

Name presentation and message visibility are different questions. The API lists displayUserName and showFirstAndLastName separately from globalChat and chatStreams; that separation does not establish what each name option displays or how the settings interact. Test the identity view with the same two ordinary accounts, but record it in a separate column from message recipients.

For each test, note what the sender sees, what the other account sees, and whether the display changes after the documented reconnect or apply step. Do not include account names in a public report; use labels like Account A and Account B. If the result changes only for one account, repeat with the same roles and build before concluding that the setting caused it.

A display-name change is not evidence that a player has gained or lost access to a stream. Likewise, seeing a message from a named player does not prove that every member sees the same identity. Keep your note limited to the two views you actually observed, including build, branch, settings source, and test date.

Record limits and route adjacent work separately#

Write down the actual observations, the original and tested values, who performed the check, and anything you could not verify. Describe the result as “Account B saw marker 01 in this test on build X,” not “this channel is private.” One pair of accounts cannot establish every role, mod, or future build’s behavior. Retest after a build or configuration change before relying on the previous result.

Native chat is also separate from external services. If messages leave the game for Discord, review the distinct Project Zomboid Discord integration and access checks; a native stream setting does not explain a bot’s permissions. Map markers and explored areas are another separate control; use this Project Zomboid multiplayer map-sharing settings test to check the exact audience. Faction membership has its own rules, so do not infer it from a chat test.

The useful outcome is a short, dated record of what your own server showed, plus a clear list of unknowns. If you cannot demonstrate a boundary with ordinary accounts, tell members not to use that stream for confidential information and keep investigating with a disposable test setup.

Keep a copy of the original values beside your test notes so the owner can restore them without relying on memory. Share the result with members as a scoped observation, including the build and date, and repeat it after a relevant update.