Commands & Exports

This section lists all available commands, exports, and events included in the script. You’ll find client-side, server-side, and shared functions designed to help developers integrate, extend, or interact with the system easily within their own scripts or frameworks.

Client Exports

This section provides all available client exports for the script. These functions allow you to interact directly with the system from the client side, enabling custom features, UI interactions, and integrations with other resources. Each export includes a short description and usage example for easy implementation.

IsPlayerInDM

The IsPlayerInDM export allows you to check if a player is currently participating in a Deathmatch session. This is useful for managing or restricting specific actions while the player is engaged in a Deathmatch.

How to Use

To check whether the player is in a Deathmatch session, use the following code:

if exports['qs-deathmatch']:IsPlayerInDM() then
    print("Player is in a Deathmatch match")
end

This will return a boolean value (true or false) indicating whether the player is actively in a Deathmatch. You can use this information to implement custom logic, such as disabling specific features, triggering events, or providing Deathmatch-specific functionality during the session.

inDeathmatch Handler

The deathmatch:inDeathmatch event is used to track a player's current state in a Deathmatch session. This allows you to update and manage a local variable (inDeathmatch) to reflect whether the player is currently participating in a Deathmatch.

How to Use

To track the player's Deathmatch state, use the following code:

local inDeathmatch = false
AddEventHandler('deathmatch:inDeathmatch', function(state)
    inDeathmatch = state
end)

Explanation

  • inDeathmatch: A local boolean variable initialized as false.

  • AddEventHandler: Listens for the deathmatch:inDeathmatch event.

  • state: The parameter passed with the event, indicating the player's current Deathmatch status (true if in Deathmatch, false otherwise).

  • When the event is triggered, the state value updates the inDeathmatch variable, allowing you to track the player's status in real-time.

You can then use the inDeathmatch variable in your code to control or restrict actions based on whether the player is actively in a Deathmatch session. For example:

if inDeathmatch then
    print("Player is in a Deathmatch session.")
else
    print("Player is not in a Deathmatch session.")
end
GetData

The GetData export allows you to retrieve the internal PBData table. This is useful for accessing the current state of the system (such as configuration, counters, players, etc.) without directly interacting with local variables inside the resource.

How to Use

To get the data, use the following code:

local data = exports['qs-deathmatch']:GetData()

This will return a Lua table containing the current PBData information. You can use this data to implement custom logic, read flags, query statistics, or display information in the NUI.

Note: GetData provides a reference to PBData. If you only need to read the data, avoid modifying it. If you need to make changes, use the appropriate events or callbacks provided by the resource to maintain state integrity.

Server Exports

This section provides all available server exports for the script. These functions allow developers to interact with the system from the server side, manage data, trigger actions, and integrate with other resources. Each export includes a clear description and a practical example to simplify its implementation.

IsPlayerInDM

The IsPlayerInDM export allows you to check if a specific player (identified by their source) is currently participating in a Deathmatch. This is useful for managing gameplay logic or triggering specific events for players in active matches.

How to Use

To check if a player is in a Deathmatch, use the following code:

if exports['qs-deathmatch']:IsPlayerInDM(source) then
	print('Player: ' .. source .. ' is in a Deathmatch match')
end

This allows for custom logic to be applied based on the player's status, such as restricting access to certain features or logging their participation.