Aller au contenu
RPScripts

Testeur de scripts FiveM

Importez une ressource et voyez ce qui cloche avant qu'elle n'atteigne votre serveur : manifeste, Lua, API des frameworks et sécurité des événements, plus un bac à sable CfxLua qui exécute ses événements, threads, exports et callbacks NUI. Votre code reste dans votre navigateur.

Déposez le ZIP d'une ressource ici

Un dossier de ressource FiveM en .zip (5 Mo max), un seul fichier .lua, ou du code collé. Rien n'est envoyé : l'analyse et la simulation s'exécutent dans cet onglet.

Les vérifications statiques et la simulation CfxLua s'exécutent localement dans un Web Worker. Vos fichiers ne sont envoyés à RPScripts que si vous choisissez « Ouvrir dans RPScripts AI ». Les résultats simulés ne prouvent pas qu'une ressource fonctionne sur un vrai FXServer ou dans GTA V.

Ce que le testeur vérifie

  • La syntaxe Lua, y compris les extensions CfxLua de FiveM (vecteurs, affectation composée, navigation sûre, hachages entre accents graves)
  • fxmanifest.lua : fx_version, game, scripts et globs qui ne correspondent à aucun fichier, fichiers NUI non envoyés, lua54, initialisation d'ox_lib, dépendances
  • Les appels à QBCore, Qbox, ESX, ox_lib, ox_inventory et ox_target par rapport à des versions amont figées, y compris le côté client/serveur
  • Les natives inexistantes ou n'existant que de l'autre côté, d'après les typages publiés par Cfx.re
  • Événements réseau gérés sans RegisterNetEvent, callbacks jamais enregistrés, exports propres jamais définis
  • Événements serveur qui font confiance aux valeurs du client pour l'argent, les objets ou les métiers, actions privilégiées sans contrôle de permission, source utilisé après Wait
  • Boucles infinies sans Wait et gestionnaires de démarrage/arrêt qui s'exécutent pour chaque ressource

Ce qui s'exécute, ce qui est simulé, ce qui nécessite un vrai serveur

Exécuté pour de vrai : votre Lua sur CfxLua 5.4 compilé en WebAssembly, avec l'ordonnanceur de FiveM (CreateThread, Wait, SetTimeout), les événements, msgpack et json, le démarrage et l'arrêt des ressources.

Simulé par RPScripts : un serveur et un client par joueur, TriggerServerEvent/TriggerClientEvent avec source, exports entre ressources, state bags, callbacks NUI, commandes avec aces, KVP de ressource, et doublures de test de QBCore, Qbox, ESX, ox_lib, ox_inventory, ox_target, qb-target et oxmysql.

Nécessite un vrai serveur : natives du jeu (entités, véhicules, peds, monde), OneSync, la base de données, les vraies données des frameworks et les scripts JavaScript ou C#. Quand le code les appelle, le résultat indique « partiel » et liste les appels.

Exemples concrets

Un événement d'achat qui fait confiance au client

RegisterNetEvent('shop:buy', function(item, price)
    local src = source
    local Player = QBCore.Functions.GetPlayer(src)
    if not Player or not Items[item] then return end
    if Player.Functions.RemoveMoney('cash', price, 'shop') then
        Player.Functions.AddItem(item, 1)
        TriggerClientEvent('shop:bought', src, item)
    end
end)

Le prix vient du client : n'importe quel joueur peut donc acheter pour rien, ou envoyer un remboursement de n'importe quel montant. L'analyseur signale ce schéma (LAB-SEC-001) ; le scénario de charges utiles hostiles envoie ensuite des événements forgés en tant que joueur sans métier et montre l'argent distribué par le serveur.

Correctif : chercher le prix côté serveur (Items[item].price) et ignorer ce que le client envoie.

Un événement que FiveM ignore sans rien dire

-- client.lua
TriggerServerEvent('shop:sell', 'bread')

-- server.lua
AddEventHandler('shop:sell', function(item) … end) -- LAB-EVT-001

Le client le déclenche avec TriggerServerEvent, mais le serveur n'utilise que AddEventHandler. FiveM l'ignore avec « was not safe for net » ; la simulation affiche la même ligne dans la trace, et LAB-EVT-001 pointe vers le gestionnaire.

Une boucle qui fige le client

CreateThread(function()
    while true do -- LAB-SCH-001
        if open then DisableControlAction(0, 1, true) end
    end
end)

while true do … end sans Wait ne rend jamais la main. LAB-SCH-001 signale la boucle et, dans le bac à sable, le watchdog arrête le thread avec « missing Wait in a loop? » au lieu de figer votre navigateur.

FAQ

Ai-je besoin de GTA V ou d'un serveur FiveM pour tester un script ?
Non. Le testeur analyse et vérifie la ressource, puis exécute son Lua dans un bac à sable CfxLua dans votre navigateur. Pour tout ce qui dépend du monde du jeu ou d'une vraie base de données, le rapport indique précisément ce qui nécessite encore un vrai serveur.
Mon code est-il envoyé ?
Non. L'analyse et la simulation s'exécutent dans un Web Worker de votre navigateur. Seul « Ouvrir dans RPScripts AI » envoie les fichiers vers votre compte RPScripts, et uniquement après connexion.
Un test réussi signifie-t-il que le script fonctionne sur mon serveur ?
Cela signifie que le comportement simulé a réussi. C'est un indice fort pour le câblage des événements, les contrôles de sécurité et les erreurs Lua, mais pas une garantie pour les natives du jeu, OneSync ou votre version exacte du framework.
Quels frameworks sont pris en charge ?
QBCore, Qbox et ESX, ainsi que ox_lib, ox_inventory, ox_target, qb-target et oxmysql. Les vérifications statiques utilisent leurs API amont figées ; le bac à sable charge des doublures de test clairement identifiées qui listent ce qu'elles implémentent.
Peut-il corriger les erreurs ?
Ouvrez la ressource dans RPScripts AI : elle reçoit les constats et les résultats de tests, propose une modification que vous pouvez relire sous forme de diff, l'enregistre comme nouvelle version, et le Lab relance les vérifications et les scénarios.

Corrigez ce que le testeur a trouvé

Ouvrez la ressource dans RPScripts AI pour corriger les constats avec un diff relisible, relancer les tests et télécharger le résultat, ou vérifiez un manifeste avec le générateur de fxmanifest.

Le bac à sable exécute le CfxLua de FiveM via FiveLab (MIT), figé à une révision examinée.

Autres outils gratuits

Tous les outils gratuits →