Métier mécanicien FiveM : natives de réparation, mods de tuning et vérifications de travail

Le symptôme : votre mécanicien répare une voiture et le moteur fume encore, les bosses restent, une pièce accordée disparaît après un redémarrage, ou n'importe quel joueur peut réparer les véhicules gratuitement.

Un métier mécanicien est deux métiers en un : la réparation (valeurs de santé et natives) et le tuning (mods de véhicule). Les deux s'exécutent sur le client, donc la partie que vous devez protéger est qui est autorisé à les déclencher.

#Réparer un véhicule

Une native ne suffit pas pour une réparation propre. Cette combinaison fait le travail :

-- 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 répare le véhicule en général, y compris les pneus.
• SetVehicleDeformationFixed supprime les bosses que la première native peut laisser derrière.
• SetVehicleEngineHealth et SetVehicleBodyHealth prennent une valeur jusqu'à 1000.0. Sous zéro le moteur est mort, donc les réinitialiser le fait redémarrer.

Parce qu'un véhicule est une entité en réseau, le client qui répare devrait en être propriétaire. Si la réparation fonctionne sur votre propre voiture et non sur celle d'un client, demandez d'abord le contrôle :

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

Pour les réparations partielles (moteur uniquement, carrosserie uniquement), appelez simplement la native de santé correspondante. Les valeurs de santé sont également importantes pour d'autres scripts, par exemple dégâts du véhicule et santé du moteur explique ce que fait chaque nombre.

#Tuning avec SetVehicleMod

Les mods sont des emplacements numérotés. Deux règles s'appliquent à tous :

1. Appelez SetVehicleModKit(vehicle, 0) avant tout changement de mod.
2. Demandez au jeu combien d'options un emplacement a avec GetNumVehicleMods. Un indice de -1 est la pièce d'origine.

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

Vérifier l'indice par rapport à GetNumVehicleMods évite un échec silencieux quand un véhicule a moins d'options que vous l'attendez. La peinture et les couleurs utilisent leurs propres natives (SetVehicleColours et autres), alors traitez-les comme un menu séparé.

Conseil : construisez le menu de tuning à partir du véhicule lui-même, en boucle sur les emplacements avec GetNumVehicleMods, plutôt que de coder les nombres en dur. Les véhicules d'add-on ont souvent un nombre d'options différent.

#Enregistrer les mods

Définir un mod change uniquement l'entité en direct. Quand le joueur range la voiture dans le garage et la sort à nouveau, le mod est parti sauf s'il a été enregistré avec le véhicule. Enregistrez l'ensemble complet des propriétés après le tuning et appliquez-les quand le véhicule apparaît. Le flux complet est dans enregistrement des propriétés du véhicule et des mods.

#Actions limitées par travail

Le code de réparation et de tuning s'exécute sur le client, donc un client modifié peut l'appeler pour n'importe qui. Mettez la règle sur le serveur :

-- 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 vérification du travail dépend de votre framework. Sur ESX lisez le travail à partir de l'objet joueur, sur QBCore et QBox lisez-le à partir des données du joueur. Utilisez le getter de votre framework à l'étape 1 et comparez-le avec votre nom de travail mécanicien, comme couvert dans ajouter un travail sur ESX et ajouter un travail sur QBCore. Pour le modèle de rappel sur les frameworks, voir callbacks serveur.

D'autres choses utiles à limiter :

• Kits de réparation comme éléments, de sorte qu'une réparation coûte quelque chose et que l'article est supprimé sur le serveur.
• Zones d'atelier, afin que le tuning ne s'ouvre qu'à l'intérieur d'un garage ou sur un établi.
• Payer le mécanicien ou le compte de la société sur le serveur, pas depuis le client.

Une barre de progression avec une option d'annulation rend les réparations bonnes. Consultez barres de progression sur ESX, QBCore et ox_lib.

#Liste de contrôle