Description

Introducing static ESX Player methods to streamline player handling. Instead of dealing with a bloated xPlayer object that can impact performance as player counts grow, this implementation provides a lightweight alternative by dynamically calling only the required functionality through exports.

Motivation

The current xPlayer object is overly bloated, storing unnecessary data that scales poorly with larger player bases. This approach addresses these performance concerns while maintaining a syntax familiar to ESX developers.

Implementation Details

The ESX.Player object uses a metamethod to return a lightweight table containing only the player's server ID when called. If the requested player is offline, it simply returns nil. For any subsequent method calls, the stored server ID is used to trigger the appropriate export, ensuring efficient and dynamic behavior.

Usage Example

local src = 1
local xPlayer = ESX.Player(src)
if (not xPlayer) then
    print("player not found")
    return
end

print(xPlayer.getIdentifier())

local identifier = "char1:12754a0705e35cda21ced87c7daf329730135087"
local xTarget = ESX.Player(identifier)
if (not xTarget) then
    print("target not found")
    return
end

print(xTarget.getIdentifier())

PR Checklist

• My commit messages and PR title follow the Conventional Commits standard.
• My changes have been tested locally and function as expected.
• My PR does not introduce any breaking changes.
• I have provided a clear explanation of what my PR does, including the reasoning behind the changes and any relevant context.