🌉Resource Bridge

Installation Guide for the `xmmx_bridge` resource!

The resource bridge is a free, powerful and extensible bridge utility built for FiveM developers and server owners. It serves as a central integration hub that abstracts and standardizes key gameplay systems such as framework interaction, inventory usage, target zone handling, progress bars, notifications, and draw text systems when using my resources.

Config

In the xmmx_bridge/shared/config.lua you must configure a few basic settings in order to prevent errors in my resources or the bridge itself.

If using xmmx_bridge in other resources/scripts, you must declare at the XM variable at the top of your script. Example:

This will allow use of any my functions found within the bridge resource.

Notifications

in the xmmx_bridge/shared/notifications.lua is where you can configure or customize notifications triggered from my resources. It is pre-configured for "qb", "esx", "ox", and "qbx. Note that iServer is passed as a variable so that you may add your server-sided exports or events for notifications.

Boss Menu & Duty Toggle

This module provides unified support for opening boss menus, toggling duty status, and checking duty status across different popular FiveM frameworks (qb-core, qbx_core, and es_extended). The functions dynamically detect the active framework and execute the appropriate logic, enabling compatibility and flexibility in multi-framework environments. Located in xmmx_bridge/client/editable/bossmenu.lua:

Functions:

XM.OpenBossMenu(data)

Opens the boss management menu for the player's job, depending on the active framework:

  • qb-core: Triggers qb-bossmenu:client:OpenMenu.

  • qbx_core: Uses exports.qbx_management:OpenBossMenu.

  • es_extended: Opens the ESX society boss menu via esx_society:openBossMenu.

XM.ToggleDuty()

Toggles the player's on-duty/off-duty status:

  • qb-core: Calls the standard QBCore:ToggleDuty server event.

  • qbx_core: Checks current duty state using GetPlayerData() and toggles it using a custom bridge event xmmx_bridge:server:qbxduty.

  • es_extended: Prints a debug message as duty toggling is not supported by default.

XM.CheckDuty()

Returns a boolean indicating whether the player is currently on duty:

  • qb-core and qbx_core: Reads the player's job status from GetPlayerData().

  • Fallback: Returns true if framework is unsupported or not explicitly handled.

Callbacks

These functions provide a unified abstraction layer for triggering and registering server callbacks across multiple frameworks. By detecting which framework is active (qb-core, qbx_core, or es_extended), the bridge ensures compatibility and reduces the need for conditional logic elsewhere in your codebase.

Here’s a concise documentation description for the two functions found in xmmx_bridge/client/editable/callbacks.lua and xmmx_bridge/server/functions.lua:

Client-Side

XM.TriggerCallback(name, cb, ...)

Triggers a server callback based on the active framework:

  • qb-core: Uses QBCore.Functions.TriggerCallback.

  • qbx_core: Uses lib.callback.

  • es_extended: Uses ESX.TriggerServerCallback.

Parameters:

  • name (string) – The name of the callback to trigger.

  • cb (function) – The function to execute upon receiving the callback result.

  • ... – Additional arguments to pass to the server-side callback.

Server-Side

XM.CreateCallback(name, cb)

Registers a server callback function that can be triggered from the client:

  • qb-core: Uses QBCore.Functions.CreateCallback.

  • qbx_core: Uses lib.callback.register.

  • es_extended: Uses ESX.RegisterServerCallback.

Parameters:

  • name (string) – The identifier for the callback.

  • cb (function) – The server function to execute when the callback is called.

Consumables

XM.Consume Function

The XM.Consume function handles consumption logic for items classified as food, drink, or alcohol across different FiveM frameworks (qb-core, qbx_core, and es_extended). It deducts the item from the player’s inventory, displays a progress bar, and applies corresponding effects like hunger, thirst, and stress relief.

Function Signature

Parameters

  • _type (string) – Type of consumable: "eat", "drink", or "alcohol".

  • itemName (string) – The internal name of the item being consumed.

  • Label (string) – A readable name displayed during the progress bar animation.

  • info (table) – Optional metadata or animation info passed to the XM.Progress function.

  • amount (number) – The value to add to hunger/thirst or other needs.

  • playerId (number) – Server ID of the player consuming the item.

Behavior

  1. Item Deduction: Triggers xmmx_bridge:server:toggleItem to remove 1 unit of the item from the player's inventory.

  2. Progress Display: Shows a progress animation with a message based on the item type (e.g., "Eating Burger...").

  3. Effect Application: Once progress is complete, the function applies effects based on the active framework:

    • Food ("eat"):

      • Increases hunger (or esx_status equivalent).

    • Drink / Alcohol ("drink" / "alcohol"):

      • Increases thirst.

    • All types relieve a random amount of stress (2–4).

  4. Framework Handling:

    • qb-core / qbx_core:

      • Adjusts hunger or thirst using consumables:server:addHunger / addThirst.

      • Triggers stress relief via hud:server:RelieveStress.

    • es_extended:

      • Uses esx_status:add for hunger/thirst.

      • Still triggers the same stress relief event.

Returns

  • true if the item was successfully consumed and effects applied.

  • nil if the progress was interrupted or an unsupported type was passed.

DrawText

Text UI Display Functions

These functions abstract the process of showing and hiding text-based UI prompts, allowing compatibility with multiple user interface systems (qb-core, ox_lib, es_extended). They provide a framework-agnostic way to display contextual messages on screen.

Function: XM.ShowText(data)

Displays a text-based UI message to the player, using the method defined in Config.TextUi.

Parameters:

  • data (table) – Contains the following fields:

    • text (string, required): The message to display.

    • position (string, optional): Screen position (e.g., "right", "right-center"). Defaults vary by system.

    • icon (string, optional): Icon to use (only for ox).

    • style (table, optional): CSS-like styling options (only for ox).

Framework-Specific Behavior:

  • qb: Uses qb-core’s DrawText with basic positioning.

  • ox: Uses lib.showTextUI with additional support for icons and styling.

  • esx: Calls ESX.TextUI with just the text string.

Function: XM.HideText()

Hides the currently displayed text UI, based on the configured UI framework.

Framework-Specific Behavior:

  • qb: Hides text using qb-core:HideText.

  • ox: Calls lib.hideTextUI.

  • esx: Uses ESX.HideUI.

These functions make switching between UI libraries seamless and centralized, ideal for projects that want to support multiple frameworks or migrate between them easily.

Hud / Radar Toggles

Function: XM.ShowHud(bool)

This function is responsible for toggling the visibility of the player HUD (Heads-Up Display) based on the currently active HUD resource. It supports multiple popular HUD systems and includes extension points for custom HUDs.

Parameters

  • bool (boolean) –

    • true: Show the HUD.

    • false: Hide the HUD.

Framework-Specific Behavior

Depending on which HUD resource is active (i.e., its state is "started"), the function executes the corresponding visibility control:

Supported HUDs:

  • 17mov_Hud

    • ToggleDisplay(true/false): Shows or hides the entire HUD.

    • HideRadar(false/true): Shows or hides the minimap.

  • 0r-hud-v3

    • ToggleVisible(true/false): Inverted logic; false shows HUD, true hides it.

  • tgiann-lumihud

    • Triggers the event "tgiann-lumihud:ui" with a true or false value.

  • your_hud

    • Placeholder for custom HUD integration. Developers can add the appropriate export or event logic to support additional HUD systems.

Usage Example

This function simplifies HUD toggling by abstracting resource-specific commands and encouraging modular extension.

Inventory Utilities

These functions are part of a cross-framework abstraction layer for managing inventory states, visibility, and item metadata across various supported inventory systems in FiveM.

Function: XM.InventoryBusy(bool)

Temporarily enables or disables the player's ability to interact with the inventory UI and hotkeys. This is useful during animations, progress bars, or any scripted events where the inventory should be locked.

Parameters

  • bool (boolean) – true to mark the inventory as busy, false to re-enable access.

Framework-Specific Behavior

  • ox_inventory: Uses LocalPlayer.state.invBusy and invHotkeys to lock/unlock.

  • qb-inventory / codem-inventory (QB): Sets inv_busy flag via LocalPlayer.state:set.

  • qs-inventory: Uses setInventoryDisabled(true/false).

  • codem-inventory (ESX): Uses LocalPlayer.state.invBusy.

Function: XM.CloseInv()

Closes the player's inventory interface, depending on the inventory type defined in Config.Inventory.

Behavior by Config Setting

  • ox: Calls ox_inventory:closeInventory().

  • newQB, oldQB, codem: Executes closeinv command.

  • qs: Stubbed (does not call any close method due to ineffective documentation).

Function: XM.ConsumedItem(itemName)

Fetches the label (display name) of an item by its internal name to be used in UI feedback such as progress bars.

Parameters

  • itemName (string) – The internal name of the item to look up.

Returns

  • (string) – The label of the item, or "Something" if not found.

Framework-Specific Behavior

  • qb-core:

    • With ox_inventory: Calls ox_inventory:GetPlayerItems() and loops through to find item.

    • Otherwise: Retrieves from QBCore.Shared.Items.

  • qbx_core: Always uses ox_inventory.

  • es_extended:

    • Uses appropriate getInventory() export based on Config.Inventory: ox, qs, or codem.

These functions streamline inventory interactions in multi-framework environments, helping developers write framework-agnostic logic for immersive and safe player interactions.

Minigame

Function: XM.MiniGame(data)

Launches a mini key-press game using the xmmx_keysgame resource, providing a simple and configurable way to add skill-based interactions to your scripts (e.g., lockpicking, hacking, crafting, etc.).

Parameters

  • data (table) – Configuration for the mini-game, including:

    • mode (string) – Game difficulty or mode (as defined by the xmmx_keysgame export).

    • keys (number) – Number of keys the player must press.

    • time (number) – Total time allowed (in milliseconds or seconds, based on xmmx_keysgame implementation).

    • label (string) – Text displayed during the game.

    • color1 (string, optional) – Primary color in hex (default: "#00a79c").

    • color2 (string, optional) – Secondary color in hex (default: "#70c0bb").

Returns

  • success (boolean) – true if the player completed the mini-game successfully, false if failed or aborted.

Example Usage

This function simplifies integrating interactive mini-games into your gameplay loop using standardized input and visuals.

Player Job

These functions provide standardized, framework-agnostic ways to retrieve the player’s job and validate if they are an employee for a given in-world location. This supports dynamic job-based systems such as business management, shop zones, or role-restricted interactions.

Function: XM.EmployeeJob()

Returns the current job name of the player across supported frameworks.

Returns

  • (string or nil) – The player’s current job name (e.g., "police", "burgershot"), or nil if unavailable.

Framework Support

  • qb-core: Uses QBCore.Functions.GetPlayerData().

  • qbx_core: Uses exports.qbx_core:GetPlayerData().

  • es_extended: Uses ESX.GetPlayerData().

Function: XM.IsEmployee(Location)

Checks if the player is employed at any of the provided job locations within a 100.0 unit radius.

Parameters

  • Location (table) – A list of location/job definitions, each containing:

    • job (string) – The job name to match.

    • coords (vector3) – The location to check proximity against.

Returns

  • (boolean) – true if the player has one of the specified jobs and is within range of the respective location, otherwise false.

Distance Check

  • A distance threshold of 100.0 units is used to determine if the player is "at" the location.

Example Location Table Format

These functions are useful for determining job-restricted access to areas, triggering boss menu logic, or controlling role-specific gameplay elements based on proximity and role.

Progress Bar

Function: XM.Progress(label, info)

Displays a progress bar animation tailored to the active framework (qb, ox, or esx). This function unifies progressbar behavior, including optional animations, props, and player interaction settings. It ensures the inventory is marked as "busy" during interaction to prevent conflicts with item usage.

Parameters

  • label (string) The message shown on the progress bar.

  • info (table, required) A configuration table containing animation and behavior options:

    • Time (number) – Duration of the progress (default: 5000 ms).

    • Move (boolean) – Whether player movement is allowed (default: false).

    • Dict, Clip, Flag (string/number) – Animation dictionary, clip name, and animation flags.

    • Prop, Prop2 (string) – Model names for props to attach.

    • Bone, Bone2 (number) – Bones to attach props to.

    • Coord, Coord2 (vector3) – World offsets for prop attachment.

    • Rot, Rot2 (vector3) – Rotation values for props.

Supported Frameworks & Behavior

✅ qb-core

  • Uses QBCore.Functions.Progressbar.

  • Temporarily disables inventory via XM.InventoryBusy(true) during progress.

  • Supports animations and up to 2 props.

  • Synchronous behavior via while not isCompleted loop.

✅ ox_lib

  • Uses lib.progressCircle.

  • Configurable props, position, and animations.

  • Returns immediately with success state.

✅ es_extended

  • Uses ESX.Progressbar.

  • Supports freezing player and basic animation.

  • Uses onFinish/onCancel callbacks for result handling.

☑️ custom

  • Placeholder for custom progress implementation.

❌ Unsupported

  • Logs an error if Config.Progress is not recognized.

Returns

  • (boolean) – true if the progress completed successfully, false if it failed or was aborted.

Example Usage

This function enables immersive, framework-aware progress feedback for any interaction scenario.

Targeting Controls

These functions enable or disable interaction targeting systems during scripted events, such as progress bars, animations, or menus—where interaction interruptions must be prevented. They support several popular targeting frameworks.

Function: XM.TargetInactive()

Disables player targeting temporarily by detecting the active targeting resource and calling its appropriate method.

Supported Frameworks & Behavior

  • ox_target: Calls disableTargeting(true)

  • qb-target: Calls AllowTargeting(false)

  • qtarget: Also uses AllowTargeting(false) (likely interchangeable export name)

Function: XM.TargetActive()

Re-enables player targeting after it has been disabled. Intended to be used following XM.TargetInactive() once the task (e.g., progress bar) is complete.

Supported Frameworks & Behavior

  • ox_target: Calls disableTargeting(false)

  • qb-target: Calls AllowTargeting(true)

  • qtarget: Calls AllowTargeting(true)

Use Case Example

Used alongside other functions (e.g., XM.Progress) to prevent interaction conflicts:

These utilities provide seamless and framework-aware control over player interaction targeting to maintain immersion and prevent unintended interruptions.

Target Box Zones

This system abstracts and standardizes interaction zones ("target zones") using popular target libraries in FiveM: ox_target, qb-target, and qtarget. It supports dynamic creation and removal of box-style target zones with custom options.

🔄 Initialization

Upon script startup, it detects the first available and supported target system (ox_target, qb-target, qtarget) and sets TargetSystem accordingly. If no target system is found, it logs a warning.

🔧 Function: XM.AddTargetZone(data)

Creates a new box-style interaction zone using the active target system.

Parameters

  • data (table) – Zone configuration:

    • name (string) – Unique identifier for the zone (required).

    • coords (vector3) – Zone center coordinates.

    • size (vector2) – Zone dimensions (x, y).

    • rotation (number) – Rotation angle in degrees.

    • debug (boolean) – Optional debug drawing.

    • drawSprite (boolean) – OX-specific: show sprite marker (default: true).

    • options (table) – List of target interaction options.

    • distance (number) – Interaction distance (for qb/qtarget only).

Returns

  • (string) – The name of the zone added, or nil if unsuccessful.

Behavior by Target System

  • ✅ ox_target: Uses ox_target:addBoxZone() with full support for size, rotation, sprite, and interaction options.

  • ✅ qb-target / qtarget: Uses AddBoxZone() with a heading and bounding box (minZ, maxZ), and adapts the options list:

    • Converts groups to job field.

    • Converts onSelect to action.

🗑️ Function: XM.RemoveTargetZone(name)

Removes a previously added target zone from the active target system.

Parameters

  • name (string) – The name of the zone to remove.

Behavior

  • ✅ ox_target: Calls removeZone(name)

  • ✅ qb-target / qtarget: Calls RemoveZone(name)

  • Removes the zone from the TargetZones registry.

🛑 Event Cleanup: onResourceStop

Automatically removes all registered target zones when the resource stops, ensuring no orphaned zones are left behind.

✅ Example Usage

Located in xmmx_bridge/client/targets/boxzones.lua:

Target Entities

This system allows you to dynamically assign interactive target options to entities (peds, vehicles, props, etc.) across supported target frameworks: ox_target, qb-target, and qtarget. It ensures clean initialization, unified behavior, and proper cleanup.

🔄 Initialization

When the script starts, it automatically sets TargetSystem based on which target resource is active. If none are found, a warning is printed to the console.

✅ Function: XM.AddTargetEntity(entity, options)

Adds interactive targeting options to a specific entity (e.g., ped, object, or vehicle).

Parameters

  • entity (Entity handle) – The in-game entity to target (must exist).

  • options (table) – A list of targeting options:

    • label (string) – Text shown when aiming at the entity.

    • icon (string) – Icon shown in the target UI.

    • onSelect (function) – Callback triggered on selection (auto-converted to action for qb/qtarget).

    • groups (table, optional) – Jobs allowed to see this option.

    • distance (number) – Optional interaction distance (defaults to 2.0).

Behavior by Target System

  • ✅ ox_target:

    • Calls ox_target:addLocalEntity(entity, options) directly.

  • ✅ qb-target / qtarget:

    • Converts groups to job field.

    • Converts onSelect to action function.

    • Wraps options in a distance field and calls AddTargetEntity.

Example Usage

Function: XM.RemoveTargetEntity(entity)

Removes an entity's targeting options if they were previously registered.

Parameters

  • entity (Entity handle) – The entity to deregister.

Behavior

  • Calls:

    • ox_target:removeLocalEntity(entity)

    • or qb-target/qtarget:RemoveTargetEntity(entity)

  • Cleans up EntityTargets table entry.

🧼 Resource Cleanup: onResourceStop

Automatically removes all entity targets registered during the resource's lifecycle when the script stops:

🗂️ Internals

  • EntityTargets (table) – Tracks all added entities for cleanup.

  • TargetSystem (string) – Holds the name of the active target resource (ox_target, qb-target, qtarget).

This system enables framework-agnostic entity targeting and maintains clean behavior through proper conversion and lifecycle handling. Located in xmmx_bridge/client/targets/targetentity.lua:

Interact

This module integrates with the interact resource to support model- and entity-based interaction zones in a structured and maintainable way. It allows defining interaction prompts tied to in-game models or entities and ensures automatic cleanup when the resource stops.

🧠 Internal State

  • InteractReady: Boolean flag to confirm the interact resource is active.

  • InteractTargets: Tracks registered interactions (model or entity) for cleanup.

🔁 Initialization

Checks for interact resource availability and enables interaction functionality accordingly.

Function XM.AddInteractModel(data)

Registers an interaction target for one or more models.

Parameters

  • data (table) – Interaction configuration:

    • model (string or table) – One or more model names.

    • options (table) – List of interaction options (icon, label, onSelect, etc.).

    • offset, bone, distance, interactDst, groups, name, id (optional) – Additional interaction parameters.

Behavior

  • Iterates through all provided model names.

  • Generates a unique or custom interactionId for each.

  • Calls interact:AddModelInteraction for each model.

Function XM.AddInteractEntity(entity, data)

Registers an interaction for a specific game entity.

Parameters

  • entity (entity handle) – The in-game entity (ped, vehicle, prop, etc.).

  • data (table) – Includes:

    • options, distance, interactDst, name, offset, bone, ignoreLos, groups, id (optional)

Behavior

  • Builds an interaction configuration and calls interact:AddLocalEntityInteraction.

  • Stores reference in InteractTargets for later cleanup.

Function XM.RemoveInteract(id)

Removes a previously registered model or entity interaction.

Parameters

  • id (string) – The unique interaction ID to remove.

Behavior

  • If it was a model-based interaction: calls RemoveModelInteraction.

  • If it was entity-based: calls RemoveLocalEntityInteraction.

🧼 Event Handler onResourceStop Cleanup

Ensures all interact targets are properly removed if the resource is stopped:

🧪 Example: Add Interaction to Trash Can Model

This integration provides a modular, extensible, and resource-safe method of handling interactions via the interact resource, promoting consistency and ease of use across your server scripts.

Located in xmmx_bridge/client/target/interact.lua:

Society Funds

These functions provide a unified way to add to or remove from a job/society’s shared account across various banking systems used in FiveM (qb, esx, okok, Renewed, etc.). This abstraction allows for compatibility across different frameworks without needing to change the business logic.

Function: XM.AddSocietyMoney(src, society, amount)

Adds funds to a society or job’s shared account.

Parameters

  • src (number) – Player source (unused in current logic, but may be useful for auditing or custom implementation).

  • society (string) – Name of the society or job (e.g., "police").

  • amount (number) – Amount of money to add.

Supported Banking Resources

  • qb-banking: AddMoney(society, amount)

  • fd_banking: AddMoney(society, amount)

  • Renewed-Banking: addAccountMoney(society, amount)

  • esx_society: esx_addonaccount:getSharedAccount("society_<name>") → addMoney(amount)

  • okokbanking: AddMoney(society, amount)

  • your_society: Placeholder for custom implementation

Function: XM.RemoveSocietyMoney(society, amount, reason)

Removes funds from a society’s shared account.

Parameters

  • society (string) – Society or job name.

  • amount (number) – Amount to remove.

  • reason (string) – Reason for the deduction (used in some banking systems).

Supported Banking Resources

  • qb-banking: RemoveMoney(society, amount, reason)

  • fd_banking: RemoveMoney(society, amount, reason)

  • Renewed-Banking: RemoveAccountMoney(society, amount)

  • esx_society: esx_addonaccount:getSharedAccount("society_<name>") → removeMoney(amount)

  • okokbanking: RemoveMoney(society, amount)

  • your_society: Placeholder for custom removal logic

🧪 Example Usage

These functions allow seamless switching or support for multiple banking frameworks without modifying core game logic. Let me know if you'd like helper logging or Discord webhooks added for auditing transactions! Located in xmmx_bridge/server/societies/society.lua:

🛡️Anti-Cheat

Function XM.ValidateCaller(expected, src, actionLabel) This function serves as a security utility to validate that a triggering source (src) matches the expected source (expected). It's designed to prevent unauthorized or spoofed event usage, acting as a lightweight anti-cheat mechanism.

✅ Purpose

Ensures that sensitive server-side events are only executed by their rightful triggering client (e.g., validating a player's own action). If the validation fails, the player can be optionally dropped from the server, and a Discord webhook notification can be sent for admin review.

🔧 Parameters

Name
Type
Description

expected

number

The expected player source ID (usually the one originally associated with the action).

src

number

The actual player source that triggered the server event.

actionLabel

string

A label or name of the action being validated (used in logs/webhook).

🔁 Behavior

  1. Mismatch Detection If src does not match expected, an anti-cheat alert is triggered.

  2. Logging & Punishment

    • Prints a message to the server console.

    • Optionally drops the player from the server using DropPlayer.

    • Sends a Discord webhook alert if a valid Webhook URL is defined.

  3. Webhook Payload Structure

    • Player name, source ID, attempted event/action, and the expected source.

    • Timestamped for log tracking.

💬 Example Use

🔒 Security Notes

  • Always use this check for sensitive actions triggered by the client (e.g., money handling, item giving, job switching).

  • Be cautious with DropPlayer() usage in development environments.

🧪 Optional Webhook Setup

To enable Discord alerts, configure the global Webhook variable:

Located in xmmx_bridge/server/anticheat/anticheat.lua:

Framework Functions

🧰 XM Server-Side Framework Utilities

These functions abstract common player-related actions across multiple popular FiveM frameworks—QBCore, ESX, and QB-X—providing a consistent interface for:

  • Cash and bank transactions

  • Inventory item management

  • Meta item support

  • Toggling items

  • Duty toggling (for qbx_core)

Each framework implementation is conditionally loaded depending on the active resources.

🧾 Common Function Definitions

Each framework implements these shared utility functions:

Function XM.AddMoney(src, amount, reason)

Adds money to the player’s cash wallet.

Function XM.RemoveMoney(src, amount, reason)

Removes money from the player’s wallet.

Function XM.AddBank(src, amount, reason)

Adds money to the player’s bank account.

Function XM.RemoveBank(src, amount, reason)

Removes money from the player’s bank account.

Function XM.AddItem(src, item, amount)

Gives the player a specific item.

Function XM.RemoveItem(src, item, amount)

Removes an item from the player's inventory.

Function XM.AddMetaItem(src, item, amount, meta)

Adds an item with metadata (supports various inventories like ox, qs, codem).

Function XM.ToggleItem(src, bool, item, amount)

Adds or removes an item based on the bool value.

🔷 QBCore Implementation

  • Framework: qb-core

  • Inventory support check: qb-inventory (for item box animation)

  • Meta item support: Handles ox_inventory, qs, codem, ak47, and qb-inventory

  • Uses QBCore.Functions.GetPlayer(src)

🔶 ESX Implementation

  • Framework: es_extended

  • Uses ESX.GetPlayerFromId(src)

  • Meta item support includes: ox_inventory, qs, codem, ak47_inventory

🔷 QBX (QBCore Extended) Implementation

  • Framework: qbx_core

  • Uses exports.qbx_core:*

  • Inventory: Primarily relies on ox_inventory

  • Duty toggle supported via:

❗ Note:

  • AddBank and RemoveBank are placeholders and need implementation based on your banking system.

🧪 Example Usage

Framework Bridge

This script enables a unified server-side interface to handle player-related logic like money, items, job checks, and usable items across QBCore, QB-X, and ESX frameworks. It allows modular and framework-agnostic scripting.

🔍 Framework Detection

On resource load, it sets the framework variable based on what’s running:

  • "qb-core"

  • "qbx_core"

  • "es_extended"

🧰 XM Utility Functions

✅ Function XM.GetPlayer(src)

Returns the player object from the active framework.

✅ Function XM.GetPlayerCash(src)

Gets the player's current cash amount.

✅ Function XM.GetPlayerBank(src)

Gets the player's bank account balance.

🧩 Function XM.CreateCallback(name, cb)

Registers a server callback compatible with the active framework:

  • QBCore.Functions.CreateCallback

  • lib.callback.register

  • ESX.RegisterServerCallback

🧪 Function XM.RegisterItemUseable(itemName, eventName)

Registers a usable item that triggers a client event.

  • Framework-specific registration:

    • QBCore.Functions.CreateUseableItem

    • exports.qbx_core:CreateUseableItem

    • ESX.RegisterUsableItem

👥 Function XM.GetPlayersNotInJobs(excludedJobs)

Returns a list of player IDs who are not in any of the specified jobs.

  • Useful for excluding certain roles (e.g., police or EMS) from missions.

👮 Function XM.PoliceCheck(jobs, count)

Registers a server callback xmmx_moneyruns:server:GetCopCount to verify if there are enough on-duty police (or specified jobs) on the server.

  • Works differently per framework, respecting each framework's job/duty system.

  • Returns true or false to the client via callback.

🔄 Inventory Toggle Handler

Server event used to add or remove an item from a player's inventory:

  • Performs anti-cheat validation with XM.ValidateCaller

  • Calls XM.ToggleItem() to process the item change

🛡️ Security Reminder

All sensitive server events like toggleItem are protected by XM.ValidateCaller, which ensures only the legitimate player can trigger the event.

✅ Example Usages

PreviousWelcome to XMMX DevelopmentNext20 vs 1 Script

Last updated