Choose the behavior before choosing a chat theme
The color-code guide distinguishes native text tags from CSS colors and indexed game palettes, with a local hex-to-RGB converter.
List the channels your server needs and who should receive each message. A global announcement, nearby roleplay text and a staff-only message have different routing requirements. Write those rules before comparing screenshots or installing a replacement interface.
Ask whether a candidate supports the events and framework integrations used by your existing resources. A themed chat can look correct while losing messages from another package. Keep the resource revision, game build and integration list beside your evaluation notes. This guide does not establish GTA VI compatibility.
Send a local message with the documented event
Cfx documents chat:addMessage with a message object containing fields such as color, multiline and args. Its client example only displays to the executing client. The adapted snippet below is a small client-side display check, not a global broadcast, moderation system or player command.
Place the call in an existing client script loaded by your test resource, with the compatible chat resource already available. It runs when that script executes. Use a staging setup and retain the first relevant client error. Magnate has checked the example against the documented API shape, but has not run it inside FiveM.
TriggerEvent('chat:addMessage', {
color = { 250, 63, 76 },
multiline = true,
args = { 'Garage help', 'Check the vehicle guide before changing a model.' }
}) A command suggestion is not a command implementation
Cfx documents chat:addSuggestion with a command name, description and parameter information. Its command name starts with a slash. This event supplies a hint in chat; the command handler and any server-side authorization still need their own implementation.
When a hint appears but nothing happens, inspect whether the intended command exists and where it is registered. When a command works but the hint is absent, inspect suggestion registration separately. Avoid changing permissions to repair a cosmetic description.
For commands affecting money, inventory, jobs or other authoritative state, enforce the actual action on the server with the appropriate checks. A hidden suggestion or missing interface button does not establish that unauthorized actions are rejected.
Use two players to verify message routing
The following is a proposed acceptance matrix. Define the intended result for your selected package and test with separate characters. One person seeing a message only proves that person’s display path.
| Scenario | What to verify |
|---|---|
| Local display check | Only the executing client sees the test message |
| Intended global channel | Both connected test players receive one message |
| Nearby roleplay channel | Inside and outside recipients match the configured range policy |
| Restricted channel | Authorized recipient sees it; unrelated character does not |
| Command hint | Hint matches the command name and actual parameters |
| Reconnect | Expected hints and message behavior return without duplicates |
| Long or multiline text | Content remains readable without covering necessary controls |
Diagnose missing and duplicate messages
For missing output, separate event generation from rendering. First record which resource creates the message, which event or export it uses and which player should receive it. Then inspect the chat resource and its first relevant error. A blank interface and an incorrectly selected recipient are different failures.
For duplicate output, reproduce one event with one originating resource before changing notification timing. Check whether an old chat resource or an integration bridge is also active. Compare a clean staging setup with the customized version and reintroduce changes in small groups.
For roleplay channels, test location and role conditions explicitly. Do not assume the color or prefix determines who can see the message. Retain the expected recipients and actual recipients in your test record so the routing issue can be reproduced.
Keep installation and rollback reviewable
Preserve the working resource and configuration before replacing a chat interface. Inventory the scripts that send messages or add suggestions, and test their important paths after the change. A successful manual test message does not prove every integration still works.
Record the exact revision, a minimal reproduction and redacted client or server errors when requesting support. Use our scripts guide for the broader resource-installation workflow. These proposed checks do not claim compatibility or runtime performance for a particular commercial chat package.
Questions, answered.
Does chat:addMessage broadcast to everyone?
A local TriggerEvent call in a client script displays to that client. Do not treat it as proof of server-wide delivery.
Does chat:addSuggestion create a working command?
It adds a command hint. The handler and any required authorization must be implemented separately.
Why does my chat show each message twice?
Reproduce with a single originating integration on staging, then check for duplicate chat resources or bridges before changing display timing.
Sources & editorial notes
Source review: November 7, 2026. Platform announcements can change. This guide separates published facts from Magnate’s original analysis and preparation advice.
- Cfx — chat:addMessage Client message object and local event example.
- Cfx — chat:addSuggestion Command suggestion arguments; reviewed November 7, 2026.
- Cfx — Secure your events Server-side validation of client-triggered actions.
Published by an independent editorial brand. Read our editorial standards.