Migra ESX a QBox: cosa viene trasferito, cosa si rompe e un elenco di controllo

Gestisci un server ESX e vuoi QBox. Prima di iniziare, devi sapere una cosa: nulla si trasferisce da solo. ESX e QBox usano tabelle diverse, identificatori di giocatore diversi, sistemi di articoli diversi e API diversi. Questa guida ti dice cosa significa, come scegliere tra un wipe e una migrazione, cosa ha bisogno di un bridge, e ti dà una timeline.

#Cosa non viene trasferito automaticamente

I tuoi giocatori mantengono il loro identificatore di licenza, quindi un personaggio convertito può ancora essere collegato alla persona giusta. Il resto deve essere mappato.

#Wipe o migra

Wipe significa un server QBox nuovo e caratteri nuovi. È più pulito e molto più veloce. Si adatta a un server che è ancora piccolo, un server i cui dati sono un disastro, o uno che sta cambiando la sua intera direzione. Dillo ai tuoi giocatori chiaramente e presto.

Migra significa convertire i dati. Mantiene il progresso del giocatore, ma hai bisogno di uno script di conversione che legga le tue tabelle ESX e scriva righe QBox. Scrivilo per il tuo server, perché ogni server ESX ha tabelle diverse e colonne aggiuntive. Il denaro è facile da mappare. Il denaro nero, gli articoli personalizzati e le proprietà del veicolo si prendono cura. Un compromesso comune è migrare denaro e veicoli e restituire articoli a mano.

Qualunque cosa scegli, testa la conversione su una copia del database, mai su quello live.

#Pianifica lo stack

QBox viene eseguito su uno stack che differisce da un server ESX tipico:

• qbx_core come framework
• ox_lib, oxmysql, ox_inventory e ox_target

Vedi install QBox per i dettagli. Se il tuo server ESX utilizza già ox_inventory, ox_lib e ox_target, una buona parte dello stack è la stessa, ma i suoi dati vivono ancora nelle tabelle del framework, quindi non si trasferisce come è.

#Script: converti, bridge o sostituisci

Esamina il tuo elenco di risorse e ordina ogni script:

1. Script indipendenti dal framework (mappe, veicoli, suoni, strumenti standalone): di solito funzionano solo.
2. Script che rilevano il framework (molti script di negozio supportano ESX, QBCore e QBox): funzionano, controlla la loro config per l'impostazione del framework.
3. Script solo ESX: questi hanno bisogno di una di tre cose:
   • Convertirlo tu stesso. La guida ESX a QBCore, convert an ESX script to QBCore, e poi convert a QBCore script to QBox mostra i cambiamenti.
   • Usa un bridge che fornisci le funzioni ESX in cima a QBox, se accetti i livelli che aggiunge.
   • Sostituiscilo con uno script nativo QBox. Spesso la scelta migliore per lavori, alloggi e script basati sull'inventario.
4. Script di inventario: questi sono i più difficili, perché le definizioni degli articoli e l'inventario cambiano con il framework.

Scrivi l'elenco. È la tua stima di lavoro. Presta particolare attenzione agli script che gestiscono denaro, articoli o veicoli, poiché toccano i dati che converti.

#Costruisci un server di prova per primo

1. Crea un secondo server con la ricetta QBox (txAdmin recipes). Non lavorare mai su quello live.
2. Copia le mappe, i veicoli e le risorse standalone.
3. Aggiungi i script convertiti o sostituiti uno alla volta e riavvia dopo ogni, quindi sai quale si rompe. Vedi reading a script error.
4. Importa una copia dei tuoi dati ESX, esegui lo script di conversione, e controlla il risultato unendoti con un account di test.
5. Testa i cicli principali: unione, lavori, denaro, negozi, veicoli, alloggi.

#Timeline elenco di controllo

Usa questo ordine, e lascia spazio per ogni passo:

1. Decidi wipe o migra, e dì alla tua comunità il piano e la data.
2. Elenca tutti i tuoi script e contrassegna ognuno come funziona, converti, bridge o sostituisci.
3. Backup i file ESX e il database. Vedi backup your server.
4. Costruisci il server di prova QBox.
5. Converti o sostituisci gli script, quindi scrivi e testa la conversione dei dati se esegui la migrazione.
6. Testa con giocatori veri se possibile, in una beta aperta.
7. Correggi cosa trovano. Questo prende più tempo di quanto ti aspetti.
8. Passa: annuncia il downtime, fai un ultimo backup di ESX, esegui la conversione su una copia nuova dei dati più recenti, e avvia QBox.
9. Mantieni il backup ESX per un po', nel caso in cui tu debba tornare indietro.

Consiglio: non cambiare nient'altro nello stesso tempo. Un cambio di framework, una mappa nuova e un'economia nuova insieme rendono impossibile dire cosa si è rotto.

Se i tuoi giocatori hanno molto in gioco, esegui il server vecchio e quello nuovo in parallelo per un breve periodo. Se i tuoi script provengono da un negozio, controlla quali framework supporta ognuno prima di acquistare quelli nuovi, in modo da scegliere script che funzionano anche su QBox.

#Elenco di controllo