Migrer ESX vers QBox : ce qui est transféré, ce qui casse et une liste de contrôle

Vous exécutez un serveur ESX et vous voulez QBox. Avant de commencer, vous devez savoir une chose : rien ne se transfère par lui-même. ESX et QBox utilisent différentes tables, différents identifiants de joueur, différents systèmes d'articles et différentes API. Ce guide vous dit ce que cela signifie, comment choisir entre un wipe et une migration, ce qui a besoin d'un bridge, et vous donne une chronologie.

#Ce qui ne se transfère pas automatiquement

Vos joueurs gardent leur identifiant de licence, donc un personnage converti peut toujours être lié à la bonne personne. Le reste doit être mappé.

#Wiper ou migrer

Wiper signifie un serveur QBox frais et de nouveaux personnages. C'est plus propre et beaucoup plus rapide. Cela convient à un serveur qui est toujours petit, un serveur dont les données sont en désordre, ou un serveur qui change toute sa direction. Dites à vos joueurs clairement et tôt.

Migrer signifie convertir les données. Cela maintient la progression des joueurs, mais vous avez besoin d'un script de conversion qui lit vos tables ESX et écrit les lignes QBox. Écrivez-le pour votre propre serveur, car chaque serveur ESX a différentes tables et colonnes supplémentaires. L'argent est facile à mapper. L'argent noir, les articles personnalisés et les propriétés des véhicules nécessitent des soins. Un compromis courant consiste à migrer l'argent et les véhicules et à rendre les articles à la main.

Quel que soit votre choix, testez la conversion sur une copie de la base de données, jamais celle en direct.

#Planifiez la stack

QBox fonctionne sur une stack qui diffère d'un serveur ESX typique :

• qbx_core comme framework
• ox_lib, oxmysql, ox_inventory et ox_target

Voir installer QBox pour les détails. Si votre serveur ESX utilise déjà ox_inventory, ox_lib et ox_target, une bonne partie de la stack est la même, mais ses données vivent toujours dans les tables du framework, donc elle ne se propage pas telle quelle.

#Scripts : convertir, bridge ou remplacer

Passez en revue votre liste de resources et triez chaque script :

1. Scripts indépendants du framework (cartes, véhicules, sons, outils autonomes) : ils fonctionnent généralement.
2. Scripts qui détectent le framework (de nombreux scripts de magasin supportent ESX, QBCore et QBox) : ils fonctionnent, vérifiez leur config pour le paramètre de framework.
3. Scripts ESX uniquement : ceux-ci ont besoin de l'une de trois choses :
   • Convertissez-le vous-même. Le guide ESX vers QBCore, convertir un script ESX vers QBCore, puis convertir un script QBCore vers QBox montrent les changements.
   • Utilisez un bridge qui fournit les fonctions ESX en haut de QBox, si vous acceptez les couches qu'il ajoute.
   • Remplacez-le par un script natif QBox. Souvent le meilleur choix pour les emplois, le logement et les scripts basés sur l'inventaire.
4. Scripts d'inventaire : ce sont les plus difficiles, car les définitions d'articles et l'inventaire changent avec le framework.

Notez la liste. C'est votre estimation de travail. Faites attention particulière aux scripts qui gèrent l'argent, les articles ou les véhicules, car ils touchent les données que vous convertissez.

#Construisez d'abord un serveur de test

1. Créez un deuxième serveur avec la recette QBox (recettes txAdmin). Ne travaillez jamais sur celui en direct.
2. Copiez les cartes, les véhicules et les resources autonomes.
3. Ajoutez les scripts convertis ou remplacés un à la fois et redémarrez après chacun, pour savoir lequel casse. Voir lire une erreur de script.
4. Importez une copie de vos données ESX, exécutez le script de conversion, et vérifiez le résultat en rejoignant avec un compte de test.
5. Testez les boucles principales : rejoindre, emplois, argent, magasins, véhicules, logement.

#Chronologie liste de contrôle

Utilisez cet ordre, et laissez de l'espace pour chaque étape :

1. Décidez wiper ou migrer, et dites à votre communauté le plan et la date.
2. Listez tous vos scripts et marquez chacun comme fonctionne, convertissez, bridge ou remplacez.
3. Sauvegardez les fichiers ESX et la base de données. Voir sauvegarder votre serveur.
4. Construisez le serveur de test QBox.
5. Convertissez ou remplacez les scripts, puis écrivez et testez la conversion de données si vous migrez.
6. Testez avec de vrais joueurs si possible, dans une bêta ouverte.
7. Corrigez ce qu'ils trouvent. Cela prend plus de temps que prévu.
8. Basculez : annoncez le temps d'arrêt, prenez une dernière sauvegarde d'ESX, exécutez la conversion sur une copie fraîche des dernières données, et démarrez QBox.
9. Conservez la sauvegarde ESX pendant un certain temps, au cas où vous devriez revenir en arrière.

Conseil : ne changez rien d'autre en même temps. Un changement de framework, une nouvelle carte et une nouvelle économie ensemble rendent impossible de dire ce qui a cassé.

Si vos joueurs ont beaucoup en jeu, exécutez l'ancien et le nouveau serveur en parallèle pendant un court moment. Si vos scripts proviennent d'un magasin, vérifiez quels frameworks chacun supporte avant d'acheter de nouveaux, pour choisir des scripts qui fonctionnent aussi sur QBox.

#Liste de contrôle