RAC-Core setup and user guide.
Customer-facing help for server owners and staff: try the demo, connect a FiveM server, learn the main workflows, and fix common setup issues.
The shortest path to a connected server
Try the demo first if you want to see the panel before installing anything. When you are ready, follow the install steps in order.
Help for real product usage
The guide avoids internal release notes and focuses on what customers need to install, operate, and troubleshoot RAC-Core.
- Demo and sample-data behavior
- FiveM resource install steps
- Framework-specific feature notes
- Support, moderation, monitor, tablet, and resource workflows
A practical guide for server owners and staff.
RAC-Core gives your team a web panel and in-game tablet for support, moderation, live operations, analytics, and server health.
What RAC-Core ships
The product is centered on staff workflows that happen during live server operations.
Before you install
A few quick checks keep the first connection smooth.
- Access to server.cfg and your FiveM resources folder
- A RAC-Core server created in the panel
- Your framework resource loaded before RAC-Core
- screencapture for live video and screenshots, or screenshot-basic for screenshots only; do not run both
- ESX status support if you want hunger and thirst writes
Try the panel with safe sample data.
The demo is intended to feel like the live product. It uses session-scoped dummy data, so you can create tickets, reply, freeze sample players, restart sample resources, inspect analytics, and reset without touching a real server.
Close to the real panel
Overview, support, players, live monitor, resources, analytics, and audit views use the same workspace language as the full product.
Session state only
Demo actions change only your browser session. Reset returns the sample server, tickets, players, resources, and audit stream to their original state.
Self-hosted demo
If you host RAC-Core yourself, the demo requires DEMO_MODE=true and a reachable backend API base. The hosted demo should work without a real server.
Four steps to connect FiveM.
Start with the default install. Tune framework settings after the panel heartbeat is working.
Step 1 - Download and place the resource
Put the latest RAC-Core resource in your FiveM resources folder and keep the folder name as rac-core.
resources/
rac-core/
fxmanifest.lua
client/
server/
ui/Step 2 - Start required dependencies first
Start only the framework your server actually uses, then its medical resource, then RAC-Core. The example below is QBOX with ARS; replace those lines for your server. For live video use screencapture, which also supplies screenshot-basic compatibility. Screenshots alone can use screenshot-basic.
# QBOX + ARS example; use your existing dependency order
ensure oxmysql
ensure ox_lib
ensure qbx_core
ensure ars_ambulancejob
# Optional: ensure screencapture
# Add the credentials from step 3 before this line
ensure rac-coreStep 3 - Add your panel credentials
Create or open your server in the RAC-Core panel, then copy the server ID and server token into server.cfg before ensure rac-core. Use set, never the replicated setr or public sets variants.
set rac_server_id "YOUR_SERVER_ID"
set rac_server_token "YOUR_SERVER_TOKEN"
# Self-hosted only; hosted users keep the default:
# set rac_api_base "https://your-domain.com/api/v1"Step 4 - Restart and verify
Restart the resource, then confirm the startup banner, version check, and panel heartbeat.
restart rac-core
# or
ensure rac-coreThe settings most server owners need.
Credentials belong in server.cfg as convars. Framework behavior lives in rac-core/server/config.lua.
# server.cfg - required credentials
set rac_server_id "YOUR_SERVER_ID"
set rac_server_token "YOUR_SERVER_TOKEN"
# Self-hosted only:
# set rac_api_base "https://your-domain.com/api/v1"
# The Lua settings below belong in a separate file:
# rac-core/server/config.lua - common options
Config.Framework = "AUTO" -- AUTO, STANDALONE, ESX, QBCORE, QBOX
Config.EnforceModeration = true
Config.Ui.AllowPlayersSupportAccess = true
Config.VersionCheck.Channel = "stable"Notes that matter
- Do not paste server tokens into screenshots, public tickets, or public repositories.
- Hosted resource packages are built for the hosted RAC-Core API. Self-hosted packages must be built or configured for your public domain.
- QBCore and QBOX use metadata-aware character handling.
- ESX surname handling can be adapted to your character package.
What each framework supports.
This table shows which features are framework-backed and which are part of the general RAC-Core operations layer.
| Framework | Supported data | Notes |
|---|---|---|
| Standalone | Moderation, support workflows, analytics, tablet, audit, device link, and queued actions that do not require framework economy data. | Use this when you want RAC-Core as an operations layer without ESX/QBCore/QBOX economy writes. |
| ESX | Job, grade, cash, bank, health, armour, hunger, thirst, offline queue, support, and analytics. | Hunger and thirst need esx_status or compatible handlers. Surname writes can be adapted in Config.FrameworkAdapters.ESX. |
| QBCore | Job, grade-only updates, cash, bank, charinfo last name, health, armour, hunger, thirst, and offline queue. | Uses qb-core exports and metadata-aware handling for character and status writes. |
| QBOX | Job, grade-only updates, cash, bank, charinfo last name, health, armour, hunger, thirst, and offline queue. | Detected through qbx_core and uses the qbx export path directly. |
Standalone
Moderation, support workflows, analytics, tablet, audit, device link, and queued actions that do not require framework economy data.
Use this when you want RAC-Core as an operations layer without ESX/QBCore/QBOX economy writes.
ESX
Job, grade, cash, bank, health, armour, hunger, thirst, offline queue, support, and analytics.
Hunger and thirst need esx_status or compatible handlers. Surname writes can be adapted in Config.FrameworkAdapters.ESX.
QBCore
Job, grade-only updates, cash, bank, charinfo last name, health, armour, hunger, thirst, and offline queue.
Uses qb-core exports and metadata-aware handling for character and status writes.
QBOX
Job, grade-only updates, cash, bank, charinfo last name, health, armour, hunger, thirst, and offline queue.
Detected through qbx_core and uses the qbx export path directly.
Medical and revive setup
Revive must clear your medical script’s death state, not just restore health. RAC detects the running medical resource independently of the framework: a QBOX server can use ARS. Start your medical resource before RAC.
Automatic selection
- Default order: ars_ambulancejob → qbx_medical → qb-ambulancejob → esx_ambulancejob. Only one revive handler runs.
- No supported medical resource detected: native resurrection at the current location. Unknown medical scripts need a custom integration to clear their death screen and internal state.
- Multiple medical scripts or a renamed resource: pin the provider or configure a custom client handler. An explicit provider that is stopped or unknown logs an error.
-- rac-core/client/config.lua (optional override)
ClientConfig.Revive = {
Provider = 'ars_ambulancejob',
}
-- Other values: auto, qbx_medical, qb-ambulancejob,
-- esx_ambulancejob, standalone, custom
-- For an unsupported resource, replace the above with:
-- ClientConfig.Revive = {
-- Provider = 'custom',
-- Handler = function()
-- TriggerEvent('your_medical:revive') -- use its documented client API
-- end,
-- }The custom handler runs on the target player’s client. Use your medical resource’s documented event or export; server-only integrations need an authorized server adapter. Test dead and last-stand players: controls should return, the death screen should close, and the player should stay revived after reconnecting. A dispatched command is not confirmation of medical completion.
Set up staff and daily workflows
Staff access and account linking
- Add staff in the server’s Staff settings and review role presets and per-user overrides. Paid access and staff permissions are separate requirements.
- Use /raclink in game and follow the generated account-link instructions. /racdevice starts browser device login. Linking does not grant a staff role.
- Grant characters.edit for character corrections and economy.edit for cash or bank changes. Revive and similar player actions use admin.actions. Honor any configured MFA requirements.
Character corrections and approvals
- In Players, open a profile and use the Characters tab. Review before/after values and enter a reason before submitting. Refresh and review again if a stale-value conflict is reported.
- Offline corrections wait for the exact framework character to load. Inspect command results; a queue entry does not change the observed snapshot immediately.
- Premium owners can set an economy approval threshold. A different staff member with character and economy edit permissions must review a qualifying correction. Reviews expire after seven days.
- Cancel and resubmit a character correction to change it; raw queue editing and replay cannot bypass the review flow.
Player help and reports
- Players use /ractablet, /help or /report. With player support access enabled, they do not need to link an account to request help.
- Choose Help Request or Player Report, select a category and target where appropriate, then write the message. Screenshots are optional when capture is enabled.
- Wait for the confirmed submission. Retry a failed request without changing it to reuse its receipt ID. Drafts survive panel refreshes and type switches, but not resource restarts.
Staff support (Pro or Premium)
- Use the Support workspace for assignment, replies, status changes, private case notes and linked player actions. Private notes are not replies to the player.
- The owner can set a first-response target of 1–1,440 minutes. A staff reply stops the clock; player follow-ups do not reset it.
- Premium automatic escalation records an audit event once per overdue case and uses configured server webhooks. Configure webhook delivery before relying on external alerts.
Populate the economy transaction ledger
The Economy workspace provides reviews and recorded transactions. Balance sampling is not a complete transaction history. To record attributable transactions, have your developer call this server export after each successful economy operation:
exports['rac-core']:RecordEconomyTransaction(playerSource, {
id = paymentId, -- stable string ID from your payment system
account = 'bank', -- cash or bank
amount = 500, -- signed, non-zero whole-number change
reason = 'Completed delivery job'
})The calling resource supplies the source name. Reuse the ID for retries of the same transaction. There is no automatic capture of every framework payment or historical backfill. The export returns dispatch status and logs HTTP failures; integrations needing complete accounting must provide a durable retry queue. Ledger access requires Pro or Premium and economy.view.
Screenshots and live video
- Screenshots only: start screenshot-basic and enable Config.Ui.EnableScreenshotCapture. Live video requires the released screencapture resource instead; it supplies screenshot-basic compatibility. Do not run both providers.
- For live video, start screencapture before rac-core, use Premium and the matching monitor permissions, then explicitly start a viewer. Live service availability, session limits, concurrency and bandwidth budgets also apply.
- Keep Config.Ui.EnableMonitorScreenshotFeed = false. The old repeating screenshot feed is disabled by default and is not the live video setup.
- Hosted customers do not need provider secrets in the resource. Self-hosted operators must configure the signed live gateway and backend settings using the repository’s docs/MONITOR_LIVE_STREAMING.md before enabling viewers.
Update and verify your installation
- Back up your configuration, download a matching release and replace the full resource, including fxmanifest.lua and client/revive.lua. Merge new configuration options into your saved files; do not overwrite private credentials.
- Restart rac-core after its dependencies. If a player still sees old behavior, reconnect and check the installed resource version and client/server console errors.
- Verify a heartbeat and player join, a support submission and staff reply, a permitted correction with a result, an offline correction when that character logs in, and a medical revive. Test as a restricted staff member as well as the owner.
- Self-hosted operators: back up the database and upgrade backend, web and resource together. Backend startup applies pending migrations; workflow features require migrations 018–023. Confirm migration success before opening access to staff.
Use the product during live staff work.
Most teams spend their time in support, player profiles, live operations, moderation, and the audit trail.
Support workflows (Pro+)
Help and report threads, assignment, replies, status changes, and screenshots in one place.
Live monitor (Premium)
Select a player and explicitly start a low-quality live video session. Premium, monitor permissions, screencapture and an enabled RAC live service are required; adding a tile does not start a stream.
Security and RBAC
Staff roles, per-user permissions, VPN/proxy visibility, join controls, and sticky risk tracking.
World controls (Premium)
Sensitive world actions such as clearing entities require Premium and the matching permission.
Offline queue
Offline character corrections wait for the exact framework character to load. Review before/after values, provide a reason, then inspect command results; queued does not mean applied.
Audit trail
Staff actions and important system events are recorded for later review.
A focused surface for staff already in session.
The tablet is a compact version of the daily workflow, tuned for quick in-game actions rather than long desktop review.
In-game commands
`/ractablet` - Open or close the RAC-Core tablet on the regular help and report page.
`/help` - Open the same regular tablet page for help and reports.
`/report` - Open the same regular tablet page for help and reports.
Actor-bound actions
goto, bring, and spectate are intentionally in-game because they need a staff actor in the server session.
Give staff the access they need, not everything.
Role presets and per-user overrides let owners separate read access, support access, resource controls, moderation, and high-risk actions.
Security controls
VPN/proxy visibility, allowlists, banned identifiers, join controls, chat flood protection, and weighted risk scoring.
RBAC model
Role templates work as presets, then user overrides let server owners tune access for individual staff members.
Understand server health and player behavior.
RAC-Core turns player density, crash locations, disconnect reasons, entity trends, and per-player activity into operational signals.
Player activity
Player count trends, live density, and per-player activity timelines.
Crash and disconnect views
Crash hotspots, disconnect breakdowns, and visual density overlays.
Economy and jobs
Economy flow sampling and job movement trends over time.
Control resources without guessing.
Resource management is a Premium workflow. Listing and control are separately permissioned so owners can allow visibility without allowing restarts or stops.
Control
Start, stop, restart, and refresh resources from the panel when your role allows it.
Monitoring
Track state, average and max ms, restart counts, and resource event logs.
Policy
Critical resources can be protected so staff cannot stop or restart sensitive services accidentally.
Confirm the basics before handing it to staff.
Most first-run problems come from setup, dependency, or permission mismatches.
The FiveM console prints the RAC-Core startup banner and version check.
The panel shows the server as online and the heartbeat card updates.
At least one player join appears in the panel.
Free monitors up to 64 online players. Pro and Premium support unlimited player monitoring.
Support and help/report pages are available on Pro or Premium.
Premium unlocks live monitor, resource management, custom commands, live map and world controls; each still needs the matching staff permission and dependencies.
Test one character correction and inspect its result; test revive on a dead player and confirm the medical UI closes.
What to check first when something does not work.
Start with these checks before changing framework settings or reinstalling the resource.
Connection and framework issues
- No players in the panel: confirm the API base, server ID, server token, and startup banner.
- Server stays offline: confirm the resource is started and the backend URL in the package matches your deployment.
- Framework values missing: keep Config.Framework = "AUTO" unless you need to force detection.
Screenshots, queue, and web issues
- No screenshots: start screenshot-basic or the screencapture compatibility provider and enable Config.Ui.EnableScreenshotCapture. Do not run both providers.
- No live video: screenshot-basic alone is insufficient. Check screencapture, Premium and monitor permissions, and whether the RAC live service is enabled. A budget or concurrency limit may also block a start.
- Revive raises health but leaves the death screen: configure the actual medical resource under ClientConfig.Revive; see Medical and revive above.
- Queued actions remain pending: inspect the panel heartbeat and server console for poll or ack failures.
- ESX hunger or thirst missing: verify esx_status or compatible handlers are installed.
- Demo does not load: self-hosted installs need DEMO_MODE=true and a web API base that reaches the backend.