Check-list avant de demander du support

Cette page, c’est ton “pare-feu anti-galère”.

Avant d’aller dire “ta base bug” à quelqu’un, tu viens ici, tu coches les étapes, tu récupères les bonnes infos, et là ta demande de support devient claire, propre et utile.

Objectif : → éviter les “ça marche pas” sans contexte → faire gagner du temps à tout le monde → augmenter tes chances d’avoir une vraie réponse rapide et précise

---

PREMIÈRE RÈGLE : TESTER LA BASE PROPRE

---

Avant de demander du support sur la base GuerreRP, pose-toi cette question simple :

Est-ce que j’ai testé la base telle qu’elle est fournie, sans bricolage ?

À vérifier :

• Tu as bien suivi :

  • “Prérequis”

  • “Comment obtenir la base GuerreRP”

  • “Installation de la base”

• Tu n’as pas encore :

  • ajouté 30 scripts venant d’ailleurs

  • remplacé ESX / ox_lib / ox_inventory par d’autres versions

  • fusionné ta DB avec 3 anciennes bases différentes

Si tu as déjà tout modifié partout, le support devient : → “support de ton mélange perso”, pas “support de la base GuerreRP”.

Idéalement :

1. Tu testes une install propre sur un dossier / base SQL vierge

2. Si la base propre marche → le problème vient de tes modifications

3. Si la base propre ne marche pas → là, ça vaut le coup de demander du support

---

INFOS TECHNIQUES À DONNER OBLIGATOIREMENT

---

Quand tu demandes du support, tu dois toujours préciser :

1. Où tourne ton serveur ?

   • Localhost (PC perso, XAMPP, WAMP…)

   • VPS / dédié (Debian, Ubuntu…)

   • Hébergeur FiveM / Pterodactyl / autre panel

2. Système :

   • Windows / Linux (quelle version si tu sais : Debian 12, Ubuntu 22.04, etc.)

3. Base de données :

   • MySQL ou MariaDB ?

   • En local ou chez un hébergeur ?

   • Tu utilises bien la base liée à GuerreRP (et pas une autre) ?

Exemple de message propre :

• “Je suis sur un VPS Debian 12, serveur FiveM sous Pterodactyl, DB MySQL chez le même hébergeur, base SQL importée depuis le fichier guerrerp.sql”

---

FOURNIR LE CONTEXTE DU PROBLÈME

---

Ne jamais écrire juste : “ça bug”, “j’ai un problème”, “ça marche pas”.

Toujours expliquer :

1. Tu voulais faire quoi ?

   • Exemple : “Je lance le serveur pour la première fois”

   • “Je me connecte, et j’ai un chargement infini”

   • “Je veux ouvrir l’inventaire et rien ne se passe”

2. À quel moment ça bug ?

   • Au démarrage du serveur ?

   • Quand le joueur se connecte ?

   • Quand il ouvre un menu ?

   • Pendant un event, un go-fast, un paintball, etc. ?

3. Sur qui / quoi ?

   • Tous les joueurs ?

   • Un seul joueur ?

   • Seulement certains jobs / zones / systèmes (ex : seulement dans la zone infectée) ?

---

FOURNIR LES LOGS / ERREURS (PAS OPTIONNEL)

---

Le support sans logs, c’est du dev à l’aveugle.

À récupérer systématiquement :

1. Erreur console serveur

   • Copie les 5 à 20 lignes autour de l’erreur

   • Pas besoin de coller 2000 lignes, mais pas juste une ligne isolée non plus

   • Inclure le nom de la ressource concernée : PowerEvent, ducratif_territoire, oxmysql, etc.

2. Erreur F8 (console client) s’il y en a

   • Si c’est un bug d’interface, d’inventaire, de NUI, de téléphone, etc.

   • Tu ouvres F8, tu reproduis le bug, tu copies les messages rouges / warnings utiles.

3. Log SQL / message oxmysql (si lié à la base de données)

   • “Unknown database…”, “Access denied…”, “Table doesn’t exist…”, etc.

Important :

• Ne modifie pas le message d’erreur

• Ne supprime pas les morceaux qui ont l’air “moches” : c’est souvent là que se trouve la vraie info

---

CHECK-LIST SQL AVANT DE CRIER AU BUG

---

Pour tout problème qui touche à l’économie, jobs, inventaire, joueurs, territoires, etc. vérifie :

1. La base SQL est bien importée ?

   • Tu as bien importé le fichier fourni avec la base

   • Il n’y a pas eu d’erreur rouge à l’import

   • Tu n’as pas mixé 3 SQL différents “pour voir”

2. Tu utilises la bonne base ?

   • Le nom de la DB dans server.cfg (config) correspond bien à la base que tu as importée

   • Tu ne pointes pas vers une vieille base qui traîne sur ton hébergeur

3. Les tables existent ?

   • Si l’erreur dit Table 'xxx' doesn't exist ou Unknown column, c’est souvent un SQL manquant

   • Tu peux comparer avec la doc / un export propre

Si tu demandes du support pour un problème lié aux data, prépare :

• Nom de la base utilisée

• Capture ou description des messages SQL

• Confirmation que tu as bien suivi la page “Erreurs SQL courantes & solutions”

---

CHECK-LIST RESSOURCES AVANT DE DEMANDER

---

Pour les scripts, tu vérifies toujours :

1. La ressource est bien dans le bon dossier ?

   • Exemple : resources/[1_esential]/[10_ducratif]/ducratif_territoire

   • Dossier complet, pas juste un fxmanifest ou un fichier perdu

2. Le nom du dossier = le nom dans ton ensure ?

   • ensure ducratif_territoire → dossier ducratif_territoire

   • Pas de majuscules random, pas d’espaces, pas de renommage hasardeux

3. La ressource démarre ?

   • Dans la console : pas de Couldn't start resource ...

   • Tu peux faire refresh puis start nom_de_la_ressource et regarder le message

4. L’ordre de démarrage est logique ?

   • Les libs (ox_lib, oxmysql, es_extended) avant les scripts qui en dépendent

   • Les scripts “core” avant les systèmes qui les utilisent

---

CE QUE TU DOIS PRÉCISER DANS TON MESSAGE DE SUPPORT

---

Quand tu écris ta demande de support, essaye de toujours inclure :

1. Environnement

   • Local / VPS / Hébergeur

   • OS (Windows, Debian, Ubuntu…)

   • Panel utilisé (txAdmin simple, Pterodactyl, etc.)

2. Ce que tu as déjà fait

   • “J’ai déjà réimporté le SQL”

   • “J’ai testé la base propre sans aucun script ajouté”

   • “J’ai vérifié les erreurs sql / j’ai corrigé les ports”

3. Exemple concret

   • “Je me connecte, j’ai l’écran de chargement infini, et sur la console j’ai ceci : …”

   • “Quand je lance la commande /xxx, j’ai cette erreur : …”

4. Logs / erreurs

   • Coller les messages utiles, pas juste “y’a des erreurs”

   • Tu peux flouter / retirer IP / mots de passe si tu veux, mais garde le contenu technique

Exemple de demande de support correcte :

“Je suis sur un VPS Debian 12, serveur lancé via txAdmin, DB MySQL locale. J’ai importé le SQL guerrerp.sql sans erreur. Quand je me connecte, j’ai un écran de chargement infini. Côté serveur, j’ai ces erreurs : [coller les 10 lignes d’erreur] J’ai déjà vérifié :

• es_extended démarre bien

• oxmysql se connecte sans erreur

• J’ai testé avec une base propre sans autres scripts ajoutés”

---

CE QU’IL FAUT ÉVITER ABSOLUMENT EN DEMANDANT DE L’AIDE

---

Si tu veux que quelqu’un t’aide sérieusement, évite :

• “ça marche pas” (sans log)

• “ta base est buggée” alors que tu as todo modifié

• envoyer une capture d’écran floue sans message lisible

• demander de l’aide sans dire si tu es en local ou en hébergeur

• cacher volontairement que tu as mixé avec 2–3 autres bases

• Ne pas avoir de formule de politesse

Le but du support, ce n’est pas de deviner ce que tu as fait dans le dos de la base GuerreRP 😅

---

MINI CHECK-LIST À COCHER AVANT DE POSTER

---

Avant d’envoyer ta demande de support, assure-toi de pouvoir répondre “oui” à au moins tout ça :

[ ] J’ai testé la base propre, sans scripts ajoutés ni modifs lourdes [ ] J’ai vérifié les erreurs dans la console serveur [ ] Si c’est visuel/interface, j’ai regardé la console F8 [ ] J’ai vérifié que la DB est bien importée et que le bon nom de base est configuré [ ] J’ai confirmé que les ressources critiques démarrent bien (ESX, ox_lib, ox_inventory, scripts Ducratif / GuerreRP) [ ] Je peux décrire clairement ce que je fais et ce qu’il se passe [ ] J’ai copié les messages d’erreur exacts (sans les réécrire à la main) [ ] Je précise si je suis en local ou chez un hébergeur

Si tu coches tout ça et que ça bloque encore, là, ta demande de support devient légitime, claire, et agréable à traiter.

Et là tu peux dire : “Ok, maintenant j’ai vraiment besoin d’un coup de main.”

---

Rejoins mon discord pour avoir de l'aide !

Rejoins le serveur Discord DucraShop (Aide Dev) !Discord