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é
- Sauvegarder la base de données,
server.cfget la configuration actuelle des métiers. - Extraire le package en dehors du répertoire des ressources actives et lire son manifeste et ses notes d'installation.
- Installer chaque dépendance déclarée et la démarrer dans l'ordre documenté.
- Importer SQL uniquement lorsque la version correspondante du package le fournit.
- Placer le dossier de ressources contenant
fxmanifest.luasousresources. - 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
- Attribuez le métier de test en suivant la procédure d’administration prévue.
- Reconnectez-vous et vérifiez que le framework reconnaît toujours le métier et le grade.
- Prenez votre service, commencez la première tâche et terminez-la normalement.
- Essayez la même interaction en étant hors service ou avec un métier qui ne dispose pas de l’accès requis.
- Remplissez l'inventaire, bloquez l'apparition du véhicule et interrompez la tâche à mi-chemin.
- Redémarrez la ressource Job Creator et répétez les actions critiques.
- 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.