Skip to main content
On a character’s first login, the resource inserts a row into vrs_permanent_ids and uses MySQL’s AUTO_INCREMENT to assign the next available number. The value is stored against the character’s identifier and read back on every subsequent login.
No. IDs are tied to a character’s identifier for life. Deleted characters do not free their ID for reuse. The next character always gets MAX(id) + 1.
The server slot ID (source / GetPlayerServerId) is recycled every time a player disconnects and can be reused by the next joiner. It is fine for a single session but useless for reports, clips, or historical logs. A permanent ID stays the same across every reconnect and every server restart.
QBox, QBCore, and ESX, via vrs_bridge. The bridge auto-detects the running framework, so no configuration is required.
No. The vrs_permanent_ids table is created automatically on first start.
Yes. Set Config.StartId in config.lua before the first boot. It only applies when the table is empty. Once IDs are being issued, changing StartId has no effect.
Yes. Config.DisplayPrefix controls the cosmetic prefix used in commands and above-head text. Set it to 'VRS-', '', or anything else you like.
Yes. Grant the vrs.permanentid ACE:
QBox/QBCore admin/god and ESX admin groups pass without needing the ACE.
The recommended path is the statebag:
See Integrations for the full API.
Yes. Copy locales/en.lua to locales/<code>.lua, translate the values (keep %s and %d placeholders in order), then set Config.Locale = '<code>'. Missing keys fall back to English automatically.
Check the server console for the specific message. The most common causes are:
  • vrs_bridge is not started, or is older than v1.2.0.
  • oxmysql is not started or cannot connect.
  • ox_lib is missing.
Ensure them in the correct order in server.cfg:
Last modified on August 12, 2026