[Enhancement] - ESX Core - Improvement of the Service System

[voidvalue-dev]

Adding a setDuty function could remove the ESX Service, as they are not fully integrated. You can go off duty in ESX Service, but the job metadata in ESX Core will still return true.

Guidance example:

---@param onDuty? boolean
---@return nil
function self.setDuty(onDuty)
    if type(onDuty) ~= "boolean" then
        onDuty = Config.DefaultJobDuty
    end

    self.job.onDuty = onDuty
    self.metadata.jobDuty = onDuty
end

At the very least, it would be advisable to review the ESX Service, as it doesn’t work as well as an on-duty system should 😭

[Kenshiin13]

    ---@param newJob string
    ---@param grade string
    ---@param onDuty? boolean
    ---@return nil
    function self.setJob(newJob, grade, onDuty) end

@cesarmr-github The setJob function already allows you to set the players duty status.

[Kenshiin13]

At the very least, it would be advisable to review the ESX Service, as it doesn’t work as well as an on-duty system should 😭

You should use either esx_service, or the new duty system. Not both. The latter is an optional replacement for esx_service.

[voidvalue-dev]

Honestly, I think that addon is completely unnecessary, considering that almost all the job logic is already in the core. It doesn’t make much sense to have this in esx_service, which doesn’t even correctly update the player’s metadata. Integrating the on/off duty logic directly into the core would make the system much more consistent and reliable, and it would avoid having to use setJob every time you want to change the duty status.

---@param newJob string
---@param grade string
---@param onDuty? boolean
---@return nil
function self.setJob(newJob, grade, onDuty) end
@cesarmr-github The setJob function already allows you to set the players duty status.

[Kenshiin13]

Luckily, every server owner can decide for themselves if they prefer to work with esx_service or job duty. That's not our decision to make. There are plenty of user scripts that use esx_service as a dependency, so just removing it is not an option.

Whether you call xPlayer.setJob() or xPlayer.setJobDuty() makes no functional difference. We chose to integrate it into xPlayer.setJob for ease of use.

[137ElPro]

The main issue is that the setJob function in ESX violates the single function responsibility principle because it handles two distinct actions simultaneously: changing a player’s job and updating their duty status (onDuty/offDuty).

When setJob is used solely to toggle the duty status, it still triggers the esx:setJob event. This causes other resources listening to this event to incorrectly interpret the action as a full job change, even though the player’s job and grade haven’t changed.

The consequences of this design include:

Unnecessary event triggers: Listeners react to a job change that didn’t actually occur.

Confusion in dependent scripts: Other resources may execute logic assuming a job change happened.

Lack of clarity and separation: The system does not clearly differentiate between changing a job and toggling duty status, which can lead to inconsistencies.

In short, setJob combines two responsibilities that should be separate, violating the principle of single responsibility and making the system less predictable and harder to maintain.

[Kenshiin13]

By your logic, setJob already violates SRP because it includes job grade as well. If we followed that to the letter, we would need three separate functions:

• setJob
• setJobGrade
• setJobDuty

But that separation would be artificial. A player’s job is defined by name + grade + duty together. Treating them as unrelated “responsibilities” is a misrepresentation of SRP. ESX intentionally models them as a single unit of state.

The fact that toggling duty triggers esx:setJob is not a side-effect — it’s the purpose. We integrated duty into setJob so you don’t need to listen to a separate event just for duty and then still fetch the player’s job anyway. A duty change in isolation is not meaningful without the job context.

The unified approach ensures you always get the full job object in one place.

The esx:setJob event explicitly passes the old job object. That exists precisely so listeners can compare the old and new state and decide if the change is relevant (job name, grade, duty, or all three).

The fact that the event fires doesn’t mean “a full job change happened.” It could be only the grade that changed. Or only duty. If dependent code reacts blindly to any trigger without checking the difference, that’s a user error, not a design flaw — and it would be just as true today if duty weren’t part of the job object.

[voidvalue-dev]

Luckily, every server owner can decide for themselves if they prefer to work with esx_service or job duty. That's not our decision to make. There are plenty of user scripts that use esx_service as a dependency, so just removing it is not an option.

Whether you call xPlayer.setJob() or xPlayer.setJobDuty() makes no functional difference. We chose to integrate it into xPlayer.setJob for ease of use.

Typically, script creators develop their own service system.
Even if the user can choose between using esx_service or the core duty system, both should be properly connected and integrated. This way, if one script uses one system and another script uses the other, everything works consistently.

Example:
Imagine esx_service is like a bottle of Coca-Cola and the core duty system is like a Mentos. On their own, they work fine, but if you want to combine them, they need to be properly integrated so the reaction is controlled and doesn’t explode unexpectedly.

[voidvalue-dev]

And because you would have to pass the job to leave or enter service

[Kenshiin13]

Even if the user can choose between using esx_service or the core duty system, both should be properly connected and integrated. This way, if one script uses one system and another script uses the other, everything works consistently.

esx_service does more than just toggle duty. It also enforces limits on how many players can be on duty for a given job. That’s deliberately outside the scope of the integrated duty system in ESX.

Trying to connect the two doesn’t make sense because they serve different purposes. You simply choose which duty system to use:

• the integrated job duty,
• esx_service,
• or even a completely standalone solution.

It’s up to the script developer to expose that choice to their users. In practice, it doesn’t matter which one you use — but it doesn’t make sense to merge them into a single design when their responsibilities aren’t the same.

[Kenshiin13]

People who don’t actively contribute often forget that the ESX codebase comes from years of legacy decisions, mistakes, and bad practices. We work with what we have, and simply rewriting core resources and breaking compatibility is not an option.

Instead, we provide alternatives — developers can choose what works best for their server without forcing breaking changes on everyone else.

[137ElPro]

Well, I'm not on duty, but I get paid. What's the point if it's not managed by the core?

Thanks for paying me by heisting, haha.