Mechanic job em FiveM: natives de reparo, mods de tuning e verificações de trabalho

O sintoma: seu mecânico conserta um carro e o motor ainda fuma, os amassados permanecem, um tuning desaparece após um reinício, ou qualquer jogador pode reparar veículos gratuitamente.

Um mechanic job é dois trabalhos em um: reparar (valores de saúde e natives) e sintonizar (mods de veículos). Ambos rodam no cliente, então a parte que você deve proteger é quem é permitido dispará-los.

#Reparando um veículo

Um único native não é suficiente para um reparo limpo. Esta combinação faz o trabalho:

-- 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 o veículo em geral, incluindo pneus.
• SetVehicleDeformationFixed remove os amassados que o primeiro native pode deixar para trás.
• SetVehicleEngineHealth e SetVehicleBodyHealth pegam um valor até 1000.0. Abaixo de zero o motor está morto, então defini-los de volta o faz voltar a funcionar.

Como um veículo é uma entidade em rede, o cliente que faz o reparo deve possuí-lo. Se o reparo funciona em seu próprio carro e não no do cliente, solicite controle primeiro:

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

Para reparos parciais (apenas motor, apenas carroceria), chame apenas o native de saúde correspondente. Valores de saúde também importam para outros scripts, por exemplo vehicle damage and engine health explica o que cada número faz.

#Sintonizando com SetVehicleMod

Mods são slots numerados. Duas regras se aplicam a todos eles:

1. Chame SetVehicleModKit(vehicle, 0) antes de qualquer mudança de mod.
2. Pergunte ao jogo quantas opções um slot tem com GetNumVehicleMods. Um índice de -1 é a peça de estoque.

-- 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 o índice contra GetNumVehicleMods evita uma falha silenciosa quando um veículo tem menos opções do que você espera. Pintura e cor usam seus próprios natives (SetVehicleColours e outros), então trate-os como um menu separado.

Dica: construa o menu de sintonização do próprio veículo, percorrendo os slots com GetNumVehicleMods, em vez de hardcodificar os números. Veículos addon frequentemente têm um número diferente de opções.

#Salvando os mods

Definir um mod muda apenas a entidade ao vivo. Quando o jogador armazena o carro na garagem e o tira novamente, o mod desaparece a menos que tenha sido salvo com o veículo. Salve o conjunto completo de propriedades após a sintonização e aplique-as quando o veículo for criado. O fluxo inteiro está em saving vehicle properties and mods.

#Ações controladas por trabalho

O código de reparo e sintonização roda no cliente, então um cliente modificado pode chamá-lo por qualquer pessoa. Coloque a regra no 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)

A verificação de trabalho depende de seu framework. Em ESX leia o trabalho do objeto jogador, em QBCore e QBox leia dos dados do jogador. Use o getter de seu framework na etapa 1 e compare com o nome de seu mechanic job, como coberto em adding a job on ESX e adding a job on QBCore. Para o padrão de callback entre frameworks, veja server callbacks.

Outras coisas que valem a pena controlar:

• Kits de reparo como itens, para que um reparo custe algo e o item seja removido no servidor.
• Zonas de oficina, então a sintonização só se abre dentro de uma garagem ou em um banco.
• Pagando o mecânico ou a conta da sociedade no servidor, não do cliente.

Uma barra de progresso com opção de cancelamento faz os reparos parecerem certos. Veja progress bars on ESX, QBCore and ox_lib.

#Lista de verificação