Lavoro FiveM meccanico: nativi di riparazione, tuning mod e controlli lavoro

Il sintomo: il tuo meccanico ripara un'auto e il motore ancora fuma, i danni rimangono, una parte sintonizzata scompare dopo un riavvio, o qualsiasi giocatore può riparare i veicoli gratuitamente.

Un lavoro meccanico è due lavori in uno: riparazione (valori di salute e nativi) e tuning (mod dei veicoli). Entrambi vengono eseguiti sul client, quindi la parte che devi proteggere è chi è autorizzato a attivarli.

#Riparazione di un veicolo

Un nativo non è sufficiente per una riparazione pulita. Questa combinazione fa il lavoro:

-- 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 ripara il veicolo in generale, compresi gli pneumatici.
• SetVehicleDeformationFixed rimuove i danni che il primo nativo può lasciare.
• SetVehicleEngineHealth e SetVehicleBodyHealth prendono un valore fino a 1000.0. Sotto zero il motore è morto, quindi ripristinarli lo fa riavviare.

Poiché un veicolo è un'entità in rete, il client che fa la riparazione dovrebbe possederlo. Se la riparazione funziona sulla tua auto e non su quella di un cliente, richiedi il controllo prima:

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

Per riparazioni parziali (solo motore, solo corpo), chiama solo il nativo di salute corrispondente. I valori di salute sono importanti anche per altri script, ad esempio danno veicolo e salute motore spiega cosa fa ogni numero.

#Tuning con SetVehicleMod

I mod sono slot numerati. Due regole si applicano a tutti:

1. Chiama SetVehicleModKit(vehicle, 0) prima di qualsiasi cambio mod.
2. Chiedi al gioco quante opzioni ha uno slot con GetNumVehicleMods. Un indice di -1 è la parte stock.

-- 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)

Controllare l'indice rispetto a GetNumVehicleMods evita un fallimento silenzioso quando un veicolo ha meno opzioni di quanto ti aspetti. Vernice e colore usano i loro nativi (SetVehicleColours e altri), quindi trattali come un menu separato.

Suggerimento: costruisci il menu di tuning dal veicolo stesso, facendo un loop sui slot con GetNumVehicleMods, piuttosto che hardcodificare i numeri. I veicoli add-on spesso hanno un numero diverso di opzioni.

#Salvataggio dei mod

Impostare un mod cambia solo l'entità live. Quando il giocatore ripone l'auto in garage e la ritira, il mod è andato a meno che non sia stato salvato con il veicolo. Salva l'intero set di proprietà dopo il tuning e applicale quando il veicolo appare. L'intero flusso è in salvataggio delle proprietà del veicolo e dei mod.

#Azioni controllate per lavoro

Il codice di riparazione e tuning viene eseguito sul client, quindi un client modificato può chiamarlo per chiunque. Metti la regola sul server:

-- 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)

Il controllo del lavoro dipende dal tuo framework. Su ESX leggi il lavoro dall'oggetto giocatore, su QBCore e QBox leggilo dai dati del giocatore. Usa il getter del tuo framework nel passaggio 1 e confrontalo con il nome del tuo lavoro meccanico, come descritto in aggiunta di un lavoro su ESX e aggiunta di un lavoro su QBCore. Per il pattern di callback tra i framework, vedi server callback.

Altre cose degne di controllo:

• Kit di riparazione come elementi, in modo che una riparazione costi qualcosa e l'elemento sia rimosso sul server.
• Zone workshop, quindi il tuning si apre solo dentro un garage o a un banco di lavoro.
• Pagare il meccanico o l'account della società sul server, non dal client.

Una barra di avanzamento con un'opzione di annullamento rende le riparazioni appropriate. Vedi barre di avanzamento su ESX, QBCore e ox_lib.

#Elenco di controllo