Trabajo de mecánico en FiveM: reparación de natives, mods de ajuste y comprobaciones de trabajo

El síntoma: tu mecánico arregla un auto y el motor aún humea, las abolladuras se quedan, una pieza ajustada desaparece después de un reinicio, o cualquier jugador puede reparar vehículos gratis.

Un trabajo de mecánico son dos trabajos en uno: reparación (valores de salud y natives) y ajuste (mods de vehículo). Ambos se ejecutan en el cliente, así que la parte que debes proteger es quién está permitido triggerearlo.

#Reparar un vehículo

Una sola native no es suficiente para una reparación limpia. Esta combinación hace el trabajo:

-- client
local function repairVehicle(vehicle)
    SetVehicleFixed(vehicle)
    SetVehicleDeformationFixed(vehicle)
    SetVehicleEngineHealth(vehicle, 1000.0)
    SetVehicleBodyHealth(vehicle, 1000.0)
    SetVehicleUndriveable(vehicle, false)
    SetVehicleEngineOn(vehicle, true, true, false)
end

• SetVehicleFixed repara el vehículo en general, incluyendo llantas.
• SetVehicleDeformationFixed elimina las abolladuras que la primera native puede dejar.
• SetVehicleEngineHealth y SetVehicleBodyHealth toman un valor hasta 1000.0. Por debajo de cero el motor está muerto, así que establecerlos de nuevo lo hace arrancar nuevamente.

Como un vehículo es una entidad de red, el cliente que hace la reparación debe poseerlo. Si la reparación funciona en tu propio auto pero no en el de un cliente, solicita control primero:

NetworkRequestControlOfEntity(vehicle)
local timeout = 0
while not NetworkHasControlOfEntity(vehicle) and timeout < 50 do
    Wait(10)
    timeout += 1
end

Para reparaciones parciales (solo motor, solo cuerpo), llama solo a la native de salud que coincida. Los valores de salud también importan para otros scripts, por ejemplo daño de vehículo y salud del motor explica qué hace cada número.

#Ajuste con SetVehicleMod

Los mods son espacios numerados. Dos reglas se aplican a todos ellos:

1. Llama a SetVehicleModKit(vehicle, 0) antes de cualquier cambio de mod.
2. Pregunta al juego cuántas opciones tiene un espacio con GetNumVehicleMods. Un índice de -1 es la pieza de serie.

-- client
local function setMod(vehicle, modType, index)
    SetVehicleModKit(vehicle, 0)
    local count = GetNumVehicleMods(vehicle, modType)
    if index >= -1 and index < count then
        SetVehicleMod(vehicle, modType, index, false)
    end
end

-- engine is mod type 11, brakes 12, transmission 13, suspension 15
setMod(vehicle, 11, 2)

-- turbo is a toggle, not a numbered mod
ToggleVehicleMod(vehicle, 18, true)

Verificar el índice contra GetNumVehicleMods evita un fallo silencioso cuando un vehículo tiene menos opciones de lo que esperabas. La pintura y el color usan sus propias natives (SetVehicleColours y otros), así que trátalos como un menú separado.

Consejo: construye el menú de ajuste desde el vehículo en sí, iterando sobre los espacios con GetNumVehicleMods, en lugar de codificar los números. Los vehículos adicionales a menudo tienen un número diferente de opciones.

#Guardar los mods

Establecer un mod solo cambia la entidad en vivo. Cuando el jugador guarda el auto en el garaje y lo saca de nuevo, el mod se va a menos que fue guardado con el vehículo. Guarda el conjunto completo de propiedades después de ajustar y aplícalas cuando el vehículo spawneа. El flujo completo está en guardar propiedades de vehículo y mods.

#Acciones controladas por trabajo

El código de reparación y ajuste se ejecuta en el cliente, así que un cliente modificado puede llamarlo para cualquiera. Pon la regla en el servidor:

-- server (ox_lib)
lib.callback.register('mechanic:canRepair', function(source)
    -- 1. job check: use your framework's player/job getter here
    -- 2. distance check: the player must be near a vehicle or workshop
    -- 3. item check and removal
    local removed = exports.ox_inventory:RemoveItem(source, 'repairkit', 1)
    return removed and true or false
end)

-- client
lib.callback('mechanic:canRepair', false, function(ok)
    if ok then repairVehicle(vehicle) end
end)

La comprobación de trabajo depende de tu framework. En ESX lee el trabajo del objeto del jugador, en QBCore y QBox léelo de los datos del jugador. Usa el getter de tu framework en el paso 1 y compara contra tu nombre de trabajo de mecánico, como se cubre en añadiendo un trabajo en ESX y añadiendo un trabajo en QBCore. Para el patrón de callback en frameworks, ver callbacks del servidor.

Otras cosas que vale la pena controlar:

• Kits de reparación como objetos, así que una reparación cuesta algo y el objeto se elimina en el servidor.
• Zonas de taller, así que el ajuste solo se abre dentro de un garaje o en un banco.
• Pagar al mecánico o a la cuenta de la sociedad en el servidor, no desde el cliente.

Una barra de progreso con una opción de cancelación hace que las reparaciones se sientan bien. Ver barras de progreso en ESX, QBCore y ox_lib.

#Checklist