ESX Legacy est un framework de rôle open-source FiveM. Pour un nouveau serveur, utilisez le modèle officiel ESX Legacy dans txAdmin ou suivez la documentation d'installation complète officielle. L'installation seule du es_extended le dossier n'est pas une configuration de serveur complète car la pile prise en charge inclut le travail de la base de données, les ressources requises et une configuration de démarrage ordonnée.
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, identifier la version exacte ESX ou fork et sauvegarder à 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 cadre pour les données de joueurs et de personnages et pour les ressources qui s'intègrent avec ses API et conventions. Les emplois, 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 Dépôt central ESX est la source correcte pour le code central actuel. Son es_extended le manifeste déclare oxmysql comme une dépendance. Utilisez la documentation officielle et l'historique des versions pour identifier ce que vous avez; évitez un package aléatoire annoncé uniquement comme le dernier ZIP ESX.
Installer un nouveau serveur ESX avec txAdmin
Le tutoriel de serveur officiel utilise le déployeur de recettes txAdmin fourni avec FXServer. Sélectionnez le modèle Legacy ESX 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 une nouvelle recette de déploiement en utilisant le modèle officiel 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 emplois, 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 la limite complète. Elle couvre les exigences oxmysql et spawnmanager, l'importation legacy.sql, l'ensemble des ressources principales et supplémentaires, les exclusions et l'ordre de démarrage requis. Suivez cette page comme une seule procédure actuelle. Ne la réduisez pas à un simple déplacement es_extended, en modifiant un fichier de configuration et en ajoutant un assurer ligne.
| 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. |
| Commande | Les garanties 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.
- Comparer 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 chaque ressource consciente du framework pour les exports, événements ou identifiants modifiés.
- Testez les emplois, 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
Commencez par le catalogue des scripts FiveM payants and narrow to Scripts ESX. An ESX product label is a starting filter. Confirm the expected ESX version or fork, database library, inventory, target or menu system, SQL changes, events, exports and permissions. Check whether the resource replaces an existing system or integrates with it. Two resources that both own inventory or character initialization can conflict even when each is individually marked ESX-compatible.
Lire 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 UI visible n'est pas un substitut à la validation côté serveur.
ESX, QBCore ou Qbox
Il n'y a pas de framework universel le meilleur établi par les sources officielles. ESX est souvent le choix à risque le plus faible lorsque les données de production, les scripts et les procédures de l'équipe existants dépendent déjà de 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 séparé. Qbox a un pont QB documenté, mais cela ne rend pas les ressources spécifiques à ESX automatiquement portables.
Utilisez une comparaison de cadre basée sur les ressources requises, les connaissances de l'équipe, la migration des données, la documentation actuelle et la capacité de retour en arrière. Lors de la considération d'un changement, inventoriez les identités, l'argent, les emplois, l'inventaire, les véhicules, le logement, les téléphones, la banque, les permissions et les événements personnalisés avant de choisir une cible.
Prochaines étapes sûres
- Pour une nouvelle construction, partez de la recette officielle actuelle ESX Legacy txAdmin.
- Pour un serveur existant, documentez la version exacte et la bifurcation avant de planifier une mise à jour.
- Pour une nouvelle ressource, vérifiez toutes les limites d'intégration et étagez-la avec une base de données représentative.
- Gardez les informations sur le framework et les exigences des produits commerciaux séparées, et vérifiez les deux avant l'achat.
Comparer ESX avec les autres chemins du framework
Examinez plus largement Comparaison du framework FiveM avant de migrer une base de données existante, et utilisez le Guide QBCore uniquement lorsque les scripts et le modèle de données requis justifient ce changement.
