Ottieni e imposta le proprietà dei veicoli in FiveM: lib, ESX e QBCore

Sintomi tipici:

A car comes out of the garage as a stock car: no colour, no turbo, no wheels, plain plate.

L'aspetto e il tuning di un veicolo sono chiamati le sue proprietà. Per mantenerli, li leggi da un veicolo generato, li memorizzi come JSON, e li applichi al prossimo che generi. Questo articolo mostra la funzione che ogni framework fornisce, la sola regola sul kit di modifica, e come salvare il risultato nel database.

#Cosa contengono le proprietà

Una tabella di proprietà contiene tutto ciò che il garage deve ripristinare: modello, targa, colori, livrea, mod per indice, tipo di ruota, fumo dei pneumatici, neon, tinta della finestra, extra e valori di salute. È una semplice tabella Lua, quindi la trasformi in testo con json.encode per l'archiviazione.

#ox_lib

Se ox_lib è sul tuo server, questo è il modo più breve, e l'unico di cui hai bisogno su QBox:

-- client
local vehicle = GetVehiclePedIsIn(PlayerPedId(), false)
local props = lib.getVehicleProperties(vehicle)

-- later, on a spawned vehicle
lib.setVehicleProperties(vehicle, props)

Entrambi sono funzioni client. Funzionano con qualsiasi framework perché leggono il gioco direttamente.

#ESX

ESX ha il suo coppia sul client:

local props = ESX.Game.GetVehicleProperties(vehicle)

ESX.Game.SetVehicleProperties(vehicle, props)

Ottieni prima l'oggetto con ESX = exports['es_extended']:getSharedObject(). Se ESX è nil, vedi fixing esx:getSharedObject.

#QBCore

QBCore ha le stesse due funzioni sul client:

local QBCore = exports['qb-core']:GetCoreObject()

local props = QBCore.Functions.GetVehicleProperties(vehicle)

QBCore.Functions.SetVehicleProperties(vehicle, props)

Su QBox, usa il coppia ox_lib da sopra.

Suggerimento: se scrivi uno script che deve funzionare su tutti e tre i framework, controlla quale è in esecuzione e chiama il coppia corrispondente, o usa semplicemente ox_lib ovunque poiché è già una dipendenza della maggior parte dei server moderni.

#SetVehicleModKit per primo

Il gioco ignora SetVehicleMod finché il veicolo non ha un kit di modifica impostato. Le funzioni sopra lo gestiscono, ma se scrivi il tuo codice di applicazione, fallo in questo ordine:

SetVehicleModKit(vehicle, 0)

SetVehicleMod(vehicle, 11, 3, false)   -- engine, level 3
SetVehicleMod(vehicle, 12, 2, false)   -- brakes
ToggleVehicleMod(vehicle, 18, true)    -- turbo

Il primo argomento di SetVehicleModKit è il kit, e 0 è quello che tutti usano. I tipi di mod sono numeri: 11 è il motore, 12 freni, 13 trasmissione, 15 sospensione, 16 armatura, e 18 è il turbo, che viene attivato invece di impostato. I colori, le ruote, il neon e la tinta hanno i loro nativi come SetVehicleColours, SetVehicleWheelType e SetVehicleNeonLightEnabled.

Scrivere questo a mano vale raramente la pena. È lungo, e la libreria copre già ogni caso. Usalo per un ritocco una tantum, non per un garage.

#Salva nel database

Le proprietà vengono archiviate come testo JSON in una colonna di testo lungo. Il flusso usuale è:

1. Il client legge le proprietà dal veicolo.
2. Le invia al server con la targa.
3. Il server le codifica e le salva.

-- client
local props = lib.getVehicleProperties(vehicle)
TriggerServerEvent('my_garage:saveProps', props.plate, props)

-- server
RegisterNetEvent('my_garage:saveProps', function(plate, props)
    local src = source
    -- check here that this player owns that plate before saving
    MySQL.update('UPDATE owned_vehicles SET vehicle = ? WHERE plate = ?', {
        json.encode(props), plate
    })
end)

La stessa chiamata su QBCore e QBox scrive la colonna mods di player_vehicles. I nomi delle colonne sono in l'articolo sulle tabelle del garage.

Attenzione: non fidati mai della targa e delle proprietà dal client senza controllare la proprietà sul server. Altrimenti un giocatore può sovrascrivere il veicolo di qualcun altro. Vedi securing server events.

#Ripristina quando il veicolo spawna

Leggi il JSON, decodificalo, quindi applicalo dopo che il veicolo esiste su questo client:

local row = MySQL.single.await('SELECT vehicle FROM owned_vehicles WHERE plate = ?', { plate })
local props = json.decode(row.vehicle)

-- send props to the client that owns the car, which applies:
lib.setVehicleProperties(vehicle, props)

Le regole per l'applicazione:

• Il veicolo deve esistere e essere caricato. Applica subito dopo CreateVehicle, con un'attesa su DoesEntityExist per quelli in rete. Vedi spawning vehicles.
• Il modello deve essere lo stesso. Le proprietà di un modello diverso applicano gli indici di mod sbagliati.
• Eseguilo sul client che ha il controllo del veicolo. L'applicazione da un client che non lo possiede può fallire.

#Problemi comuni

Mod perse dopo l'archiviazione. Il salvataggio è stato eseguito dopo che l'auto è stata eliminata, quindi hai salvato una tabella vuota. Leggi le proprietà per primo, quindi elimina.

La targa cambia dopo il ripristino. La targa salvata fa parte delle proprietà. Se generi con una targa e applichi proprietà con un'altra, le proprietà vincono. Assicurati che entrambi corrispondano, altrimenti le chiavi e il database smettono di corrispondere.

I colori sono sbagliati. Un colore personalizzato viene archiviato con i suoi propri valori RGB, che alcuni vecchi script non ripristinano. Usa la funzione attuale del tuo framework.

JSON troppo grande o non valido. La colonna vehicle deve essere un tipo di testo lungo, e i dati devono provenire da json.encode. Una tabella con le chiavi in una forma numerica e stringa mista può codificare come un elenco invece di un oggetto, quindi carica sempre e confronta una riga salvata quando esegui il debug.

Auto personalizzate o addon. Le parti di mod personalizzate dipendono dalla meta del modello e dal suo stream. Se una parte manca dal modello, l'indice non fa nulla. Vedi adding addon cars.

#Checklist