ESX Legacy est un framework de jeu de rôle open source pour FiveM. Pour un nouveau serveur, utilisez le modèle officiel ESX Legacy dans txAdmin ou suivez toute la documentation d’installation officielle. Installer uniquement le dossier es_extended ne constitue pas une installation complète du serveur : l’ensemble pris en charge comprend des opérations sur la base de données, des ressources nécessaires et une configuration ordonnée du démarrage.
Points clés
- Utilisez la recette officielle ESX Legacy txAdmin pour une nouvelle installation.
es_extendedest la base fondamentale, pas tout le serveur de jeu de rôle.- Le chemin manuel documenté inclut oxmysql, spawnmanager, SQL, exclusions et ordre des ressources.
- Avant une mise à jour, identifiez la version exacte ESX ou fork et sauvegardez à la fois la base de données et les ressources.
- Vérifiez chaque script tiers contre le framework, l'inventaire, la bibliothèque de base de données, les événements, les exports et les dépendances actuels.
Ce que fournit ESX Legacy
ESX fournit une base de framework pour les données de joueurs et de personnages et pour les ressources qui s'intègrent avec ses API et conventions. Les métiers, l'inventaire, le logement, la banque, les téléphones et autres systèmes de gameplay sont des ressources séparées ou des parties d'une recette sélectionnée. Leur présence et leur comportement dépendent de la pile réelle, pas seulement du fait que es_extended est installé.
Le dépôt officiel du cœur d’ESX est la source à utiliser pour le code actuel du cœur. Son manifeste es_extended déclare oxmysql comme dépendance. Utilisez la documentation officielle et l’historique des versions pour identifier votre installation ; évitez les paquets quelconques présentés simplement comme le dernier ZIP d’ESX.
Installer un nouveau serveur ESX avec txAdmin
Le tutoriel officiel du serveur utilise le déployeur de recettes txAdmin intégré à FXServer. Sélectionnez le modèle ESX Legacy et complétez la configuration guidée actuelle plutôt que de copier un dossier principal dans un répertoire de ressources autrement vide.
- Préparez un environnement FXServer actuel et ouvrez le flux de configuration de txAdmin.
- Créez un nouveau déploiement à partir de la recette officielle ESX Legacy.
- Fournissez la clé de serveur et les paramètres de base de données documentés.
- Permettez à la recette de déployer la base de données et les ressources requises.
- Examinez la configuration générée, les autorisations et l'ordre des ressources.
- Démarrez le serveur de test et vérifiez la création de personnages, la persistance, les métiers, les permissions et les journaux.
Gardez les informations d'identification hors des fichiers partagés et des captures d'écran. Après le déploiement, enregistrez les versions exactes du dépôt ou des versions de publication afin que les vérifications de compatibilité ultérieures soient basées sur des preuves plutôt que sur une étiquette générique ESX.
Utilisez le chemin d'installation manuel uniquement si nécessaire
La documentation officielle d’installation manuelle définit le périmètre complet. Elle couvre les exigences relatives à oxmysql et spawnmanager, l’importation de legacy.sql, l’ensemble des ressources principales et additionnelles, les exclusions et l’ordre de démarrage requis. Suivez cette page comme une procédure actuelle et complète. Ne la réduisez pas au déplacement de es_extended, à la modification d’un fichier de configuration et à l’ajout d’une ligne ensure.
| Zone d'installation | Preuves à conserver |
|---|---|
| Noyau et modules complémentaires | Dépôt, étiquette ou commit exact pour chaque ressource ESX. |
| Base de données | Configuration de connexion, SQL importé et sauvegarde pré-changement. |
| Dépendances | oxmysql, spawnmanager et toutes les bibliothèques spécifiques aux ressources. |
| Ordre | Les commandes ensure documentées et toute exclusion délibérée. |
| Vérification | Journaux de démarrage, persistance des personnages et vérifications des permissions. |
Mettre à jour un serveur ESX existant en toute sécurité
Identifiez d'abord si le serveur exécute la version actuelle de ESX Legacy, une version plus ancienne ou une bifurcation avec des modifications de noyau personnalisées. Enregistrez le schéma de base de données actuel, les versions des ressources et les modifications locales. Créez une sauvegarde de la base de données restaurable et une capture instantanée des ressources/configuration avant de remplacer quoi que ce soit.
Lisez les notes de migration et de publication entre la version déployée et la version cible. Testez la mise à niveau complète sur le serveur de staging avec des données de production représentatives. Une mise à jour du noyau peut affecter les exports, les événements, les données des joueurs, les tables de la base de données, les intégrations d'inventaire et les scripts dépendants. Validez les reconnexions et les redémarrages ainsi qu'un nouveau personnage.
- Comparez les schémas et les migrations SQL avant de les importer.
- Résolvez les modifications de cœur personnalisées explicitement au lieu de les écraser silencieusement.
- Vérifiez les changements d’exports, d’événements ou d’identifiants dans chaque ressource qui utilise le framework.
- Testez les métiers, groupes et commandes autorisés et refusés.
- Examinez les journaux client, serveur et base de données sous des actions représentatives.
- Gardez les fichiers précédents et la sauvegarde correspondante de la base de données jusqu'à ce que le déploiement soit accepté.
Choisissez un script compatible avec ESX
Lisez les informations spécifiques au produit concernant la livraison, la licence, les mises à jour et le support. Installez sur un serveur de test correspondant et testez les chemins de défaillance, y compris les rôles non autorisés et les événements répétés. Une restriction d'interface utilisateur visible ne remplace pas une validation côté serveur.
ESX, QBCore ou Qbox
Il n'y a pas de framework universellement meilleur établi par les sources officielles. ESX est souvent le choix le moins risqué lorsque les données de production, les scripts et les procédures d'équipe existants dépendent déjà d'ESX et qu'aucun avantage de migration testé ne l'emporte sur le coût de conversion. QBCore est un écosystème d'API et de ressources distinct. Qbox dispose d'un pont QB documenté, mais cela ne rend pas les ressources spécifiques à ESX automatiquement portables.
Utilisez une comparaison de frameworks basée sur les ressources requises, les connaissances de l'équipe, la migration des données, la documentation actuelle et la capacité de restauration. Lorsque vous envisagez un changement, inventoriez les identités, l'argent, les métiers, l'inventaire, les véhicules, le logement, les téléphones, les services bancaires, les permissions et les événements personnalisés avant de choisir une cible.