Guide du créateur de métiers FiveM : configuration, dépendances et tests

Un créateur de métiers FiveM permet au personnel autorisé de définir des métiers sans écrire chaque interaction à la main, mais l'installation dépend toujours du framework exact, de l'inventaire, du ciblage, de la base de données et des versions UI utilisés par votre serveur. Vérifiez d’abord ces exigences de compatibilité, installez les dépendances déclarées, limitez l’accès au créateur, créez un petit métier de test et vérifiez le parcours complet du joueur avant de configurer tout un service.

Vérifiez la compatibilité avant l'installation

Commencez sur la page produit du créateur de métiers FiveM et comparez ses exigences actuelles avec votre serveur. Si vous êtes toujours en train de choisir une approche, la collection de scripts de métiers FiveM propose des alternatives aux serveurs qui ont besoin d’un métier prêt à l’emploi plutôt que d’un créateur en jeu.

• Framework : identifier la branche et la version exactes de ESX, QBCore, Qbox ou autonome en cours d'utilisation.
• Base de données: confirmer le pont de base de données pris en charge et si une importation ou une migration de schéma est requise.
• Inventaire et ciblage : vérifier l'intégration nommée, pas seulement un nom de produit similaire.
• Bibliothèques UI : installer uniquement les versions déclarées par le package.
• Autorisations : déterminez quel ACE, groupe de framework ou identifiant peut ouvrir le créateur.

« Prend en charge FiveM » n'est pas une déclaration de compatibilité. Un créateur peut démarrer avec succès tandis que les grades de métier, les éléments d'inventaire ou les zones cibles échouent parce qu'un adaptateur ne correspond pas au serveur.

Installer la ressource dans un ordre contrôlé

1. Sauvegarder la base de données, server.cfg et la configuration actuelle des métiers.
2. Extraire le package en dehors du répertoire des ressources actives et lire son manifeste et ses notes d'installation.
3. Installer chaque dépendance déclarée et la démarrer dans l'ordre documenté.
4. Importer SQL uniquement lorsque la version correspondante du package le fournit.
5. Placer le dossier de ressources contenant fxmanifest.lua sous resources.
6. Ajoutez son nom de ressource exact à server.cfg, puis démarrez-le en staging.

Ne renommez pas les dossiers de ressources à moins que le fournisseur ne le prenne explicitement en charge. D'autres ressources peuvent référencer une exportation par le nom de ressource d'origine. De même, ne copiez pas de SQL aléatoires d'un ancien tutoriel dans une base de données actuelle.

Verrouillez le créateur avant de l'utiliser

Un créateur de métiers modifie l'autorité du serveur, l'économie et l'accès. Son menu ne doit jamais être disponible pour tous les clients connectés. Configurez la méthode de permission documentée, puis testez avec deux comptes : un autorisé et un joueur ordinaire. Le compte non autorisé doit échouer côté serveur, et non pas simplement avoir son bouton de menu masqué.

Gardez les secrets et les décisions de confiance dans les fichiers du serveur. Le code client peut être inspecté et les événements client peuvent être tentés par un client modifié. Chaque action qui crée des grades, paie de l'argent, accorde des objets ou modifie des données de métier partagées nécessite une autorisation côté serveur et une validation des entrées dans la ressource elle-même.

Créez un métier de test minimal

Utilisez un nom jetable tel que qa_delivery plutôt que de commencer par modifier un métier important de la police ou des services médicaux. Configurez uniquement les champs réellement proposés par la ressource :

Zone	Ce qu'il faut vérifier
Identité du métier	Nom interne unique, libellé visible par le joueur et enregistrement du métier dans le framework
Grades	Ordre, étiquettes, valeurs de rémunération et toute capacité de chef
Prise de service	Comment un joueur commence et termine le travail ; si l'état survit aux reconnexions
Emplacements	Coordonnées, rayon d'interaction, comportement du marqueur/de la cible et règles d'accès
Objets	Noms d'objets d'inventaire existants, quantités et comportement en cas d'échec de capacité
Véhicules	Noms de modèles existants, dégagement d'apparition, stockage et comportement de retour
Récompenses	Montant faisant autorité sur le serveur, temps de recharge et protection contre les abus répétés

Testez le flux de travail complet du joueur

1. Attribuez le métier de test en suivant la procédure d’administration prévue.
2. Reconnectez-vous et vérifiez que le framework reconnaît toujours le métier et le grade.
3. Prenez votre service, commencez la première tâche et terminez-la normalement.
4. Essayez la même interaction en étant hors service ou avec un métier qui ne dispose pas de l’accès requis.
5. Remplissez l'inventaire, bloquez l'apparition du véhicule et interrompez la tâche à mi-chemin.
6. Redémarrez la ressource Job Creator et répétez les actions critiques.
7. Vérifiez les journaux du serveur et de F8 pour les erreurs, pas seulement les notifications visibles.

Les cas d'échec sont importants. Une récompense ne doit pas être accordée deux fois après une reconnexion, un inventaire plein ne doit pas détruire un objet silencieusement, et un spawn bloqué ne doit pas laisser un état de métier irrécupérable. Le comportement exact dépend de la ressource installée ; enregistrez ce que fait votre version.

Problèmes de configuration courants

Problème	Contrat probable à inspecter
Le menu ne s'ouvre pas	Méthode de permission, raccourci clavier, nom de commande, dépendance UI et erreurs client
Le métier existe, mais les joueurs ne peuvent pas l’utiliser	Enregistrements des métiers et grades du framework, état de service et données des joueurs mises en cache
Les objets sont manquants	Noms exacts des objets d'inventaire et adaptateur d'inventaire pris en charge
Les zones cibles ne font rien	Version de la ressource de ciblage, configuration de la zone et ordre de démarrage de la ressource
Les récompenses sont dupliquées	Validation des événements du serveur, persistance du temps de recharge/état et comportement de reconnexion
Les modifications disparaissent après le redémarrage	Connexion à la base de données, autorisations d'écriture et mécanisme de sauvegarde de la ressource

Mettre à jour sans perdre les métiers

Exportez ou sauvegardez les données du créateur avant de remplacer les fichiers. Comparez les clés de configuration au lieu d'écraser la configuration actuelle. Si la version inclut une migration, exécutez-la sur une base de données de staging restaurée et confirmez les jobs, grades et emplacements existants avant la production. Conservez le dossier de ressources précédent et le dump de la base de données jusqu'à ce que la nouvelle version survive à un redémarrage et à un test de flux de joueurs.

Un Job Creator réduit la configuration répétitive uniquement après que ses intégrations sont stables. Le support du framework, les permissions et les vérifications de récompense faisant autorité sur le serveur restent la base ; l'éditeur en jeu ne peut pas compenser une dépendance non concordante.