Passer de GCPhone ou Quasar à LB Phone : plan de migration

Avant de commencer : il n’existe pas de convertisseur officiel

Changer de téléphone mérite une vraie préparation, car un téléphone contient des numéros, des contacts, des messages et les liens vers vos scripts d’inventaire, de banque et de job. Un point d’emblée : ni la documentation de LB Phone ni nos guides ne décrivent d’outil qui copie les données de GCPhone ou de Quasar Smartphone dans LB Phone. Le guide d’installation officiel décrit une installation neuve, pas une importation de données.

Il reste donc deux options honnêtes : un nouveau départ clairement annoncé, ou une conversion sur mesure que vous développez ou que vous payez. Ce guide couvre le plan pour les deux. Ne présentez pas le changement à vos joueurs comme sans perte tant que des enregistrements représentatifs et leurs relations n’ont pas été vérifiés.

Étape 1 : décider ce que vous voulez garder

Faites une liste par type de données : numéros de téléphone, contacts, messages, historique d’appels, photos et comptes de réseaux sociaux. Pour chacun, décidez s’il est transféré, recréé ou repart de zéro. Exigez un plan de conversion pour chaque type de données à conserver, y compris pour les personnages hors ligne et les téléphones uniques.

Trois décisions déterminent toute la migration :

• À qui appartient un numéro : au personnage ou à l’item de téléphone ? La fonction de téléphones uniques de LB Phone donne à chaque item de téléphone son propre numéro et nécessite un inventaire qui gère les métadonnées.
• Comment résoudre les collisions de numéros, par exemple quand deux personnages se retrouvent avec le même numéro.
• Si les URL des photos et pièces jointes restent accessibles. LB Phone utilise sa propre méthode d’upload, Fivemanage par défaut.

Un nouveau départ est le choix le plus simple. Si vos joueurs tiennent surtout à leurs contacts, les recréer peut être un compromis (voir l’étape 6).

Étape 2 : sauvegarder la base de données et l’ancien téléphone

LB Scripts demande de toujours faire une sauvegarde avant de modifier la base de données. Sauvegardez deux choses :

1. La base de données. Le guide LB montre l’export avec HeidiSQL : clic droit sur la base, "Export database as SQL", cases "Create" cochées et cases "Drop" décochées, puis choix d’un nom de fichier. Pour une sauvegarde de migration complète, vérifiez que l’export contient les données en plus de la structure.
2. L’ancienne ressource de téléphone et sa configuration, par exemple en ZIP. Gardez une copie de retour arrière de l’ancienne ressource et de ses données. Pour Quasar, sauvegardez aussi la configuration actuelle du téléphone.

Étape 3 : monter un serveur de test à partir de la sauvegarde

Ne lancez jamais la migration d’abord sur votre ville en production. Restaurez la sauvegarde dans une base séparée et faites tourner une copie de votre serveur dessus. Toutes les étapes suivantes se font sur ce serveur de test jusqu’à l’étape 9.

Étape 4 : vérifier quelles tables LB Phone supprimerait

C’est l’étape qui décide si les données survivent. Avant d’exécuter le fichier SQL de LB Phone, le guide officiel demande de supprimer toutes les tables qui commencent par phone_. Sur un serveur neuf, aucun problème. Sur un serveur avec un ancien téléphone, cela peut effacer son historique.

Depuis GCPhone / Re-Ignited

Le base.sql de GCPhone ajoute une colonne phone_number à la table users et crée phone_app_chat, phone_calls, phone_messages et phone_users_contacts. Le base.sql de Re-Ignited crée les mêmes quatre tables. Les quatre commencent par phone_, donc l’étape d’installation de LB Phone effacerait les contacts, messages, appels et discussions de GCPhone. La colonne phone_number de users et les tables séparées twitter_* de twitter.sql ne correspondent pas au préfixe.

Donc : exportez ces quatre tables (et users.phone_number) avant l’installation de LB, ou renommez-les sur le serveur de test avec un préfixe comme old_phone_, pour pouvoir encore les lire à l’étape 6. Notez l’édition que vous utilisez, car Re-Ignited fournit des archives séparées pour ESX 1.1 et ESX 1.2.

Depuis Quasar Smartphone

Vérifiez d’abord votre édition. La gamme actuelle, Smartphone 2026 ou V3, préfixe toutes ses tables avec qs_phone_ : elles ne sont donc pas concernées par la règle phone_ de LB Phone. Ne supprimez que les tables qui commencent exactement par phone_, et vérifiez chaque correspondance avant de la supprimer.

L’ancienne gamme Smartphone PRO est différente. La fiche RPScripts de QS Smartphone (Legacy 1.7.96) indique que ses fichiers esx.sql et qb.sql suppriment puis recréent les tables du téléphone. Ouvrez le fichier SQL que vous avez installé et listez ses noms de tables avant de supprimer quoi que ce soit. Les applications, adaptateurs vocaux et add-ons d’une édition Quasar ne font pas automatiquement partie d’une autre, et les applications DLC gratuites de Quasar nécessitent le téléphone de base Quasar : elles ne passeront donc pas sur LB Phone.

Étape 5 : installer LB Phone sur le serveur de test

Retirez ou arrêtez d’abord l’ancien téléphone. Le guide de Quasar demande de retirer tout autre téléphone avant d’en installer un, en citant notamment lb-phone, car ces téléphones utilisent le même item, les mêmes touches et les mêmes événements, et en faire tourner deux en même temps provoque des erreurs et des appels coupés. C’est aussi vrai dans l’autre sens. Arrêtez l’ancien téléphone au lieu de supprimer ses fichiers, pour pouvoir revenir en arrière.

Suivez ensuite le guide d’installation officiel de LB :

• MariaDB 10.11 ou plus récent, oxmysql, des artifacts serveur à jour, loaf_bcrypt recommandé.
• Après vos vérifications de l’étape 4, supprimer les tables phone_ et exécuter lb-phone/phone.sql avec HeidiSQL.
• Démarrer votre framework, oxmysql et votre inventaire avant le téléphone. La page produit donne ensure oxmysql, ensure lb-phoneprop, ensure lb-phone.
• Régler la méthode d’upload dans config.lua et les clés dans lb-phone/server/apiKeys.lua.

Si vous utilisez des téléphones uniques, configurez l’item phone dans votre inventaire comme le décrit le guide LB des téléphones uniques ; sur ox_inventory, cela inclut le retrait du bloc d’intégration NPWD pour Item('phone'.

Étape 6 : transférer ou recréer les données, puis les comparer

Il n’existe pas d’importateur documenté : toute donnée conservée demande une étape sur mesure. LB Phone documente en revanche des exports serveur utilisables par un développeur. Par exemple, AddContact ajoute un contact à un numéro donné, et SendMessage envoie un message entre deux numéros. Un développeur peut lire l’ancienne table de contacts de l’étape 4 et recréer les contacts via AddContact une fois que les joueurs ont leurs nouveaux numéros LB. Il s’agit d’un script sur mesure, pas d’un outil de migration officiel, et nos sources ne précisent pas si les anciens numéros peuvent être conservés.

Avant de vous fier au résultat, comparez les données :

• Comptez les enregistrements par type de données avant et après, par exemple les contacts par personnage.
• Vérifiez des enregistrements représentatifs et leurs relations à la main : le bon contact sur le bon numéro, pour un personnage en ligne et un personnage hors ligne.
• Cherchez les doublons et les collisions de numéros.
• Vérifiez les anciens liens de photos. Les URL de pièces jointes enregistrées peuvent ne plus être accessibles après le changement.

Étape 7 : adapter les scripts qui appelaient l’ancien téléphone

Les alertes de job, le dispatch ou les scripts de garage appellent souvent l’ancien téléphone via des exports ou des événements. Une fois ce téléphone retiré, ces appels échouent ; "No such export" signifie que la ressource appelée n’est pas démarrée ou porte un autre nom. La documentation LB liste les exports et événements propres à LB Phone, par exemple SendMessage, SendNotification et EmergencyNotification. Elle ne documente pas d’alias pour les exports de gcPhone ou de Quasar : chaque script qui appelait l’ancien téléphone doit donc être adapté aux exports de LB Phone. Re-Ignited démarre gcphone avant les ressources de job, ce qui indique bien quels scripts en dépendent.

Étape 8 : tester avec deux personnages

Testez avec deux personnages ordinaires sur le serveur de test : appels dans les deux sens, messages et pièces jointes après un redémarrage, remise d’un téléphone unique, virements bancaires et applications de job. Testez les reconnexions, les numéros en double et les alertes de job avant de remplacer le téléphone en production. Si les appels vidéo n’affichent personne, mettez en place un serveur TURN ; LB Phone prend en charge Cloudflare nativement.

Étape 9 : basculer le serveur en production

Ne basculez qu’une fois les étapes 6 à 8 validées. Un ordre raisonnable :

1. Prévenez vos joueurs à l’avance de ce qui est transféré et de ce qui ne l’est pas, surtout si leur historique de téléphone ne suit pas.
2. Arrêtez le serveur et faites une nouvelle sauvegarde comme à l’étape 2.
3. Exécutez exactement les étapes qui ont fonctionné sur le serveur de test, dans le même ordre : protéger ou exporter les anciennes tables, installer LB Phone, lancer votre script de conversion si vous en avez un.
4. Démarrez le serveur et refaites une version courte des tests de l’étape 8.

Vous préparez le changement ? Obtenez LB Phone v2 sur RPScripts et testez-le d’abord sur votre serveur de staging.

Étape 10 : garder un plan de retour arrière

Conservez la copie de retour arrière de l’ancienne ressource de téléphone et de ses données jusqu’à être sûr de ne plus en avoir besoin. Rédigez le retour arrière avant le jour J : arrêter le serveur, restaurer la sauvegarde de la base de l’étape 9, remettre les lignes ensure sur l’ancien téléphone et restaurer les scripts de job modifiés à l’étape 7. Testez aussi ce retour arrière une fois sur le serveur de test, pour savoir qu’il fonctionne.

FAQ

Existe-t-il un outil officiel pour transférer les données de GCPhone ou de Quasar vers LB Phone ?

Ni dans la documentation de LB Phone, ni sur RPScripts. Les options sont une conversion sur mesure ou un nouveau départ.

L’installation de LB Phone va-t-elle supprimer mes données GCPhone ?

C’est possible. Le guide LB demande de supprimer toutes les tables phone_ avant d’exécuter le fichier SQL, et les tables de contacts, messages, appels et discussions de gcPhone commencent toutes par phone_. Sauvegardez-les et exportez-les d’abord.

Va-t-elle supprimer mes données Quasar Smartphone V3 ?

Les tables V3 commencent par qs_phone_ et ne sont donc pas concernées par la règle phone_. Sauvegardez quand même d’abord et vérifiez chaque table avant de la supprimer.

Puis-je garder l’ancien téléphone à côté de LB Phone ?

Non. Selon le guide de Quasar, faire tourner deux téléphones en même temps provoque des erreurs et des appels coupés. Arrêtez l’ancien téléphone, mais gardez ses fichiers et ses données pour un retour arrière.

Puis-je recréer les contacts automatiquement ?

Un développeur peut utiliser l’export documenté AddContact de LB Phone dans un script sur mesure. Ce n’est pas un outil de migration officiel.

Pour ce choix de téléphone, comparez les Scripts de téléphone : LB Phone v2 figure dans la sélection actuelle pour plusieurs frameworks, GKSPhone (ESX) est précisément l’ancien paquet ESX 1.1/1.2 (1.2 FIX 5), et CodeM Phone (mPhone 2.0) demande une vérification des dépendances du paquet. La documentation actuelle de GKSPHONE V2 décrit un autre produit que le téléchargement GKSPhone lié ici. Aucun n’a fait ses preuves pour une reprise sans perte de vos données de téléphone. RPScripts vend ces paquets.