Guides FiveM : Frameworks, Intégration et Tests d’Installation
Comparez ressources et données pour QBCore, ESX, Standalone, vRP et OX/Qbox. Durée selon scripts propres et tests.
Réponse courte: Identifiez core et inventaire, puis réglage AC et tests.
Installation et compatibilité
| Base | Champ framework AC | Données supportées | Guide |
|---|---|---|---|
| QBCore | qb | players / citizenid ; index compatibles | Guide d’installation → |
| ESX | esx | users / identifier ; index compatibles | Guide d’installation → |
| Standalone | standalone | Données propres non prises en charge par pont | Guide d’installation → |
| vRP / vRPex | standalone : contrôles généraux | Économie/personnages vRP propres non supportés | Guide d’installation → |
| Qbox / ox_core | qbox / standalone | Qbox compatible ; ox_core pur non supporté | Guide d’installation → |
Choisir l’installation réelle
qb-core → qb ; es_extended → esx ; qbx_core → qbox. standalone général pour custom/vRP. ox_inventory n’est pas un core ; ox_core séparément. Vérifiez auto en console.
Un profil ne crée pas vos règles
Découvrir événement/framework ne valide pas prix, quantité, position et droits. Boutiques, métiers, récompenses et inventaires propres doivent vérifier côté serveur. Action normale n’exige pas de log de détection. Testez lecture, refus de droits et détection séparément.
Distinguer framework et inventaire
Identifiez la ressource d’état joueur : qb-core, qbx_core ou es_extended. Examinez séparément inventaire et adaptations API. Un nom connu ne garantit pas tous les scripts bancaires ou d’inventaire externes. Conservez les dépendances ; ne lancez pas des cores concurrents pour dépanner.
Modifiez le champ existant : qb pour QBCore, qbox pour Qbox ; ce sont des valeurs, pas des dossiers. auto permet la détection. Vérifiez le mode dans les messages et GetStatus côté serveur. Le pont détecte séparément les cores actifs et peut signaler un démarrage manquant.
-- Modifier le champ existant, pas toute la table.
ts.Framework.framework = "qb"
-- Autres valeurs prises en charge : "esx", "qbox", "auto", "standalone"
Vérifier les données du personnage
Les lectures utilisent citizenid avec QBCore/Qbox et identifier avec ESX. L’ID serveur temporaire ne remplace pas l’identifiant personnage. Colonnes et index compatibles sont nécessaires ; une structure personnalisée peut être refusée.
- Comparez un personnage test dont espèces, banque, métier et véhicule sont connus.
- Avec ox_inventory, comparez un petit inventaire en ligne. Respectez les troncatures ; pas de stashes ni métadonnées arbitraires.
- En cas d’erreur API, vérifiez lancement et version. Une API indisponible signifie possession inconnue, pas arme absente prouvée.
Tester les parcours réels
La détection ne connaît pas les droits, positions, prix ou récompenses de chaque événement personnalisé. Votre script doit les vérifier côté serveur. Un profil ne sécurise pas automatiquement un événement argent/item vulnérable. Validez source et session avant intégration.
Standalone/vRP peuvent utiliser des contrôles généraux adaptés ; le pont ne promet pas leurs schémas personnalisés. Expliquez les limites plutôt que substituer des tables étrangères. Recontrôlez après mises à jour core, inventaire ou métiers.
Notez versions core et inventaire. Après redémarrage core, reconnectez le personnage avant de juger l’API en ligne. Ne changez pas schéma et sanction ensemble : séparer permet diagnostic et restauration.
- Changement de personnage et réanimation ne laissent pas d’exemption permanente.
- Maison, garage et prison appellent MarkTeleport juste avant le déplacement.
- Armes d’arène sans inventaire utilisent un AllowWeapon court depuis un script serveur de confiance.
- Testez police, outils, boutiques et grosses récompenses contre les logs avant des sanctions plus fortes.
Mesurer une référence reproductible
Profilez une session représentative avant les changements. Notez joueurs, artifact, versions et activité. Roleplay calme, garages pleins et combats diffèrent. Après un seul réglage, comparez le même scénario. CPU, hitches et requêtes valent mieux qu’un gain FPS promis.
Les commandes enregistrent un échantillon borné. Attendez la fin et identifiez ressource et thread responsables du pic. Tous les hitches ne viennent pas de l’AC. Gardez valeurs et comparaison privées ; une courte mesure ne couvre pas tous les pics.
profiler record 500
profiler status
profiler view
tosunac_doctor
Mises à jour, restauration et support
Retestez après changement de core, inventaire, métiers ou AC. Ne modifiez pas schéma, sanction et version ensemble. Si le changement échoue, restaurez ressource et réglages en maintenance ; évaluez la perte de données avant restauration de base. Fournissez versions artifact/core/inventaire/AC, ressource, étapes, heure et première erreur expurgée au support. Aucun identifiant joueur, licence, mot de passe ou token public.
Détails associés
Documentation d’installation · Pont de base de données · Exports serveur
Questions fréquentes
Un réglage panel suffit lors du changement core ?
Non. API, inventaire, IDs, schéma et événements changent ; sauvegardez et retestez.
Pas de données signifie AC arrêté ?
Non. Droits/schéma du pont et contrôles généraux sont distincts.
Plusieurs serveurs ?
Vérifiez quota du forfait et licence par serveur ; testez séparément.