Non esiste un vincitore universale ufficiale tra ESX, QBCore e Qbox. Scegli il framework le cui ricette attuali, APIs e risorse compatibili corrispondono alle funzionalità del tuo server richieste, ai dati esistenti e alle competenze del team. Se gestisci già uno stack stabile specifico per un framework, rimanere in quell'ecosistema è solitamente la prima opzione da valutare perché la migrazione tocca più della cartella principale.
Guida rapida alle decisioni
| Punto di partenza | Primo framework da valutare | Motivo per verificare |
|---|---|---|
| Server ESX esistente | ESX Legacy | Preserva dati, eventi, esportazioni e conoscenze delle risorse specifiche di ESX quando i requisiti attuali sono ancora soddisfatti. |
| Server QBCore esistente | QBCore | Evita la conversione a meno che un altro framework non risolva un requisito documentato che lo giustifichi. |
| Nuova build orientata a QB | QBCore o Qbox | Confronta le due ricette ufficiali, le risorse selezionate, il modello API e la compatibilità esatta di terze parti. |
| Team QBCore che considera Qbox | Qbox con audit del bridge | Il bridge QB aiuta molte risorse, ma le eccezioni documentate richiedono ancora controlli a livello di risorsa. |
| Nessun requisito di framework roleplay | Risorse Standalone | Standalone descrive uno schema di dipendenza; conferma se un framework completo è effettivamente non necessario. |
Cosa fa un framework FiveM
Cfx.re descrive i framework come fondamenta che rendono più facile la creazione di risorse del server. Un framework roleplay solitamente stabilisce schemi condivisi per dati del giocatore e del personaggio, lavori, oggetti, denaro, comandi, permessi e comunicazione tra risorse. Le funzionalità esatte visibili ai giocatori dipendono dalla ricetta completa e dalle risorse installate, non solo dal nome del framework principale.
Questa distinzione impedisce un confronto fuorviante. Inventario, alloggi, telefoni, sistemi bancari o veicoli possono essere risorse separate e sostituibili. Una spunta accanto al nome di un framework non prova quale implementazione, versione o integrazione un server di produzione eseguirà.
ESX Legacy
ESX Legacy è un framework roleplay open-source con il suo core attuale pubblicato dall'organizzazione ufficiale ESX. Il tutorial ufficiale per nuovi server utilizza il template ESX Legacy txAdmin. La documentazione per l'installazione manuale include oxmysql, spawnmanager, importazione del database, core e risorse aggiuntive, esclusioni e ordine di avvio.
ESX è la prima opzione da valutare quando un server esistente ha già dati dei giocatori, risorse e procedure di team specifici di ESX. Questa è un'osservazione sul rischio di migrazione, non una rivendicazione di quota di mercato. Per una nuova build, ispeziona la ricetta attuale e verifica che ogni prodotto richiesto supporti la versione esatta di ESX, l'inventario, la libreria del database, le esportazioni e gli eventi.
QBCore
Ufficiale di QBCore qb-core espone un Oggetto Core con funzioni, dati del giocatore, dati condivisi, configurazione e comandi. Le definizioni condivise includono lavori, gang, oggetti e veicoli. L'installazione ufficiale di Windows utilizza la ricetta popolare di QBCore Framework in txAdmin, e la ricetta distribuisce un database e un set di risorse più ampio piuttosto che solo la cartella core.
QBCore è un candidato per una nuova o esistente build dell'ecosistema QB quando i suoi APIs documentati e le risorse compatibili coprono i requisiti del server. Non dedurre che ogni risorsa che porta un'etichetta QBCore supporti ogni versione core o inventario sostitutivo. Registra le esportazioni richieste, le dipendenze, SQL e l'ordine di avvio per lo stack esatto.
Qbox
L'introduzione ufficiale di Qbox registra che Qbox è iniziato nel 2022 da QBCore e ora ha i suoi APIs e risorse core. Qbox mantiene un bridge di compatibilità QB per molte risorse QBCore scritte correttamente. La sua documentazione elenca anche eccezioni, incluse risorse che dipendono dall'accesso diretto al database, file core interni o comportamenti non supportati.
L'installazione ufficiale di Qbox utilizza una ricetta popolare di QBox in txAdmin. Per una migrazione da QBCore, la guida di conversione copre le differenze di configurazione, i gradi numerici di lavoro e gang, la conversione dell'inventario e del database, e la sostituzione incrementale di API. Qbox è quindi una scelta di framework deliberata con un audit di compatibilità, non semplicemente un interruttore che fa funzionare ogni script QBCore invariato.
Dimensioni di confronto che puoi verificare
| Dimensione | Domanda | Prova |
|---|---|---|
| Percorso di installazione | Esiste una ricetta ufficiale attuale e una documentazione completa? | Documentazione ufficiale e repository delle ricette alla data della revisione. |
| Risorse richieste | Quali risorse di database, libreria, inventario e supporto sono selezionate? | File di ricetta, manifest e dichiarazioni di dipendenza. |
| Compatibilità API | Quali esportazioni, eventi, oggetti e campi dati vengono chiamati dagli script richiesti? | Origine della risorsa, manifest e documentazione ufficiale API. |
| Modello di dati | Quali identificatori, gradi, account e relazioni devono essere preservati? | Inventario dello schema e mappatura della migrazione testata. |
| Operazioni | Il team può aggiornare, diagnosticare e ripristinare lo stack? | Runbook, backup ed esercitazione di recupero a fasi. |
| Prestazione | Come si comporta lo stack esatto sotto azioni rappresentative? | Log del profiler, resmon e database da test controllati ripetuti. |
Checklist decisionale
- Elenca le funzionalità richieste per i giocatori. Nomina i requisiti esatti per lavori, economia, inventario, alloggi, telefono, veicoli, amministrazione e integrazione.
- Elenca le dipendenze esistenti. Registra le versioni del framework, i manifest, le tabelle del database, le esportazioni, gli eventi e le modifiche personalizzate al core.
- Supporto per le risorse della mappa. Per ogni risorsa richiesta, conferma il framework e la versione che supporta effettivamente, inclusi bridge e sistemi di sostituzione.
- Verifica le conoscenze del team. Includi gli API, le lingue, il modello di database e gli strumenti operativi che i manutentori possono diagnosticare.
- Stima la migrazione dalle prove. Conta i domini di dati reali e le integrazioni; non utilizzare una tabella generica di ore o costi.
- Costruisci uno stack di test rappresentativo. Utilizza la ricetta ufficiale, le risorse selezionate e una copia sanificata di dati realistici.
- Definisci l'accettazione e il rollback. Decidi cosa deve funzionare e come ripristinare i file e il database coerenti precedenti.
La migrazione influisce sull'intero modello del server
Cambiare framework può coinvolgere identità, personaggi, denaro, lavori, gang, inventario, veicoli, garage, alloggi, telefoni, banche, conti sociali, permessi ed eventi personalizzati. Le relazioni dei dati sono importanti: creare un nuovo identificatore di personaggio senza mappare tutti i record correlati può rendere orfani beni o permessi.
Non eseguire uno script di conversione generico SQL sulla produzione. Inizia con uno schema e un inventario delle risorse, progetta una conversione idempotente su una copia di test, convalida i conteggi dei record e le relazioni, e prova il rollback. Gli script specifici del framework potrebbero richiedere un bridge ufficiale, una modalità multi-framework documentata o modifiche al codice. Gli script ESX non sono automaticamente portabili su QBCore o Qbox, e il bridge Qbox QB non è universale.
Come misurare le prestazioni del tuo stack
Se le prestazioni influenzano la scelta, confronta build controllate piuttosto che ripetere una classifica. Usa lo stesso host o hardware isolato equivalente, artefatto FXServer, versione del database, volume di dati e azioni rappresentative dei giocatori. Mantieni il set di risorse funzionalmente comparabile e dichiara ogni differenza intenzionale.
- Scalda ogni server in modo coerente e cattura il comportamento inattivo.
- Ripeti le stesse azioni di caricamento del personaggio, inventario, lavoro, veicolo ed economia.
- Raccogli prove dal profiler FiveM o resmon più query lente del database e metriche di sistema.
- Esegui campioni multipli e riporta distribuzioni o intervalli, non un singolo numero migliore.
- Ispeziona errori, correttezza dei dati e comportamento di riconnessione insieme alla temporizzazione.
- Conserva la configurazione e i log grezzi in modo che un altro revisore possa riprodurre la conclusione.
Un benchmark di un core con diverse risorse non isola il framework. Un risultato da un server vuoto sintetico non dimostra la capacità di produzione. Pubblica solo conclusioni supportate dalla configurazione registrata e dalle prove grezze.
Raccomandazione pratica
- Scegli ESX quando le risorse ESX attuali, i dati e la conoscenza del team soddisfano al meglio i requisiti e la migrazione non ha alcun beneficio dimostrato.
- Scegli QBCore quando la ricetta ufficiale QB e l'ecosistema documentato si adattano a una nuova build o a un server QB esistente.
- Scegli Qbox quando il team desidera deliberatamente la ricetta attuale di Qbox e i suoi API e può completare un ponte o un audit di migrazione QB.
Apri le guide dedicate ai framework per l'attuale confine ufficiale di installazione e compatibilità. Abbina quindi le risorse commerciali allo stack esatto scelto, piuttosto che trattare un'etichetta di categoria generica come prova definitiva.
Guide dettagliate ai framework
Continua con l'esatto confine di installazione e compatibilità per ESX Legacy, QBCore o il Qbox e stack Ox.