Remboursements & pertes — conditions et preuves

Environ 4002 motsEnviron 13 min

Le système de remboursement d’Insane RP permet de corriger certaines pertes provoquées par :

un bug ;
un problème serveur ;
une erreur administrative ;
un incident technique vérifiable.

Un remboursement n’a pas pour objectif d’annuler les conséquences normales du RolePlay.

Lorsqu’une perte résulte normalement d’une scène, elle doit généralement être assumée.

Principe général

Pour qu’une demande puisse être étudiée, il doit être possible de déterminer raisonnablement :

ce qui a été perdu ;
comment la perte est survenue ;
quand elle est survenue ;
si elle provient réellement d’un problème technique ou administratif ;
si le joueur possédait réellement les éléments réclamés.

Un remboursement n’est pas automatique

Le simple fait d’avoir perdu quelque chose ne donne pas automatiquement droit à un remboursement.

Chaque demande peut être analysée selon :

les preuves ;
les logs disponibles ;
le contexte ;
la cause de la perte ;
les règles applicables.

Pertes RP normales

Une perte résultant normalement du RolePlay ne doit généralement pas être remboursée.

Exemples

arme saisie par la police ;
argent volé lors d’une scène valide ;
cargaison perdue pendant un braquage ;
véhicule endommagé pendant une poursuite ;
objet remis volontairement à quelqu’un ;
marchandise perdue après une arrestation.

Exemple simple

Vous transportez des stupéfiants.

Vous êtes arrêté.

La police saisit la marchandise.

Vous ne pouvez pas ensuite ouvrir un ticket :

« remboursement bug inventaire »

parce que le bug s’appelait en réalité LSPD (n'est-ce pas) 😉

Bug serveur

Une perte provoquée par un véritable dysfonctionnement peut être étudiée.

Cela peut notamment concerner :

inventaire supprimé ;
coffre vidé par erreur technique ;
véhicule disparu anormalement ;
argent retiré plusieurs fois ;
transaction incorrectement exécutée ;
problème après un crash serveur.

Erreur administrative

Lorsqu’une action staff provoque accidentellement une perte, une correction peut être effectuée.

Exemples

mauvais montant retiré ;
mauvais objet supprimé ;
mauvais joueur ciblé ;
véhicule supprimé par erreur ;
donnée modifiée incorrectement.

Erreur reconnue

Lorsqu’une erreur administrative est clairement identifiée, le staff doit essayer de restaurer la situation de manière raisonnable.

Crash personnel

Un crash FiveM individuel ne donne pas automatiquement droit à un remboursement.

Il faut déterminer si la perte :

a réellement été causée par le crash ;
peut être vérifiée ;
n’aurait pas eu lieu normalement sans le problème.

Crash pendant une scène

Un crash pendant :

braquage ;
poursuite ;
transaction ;
combat ;

ne signifie pas automatiquement que toutes les pertes survenues doivent être annulées.

Le contexte de la scène doit être pris en compte.

Crash serveur global

Lorsqu’un crash général touche plusieurs joueurs, certaines pertes peuvent être étudiées plus facilement lorsque les conséquences techniques sont identifiables.

Rollback

Un rollback peut remettre certaines données dans un état antérieur.

Cela peut provoquer :

disparition d’une acquisition récente ;
retour d’un ancien inventaire ;
modification d’un solde ;
incohérence de véhicule.

Demande après rollback

Le staff peut vérifier la situation grâce aux éléments disponibles.

Cependant, il n’est pas toujours techniquement possible de reconstruire précisément chaque action ayant eu lieu avant le rollback.

Restart normal

Un redémarrage annoncé ne constitue pas automatiquement un bug.

Les joueurs doivent prendre en compte les annonces lorsqu’un restart est imminent.

Commencer une transaction avant restart

Si un joueur commence volontairement une opération importante quelques secondes avant un redémarrage annoncé, la demande pourra être étudiée avec davantage de prudence.

Argent

Une perte d’argent peut être étudiée lorsqu’elle semble provenir :

d’un bug ;
d’un double prélèvement ;
d’une transaction défectueuse ;
d’une erreur administrative.

Preuve d’argent

Une simple déclaration :

« j’avais beaucoup d’argent »

n’est généralement pas suffisante.

Les éléments utiles peuvent notamment inclure :

logs ;
screenshot ;
vidéo ;
historique de transaction ;
données serveur.

Argent liquide

Lorsque de l’argent liquide disparaît, précisez :

montant approximatif ;
activité réalisée ;
moment de la perte ;
dernière situation où vous l’avez vu.

Argent bancaire

Pour une anomalie bancaire, précisez :

compte concerné ;
montant ;
opération effectuée ;
éventuel destinataire.

Double prélèvement

Si une transaction retire deux fois une somme alors qu’une seule opération a été effectuée, ne répétez pas l’opération.

Conservez une preuve puis contactez le support.

Argent reçu en trop

Un bug peut également donner plus d’argent que prévu.

Dans ce cas :

ne le dépensez pas ;
ne le transférez pas ;
signalez-le.

Pourquoi signaler un gain buggué ?

Parce qu’un bug économique reste un bug même lorsqu’il vous donne de l’argent au lieu de vous en prendre.

Étrangement, le serveur ne considère pas :

« le bug était en ma faveur »

Objets

Un objet disparu à cause d’un problème technique peut éventuellement être restauré.

Informations nécessaires

Précisez autant que possible :

nom exact de l’objet ;
quantité ;
emplacement ;
heure approximative ;
action effectuée avant la disparition.

Plusieurs objets

Si plusieurs objets sont concernés, fournissez une liste claire.

« J’ai perdu plein de trucs »

Cette description est insuffisante.

Le staff ne peut pas reconstruire votre inventaire comme ça...

Armes

Les remboursements concernant les armes peuvent nécessiter davantage de vérifications.

Précisez notamment :

type d’arme ;
circonstance de la perte ;
éventuels éléments associés lorsque cela est pertinent.

Arme saisie

Une arme légalement saisie dans une scène ne doit pas être remboursée.

Arme perdue après bug

Si une arme disparaît à cause d’un problème technique clairement identifié, une demande peut être étudiée.

Munitions

Les munitions peuvent également être prises en compte lorsqu’elles sont vérifiables.

Objets illégaux

Une ressource illégale n’est pas exclue automatiquement d’un remboursement lorsqu’une véritable erreur technique est démontrée.

Cependant, le staff doit vérifier que la perte n’était pas simplement une conséquence normale d’une activité criminelle.

Exemple

Votre coffre contenant une marchandise disparaît à cause d’un bug confirmé.

La demande peut être étudiée.

Vous êtes arrêté et la police saisit cette même marchandise.

Ce n’est pas une demande technique.

Drogues

Les ressources liées à la production ou au trafic peuvent être vérifiées comme les autres objets lorsque le contexte est réellement technique.

Véhicules

Un véhicule peut rencontrer différents types de problèmes :

disparition ;
duplication ;
état incorrect ;
garage défectueux ;
destruction anormale.

Véhicule disparu

Avant de demander un remboursement ou une restauration, vérifiez :

vos garages ;
la fourrière ;
les systèmes de stockage ;
si le véhicule est déjà sorti.

Véhicule détruit en RP

Un véhicule détruit pendant :

accident ;
poursuite ;
fusillade ;
scène normale ;

n’est pas automatiquement remboursable.

Bug de véhicule

Un remboursement ou une correction peut être étudié lorsque le véhicule :

disparaît sans raison ;
est supprimé par un bug ;
subit une anomalie clairement technique.

Réparation administrative

Dans certains cas, le staff peut choisir de réparer ou restaurer l’état plutôt que de créer un nouveau véhicule.

Véhicule dupliqué

Si un bug génère plusieurs copies :

n’en vendez pas une ;
ne les transférez pas ;
ne cherchez pas à conserver les doublons.

Signalez le problème.

Propriété

Les problèmes concernant une propriété, un logement ou un garage peuvent nécessiter une vérification spécifique.

Bien disparu

Si une propriété n’apparaît plus correctement, ne tentez pas immédiatement de la racheter.

Contactez le support afin d’éviter une situation encore plus complexe.

Coffres

Lorsqu’un coffre rencontre un problème, précisez :

emplacement ;
propriétaire ;
contenu approximatif ;
dernière utilisation normale.

Coffre vide

Un coffre vide ne signifie pas automatiquement qu’un bug a eu lieu.

Le staff peut devoir vérifier :

retraits ;
accès autorisés ;
actions des joueurs ;
logs.

Vol par un joueur

Si un autre joueur possédait légitimement l’accès et retire des ressources dans un contexte RP autorisé, il ne s’agit pas forcément d’un bug.

Compte entreprise

Un problème économique concernant une entreprise peut avoir des conséquences importantes.

Informations utiles

Pour une anomalie de compte société, indiquez :

entreprise ;
montant ;
opération ;
personnes concernées ;
moment approximatif.

Détournement RP

Un détournement effectué par un joueur dans le cadre des règles ne devient pas automatiquement un problème technique.

Action interdite

Si le détournement constitue une infraction au règlement, il s’agit d’abord d’un dossier de modération.

La restitution éventuelle sera décidée en fonction de la situation.

Arnaque

Une arnaque RP autorisée n’est pas automatiquement remboursable.

Arnaque interdite

Si une arnaque enfreint clairement les règles, le staff peut étudier :

la sanction ;
les ressources concernées ;
une éventuelle restitution.

Scam HRP

Une fraude utilisant des moyens HRP ou de l’argent réel doit être signalée immédiatement.

Perte après triche

Lorsqu’un joueur perd des biens à cause d’un tricheur, la situation peut être examinée.

Le staff doit d’abord confirmer suffisamment les faits.

Ban du tricheur

Le bannissement de la personne ne signifie pas automatiquement que chaque participant recevra toutes les ressources qu’il affirme avoir perdues.

Les pertes doivent rester raisonnablement vérifiables.

Mass FreeKill

Une situation de Mass FreeKill peut parfois nécessiter des corrections administratives lorsque les conséquences économiques sont importantes et vérifiables.

Mort normale

Une mort résultant d’une scène valide ne donne pas droit à un remboursement simplement parce que le joueur est mécontent du résultat.

Désynchronisation

La désynchronisation peut parfois provoquer :

collisions étranges ;
dégâts inattendus ;
comportements différents entre les clients.

Toutes les situations de desync ne peuvent pas nécessairement être remboursées.

Desync vérifiable

Lorsqu’un problème exceptionnel est clairement visible et provoque directement une perte importante, le staff peut examiner la demande.

Latence personnelle

Une mauvaise connexion du joueur n’est pas nécessairement de la responsabilité du serveur.

Les demandes seront étudiées au cas par cas.

Mauvaise manipulation

Une erreur réalisée par le joueur lui-même n’est généralement pas remboursée.

Exemples

jeter accidentellement un objet ;
vendre le mauvais véhicule ;
transférer de l’argent au mauvais joueur ;
acheter le mauvais article.

Achat par erreur

Vérifiez toujours :

nom ;
prix ;
quantité ;

avant de confirmer une transaction.

Confirmation

Lorsqu’un système affiche clairement les informations avant validation, une mauvaise confirmation de votre part ne constitue généralement pas un bug.

Mauvais destinataire

Envoyer volontairement un transfert au mauvais identifiant ou à la mauvaise personne n’entraîne pas nécessairement un remboursement administratif.

Exception technique

Si le système affiche un destinataire mais crédite une autre personne à cause d’un bug, la situation devient différente.

Mauvais prix

Un joueur qui accepte volontairement une transaction ne peut pas demander un remboursement uniquement parce qu’il réalise ensuite qu’il aurait pu trouver moins cher.

Achat auprès d’un joueur

Le staff n’a pas vocation à annuler chaque transaction dès qu’un joueur regrette son choix.

Prêt

Un prêt RP non remboursé doit d’abord être traité comme une situation RP lorsqu’il respecte les règles.

Dette

Le support ne constitue pas automatiquement une société de recouvrement administrative.

Les procédures dépendent du contexte et des règles applicables.

Prêt sans preuve

Un accord important devrait idéalement laisser suffisamment d’éléments RP permettant d’en démontrer l’existence.

Don volontaire

Un bien donné volontairement à un joueur n’est pas remboursé simplement parce que vous avez changé d’avis.

Cadeau à un ami

Même principe.

Une rupture d’amitié HRP ne transforme pas automatiquement chaque ancien cadeau en ticket de remboursement.

Organisation

Les ressources appartenant à un groupe peuvent nécessiter des vérifications particulières.

Départ d’un membre

Un conflit concernant les biens d’une organisation après le départ d’un membre doit être étudié selon :

règles du groupe ;
règlement illégal ;
contexte RP ;
éventuelles infractions.

Dissolution

La dissolution d’une organisation ne garantit pas que tous ses biens soient répartis ou remboursés aux anciens membres.

Entreprise fermée

Les règles de reprise ou fermeture d’une entreprise peuvent avoir leurs propres conséquences économiques.

Reset de personnage

Une suppression volontaire ou un reset accepté peut entraîner la perte de certaines données.

Ces pertes ne doivent pas être réclamées ensuite comme des bugs lorsqu’elles faisaient partie de la procédure.

Mort RP

Lorsqu’une Mort RP implique certaines pertes prévues par les règles, celles-ci ne sont pas remboursables simplement parce que le joueur les regrette après validation.

Changement de personnage

Les ressources d’un ancien personnage ne doivent pas nécessairement être transférées vers un nouveau.

Ban

Une sanction peut entraîner certaines conséquences sur l’utilisation du compte ou des ressources.

Elle ne constitue pas un bug.

Wipe administratif

Lorsqu’un wipe est appliqué comme sanction validée, les éléments retirés ne sont pas remboursables.

Fausse sanction

Si une sanction ou confiscation est ensuite reconnue comme erronée, certaines conséquences peuvent être corrigées.

Annulation de sanction

L’annulation d’une sanction ne garantit pas toujours qu’il soit techniquement possible de restaurer chaque élément exactement.

Le staff fera au mieux avec les données disponibles.

Les preuves

Une bonne preuve augmente fortement la capacité du staff à comprendre une demande.

Preuves possibles

Selon la situation :

clip vidéo ;
screenshot ;
logs serveur ;
historique de transaction ;
transcript ;
données internes.

Vidéo

Une vidéo représente souvent l’un des meilleurs éléments car elle peut montrer :

action effectuée ;
état précédent ;
moment de la perte ;
contexte.

Vidéo complète

Lorsque le contexte est important, fournissez suffisamment de temps avant et après le problème.

Montage

Évitez de couper précisément tous les moments entourant la perte.

Le staff peut demander la version originale.

Screenshot

Un screenshot peut suffire pour certains problèmes simples.

Limite du screenshot

Une capture montre un instant précis.

Elle ne permet pas toujours de démontrer ce qui s’est passé juste avant ou après.

Logs

Les logs peuvent être utilisés afin de vérifier certaines actions.

Cependant, tous les systèmes ne disposent pas nécessairement du même niveau de traçabilité.

« Regardez les logs »

Cette phrase peut être utile.

Mais le staff a tout de même besoin d’informations pour savoir :

quels logs ;
quel joueur ;
quelle heure ;
quelle action.

Heure précise

Donnez l’heure la plus précise possible.

Moins utile

Je crois que c’était la semaine dernière le soir.

Fuseau et date

Lorsque la demande n’est pas réalisée immédiatement, précisez également la date afin d’éviter les confusions.

Identifiant joueur

Lorsque demandé, fournissez l’identifiant nécessaire au staff.

Évitez cependant de publier des informations sensibles dans des salons publics.

Nom du personnage

Précisez le personnage concerné lorsque vous en possédez plusieurs.

Quantités exactes

Évitez :

j’avais environ beaucoup de coke

Préférez :

J’avais 25 unités dans le coffre avant le bug.

Valeur estimée

Lorsque le montant exact est inconnu, soyez transparent.

Ne transformez pas une estimation en certitude.

Absence de preuve

Une demande sans clip n’est pas automatiquement refusée si d’autres moyens permettent de vérifier les faits.

Cependant, certaines situations peuvent être impossibles à confirmer.

Témoignage d’un ami

Le témoignage d’un autre joueur peut apporter du contexte.

Il ne remplace pas toujours une preuve technique.

Plusieurs témoins

Plusieurs témoignages cohérents peuvent être pris en compte, mais ils ne constituent pas automatiquement une preuve absolue.

Fausse preuve

Présenter volontairement une fausse preuve dans l’objectif d’obtenir des ressources constitue une faute grave.

Modification de screenshot

Il est interdit de modifier :

montant ;
inventaire ;
heure ;
texte ;

afin de tromper le staff.

Ancienne preuve

Une capture ancienne ne doit pas être présentée comme preuve que les mêmes ressources étaient toujours présentes au moment de la perte.

Preuve provenant d’une autre personne

N’utilisez pas le clip d’un autre joueur pour prétendre qu’il s’agit de votre propre inventaire.

Oui, il fallait probablement le préciser quelque part 😃

Remboursement frauduleux

Toute tentative de remboursement frauduleux peut entraîner une sanction.

Exagération

Mentir volontairement sur les quantités peut également être considéré comme une fraude.

Exemple

Les logs montrent une perte de 10 objets.

Vous réclamez 100 en espérant que personne ne vérifie.

Double remboursement

Un même problème ne peut pas être remboursé plusieurs fois.

Plusieurs tickets

Il est interdit d’ouvrir plusieurs tickets pour essayer d’obtenir plusieurs validations du même remboursement.

Remboursement déjà effectué

Si une correction a déjà été faite, informez le staff si un second membre reprend accidentellement le dossier.

Ressource retrouvée après remboursement

Si vous retrouvez ensuite une ressource déjà remboursée en raison d’un bug temporaire, signalez-le.

Le doublon devra éventuellement être retiré.

Revente avant vérification

Lorsqu’un objet semble avoir été dupliqué, ne le vendez pas avant que la situation soit clarifiée.

Dépenser un remboursement incorrect

Si le staff vous donne accidentellement une quantité trop importante :

ne dépensez pas le surplus ;
signalez l’erreur.

Erreur du staff favorable au joueur

Une erreur reste une erreur même lorsqu’elle vous avantage.

Montant du remboursement

Lorsqu’une demande est validée, le remboursement correspond normalement à ce qui peut être raisonnablement démontré.

Pas d’indemnisation supplémentaire

Une perte ne donne généralement pas droit à un bonus pour :

attente ;
frustration ;
temps passé dans le ticket.

Exemple

Vous perdez 50 unités à cause d’un bug confirmé.

Le remboursement concerne les 50 unités.

Pas :

50 + 50 autres parce que j’ai dû ouvrir Discord

Valeur de remplacement

Dans certaines situations, le staff peut devoir utiliser une valeur ou ressource équivalente lorsque la restauration exacte est techniquement impossible.

Cela reste une décision administrative.

Objet indisponible

Un objet supprimé ou modifié par une mise à jour ne pourra pas forcément être recréé sous son ancienne forme.

Véhicule modifié

Une mise à jour peut changer certains véhicules.

Le remboursement ne garantit pas le retour exact d’un comportement ou d’une caractéristique ancienne.

Changements d’équilibrage

Un nerf ou changement volontaire d’équilibrage ne donne pas droit à un remboursement.

Exemple

Le prix de revente d’une ressource est réduit lors d’une mise à jour.

Les anciens propriétaires ne peuvent pas demander la différence sur tout leur stock.

Changement de prix

L’économie peut évoluer.

Une variation de prix n’est pas une perte technique.

Suppression d’un système

Lorsqu’une fonctionnalité est volontairement retirée, les modalités de compensation éventuelles sont décidées par l’administration.

Ne partez pas du principe qu’un remboursement sera automatiquement accordé.

Délai de demande

Les demandes doivent être réalisées dans un délai raisonnable après le problème.

Plus une situation est ancienne, plus elle peut être difficile à vérifier.

Pourquoi ne pas attendre ?

Certains logs ou contextes peuvent devenir plus difficiles à retrouver avec le temps.

« Ça date d’il y a plusieurs mois »

Une demande extrêmement ancienne pourra être impossible à vérifier suffisamment.

Signalez rapidement

Lorsque la perte est importante :

évitez de modifier davantage la situation ;
conservez vos preuves ;
ouvrez un ticket.

Ne pas continuer à exploiter le problème

Si vous remarquez qu’une action :

supprime ;
duplique ;
modifie incorrectement ;

des ressources, arrêtez de l’utiliser.

Limiter les dégâts

Continuer volontairement une action défectueuse peut rendre la situation plus difficile à corriger.

Procédure de remboursement

Une demande peut généralement suivre plusieurs étapes.

Étape 1 — Ouvrir un ticket

Utilisez la catégorie adaptée.

Catégorie remboursement : Remboursement dans le panel de ticket.

Étape 2 — Expliquer le problème

Décrivez clairement :

ce que vous avez perdu ;
pourquoi vous pensez qu’il s’agit d’un bug ;
quand cela s’est produit.

Étape 3 — Fournir les preuves

Ajoutez :

clips ;
captures ;
informations demandées.

Étape 4 — Vérification

Le staff peut consulter les éléments disponibles.

Étape 5 — Décision

La demande peut être :

acceptée ;
partiellement acceptée ;
refusée ;
transmise à un responsable.

Acceptation partielle

Une demande peut être partiellement validée lorsqu’une partie seulement des ressources peut être vérifiée.

Exemple

Vous demandez 100 unités.

Les preuves permettent d’en confirmer 70.

Le staff peut limiter la correction aux 70 éléments réellement vérifiables.

Refus

Un refus peut notamment être lié à :

perte RP normale ;
preuves insuffisantes ;
mauvaise manipulation ;
demande incohérente ;
impossibilité de vérifier ;
fraude.

Refus ≠ accusation

Un remboursement refusé faute de preuve ne signifie pas automatiquement que le joueur est considéré comme menteur.

Cela peut simplement signifier que le staff n’a pas suffisamment d’éléments pour créer des ressources.

Contestation d’un refus

Lorsqu’une procédure permet de demander une seconde vérification, apportez idéalement :

nouvel élément ;
nouvelle preuve ;
information manquante.

Staff Shopping

Ne fermez pas le ticket pour en rouvrir un autre jusqu’à trouver un staff acceptant votre remboursement.

Respect du staff

Un remboursement refusé ne justifie pas :

insultes ;
menaces ;
spam.

Patience

Certaines demandes nécessitent :

vérification de logs ;
consultation d’un responsable ;
intervention d’un développeur.

Pings répétés

Évitez :

up

staff ?

??

ça fait 3 minutes

allo ?

Le ticket n’a pas oublié l'existence de votre ticket en 30 secondes, soyez patient.

Remboursement par Support

Un membre du support peut recueillir les informations sans nécessairement avoir l’autorisation d’effectuer lui-même la correction.

Validation supérieure

Certaines demandes sensibles peuvent nécessiter l’accord d’un membre disposant des permissions nécessaires.

Gros remboursements

Plus une demande possède un impact économique important, plus une vérification rigoureuse peut être nécessaire.

Pas de favoritisme

Une demande provenant :

d’un ami ;
d’un staff ;
d’un streamer ;
d’un dirigeant d’organisation ;

doit être vérifiée selon les mêmes principes.

Staff concerné

Lorsqu’un membre du staff demande un remboursement pour son propre personnage, il est préférable qu’un autre membre examine la situation.

Organisation d’un staff

Même principe lorsque le remboursement bénéficie directement à son groupe RP.

Traçabilité

Les remboursements importants doivent être correctement documentés lorsque les outils du serveur le permettent.

Motif

Une correction doit disposer d’un motif clair.

Exemple

Remboursement bug coffre confirmé — ticket correspondant.

Logs administratifs

Les actions de remboursement peuvent être enregistrées afin d’éviter :

doublons ;
abus ;
erreurs.

Give manuel

Un Give administratif utilisé pour un remboursement doit correspondre précisément à ce qui a été validé.

Vérifier le joueur

Avant de donner une ressource, le staff doit vérifier qu’il cible le bon joueur.

Vérifier la quantité

Une quantité incorrecte peut créer un nouveau problème économique.

Correction d’une erreur de remboursement

Si une erreur survient :

signalez-la ;
corrigez-la ;
ne cherchez pas à la cacher.

Modèle de demande

Vous pouvez utiliser ce format dans votre ticket :

Problème

Expliquez précisément ce qui s’est produit.

Cause supposée

Expliquez pourquoi vous pensez qu’il s’agit d’un problème technique.

Solutions déjà essayées

Expliquez si vous avez :

reconnecté ;
vérifié vos garages ;
vérifié vos comptes ;
effectué d’autres vérifications pertinentes.

Exemple de bonne demande

Bonjour, aujourd’hui vers 21h35 j’ai déposé 30 unités dans le coffre de mon véhicule. Après avoir rouvert le coffre, il était vide. J’ai reconnecté mais les objets n’étaient toujours pas présents. Voici le clip montrant le dépôt puis la disparition.

Cette demande donne immédiatement des informations utiles.

Exemple de mauvaise demande

j’ai perdu des trucs remboursez

Le département d’investigation paranormal d’Insane RP n’est toujours pas ouvert malheureusement 😦

Checklist avant de demander un remboursement

La perte ne provient pas simplement d’une scène RP normale.
J’ai vérifié mes garages / comptes / coffres concernés.
J’ai noté la date et l’heure approximative.
Je sais exactement ce que j’ai perdu.
J’ai conservé une preuve si possible.
Je n’ai pas exploité le bug.
Je n’ai pas déjà été remboursé.
Je n’ai pas ouvert plusieurs tickets identiques.
Je suis prêt à fournir les informations demandées.

Cas généralement étudiables

✅ Potentiellement remboursables

bug serveur confirmé ;
erreur administrative ;
double prélèvement technique ;
inventaire supprimé anormalement ;
perte directement liée à un incident serveur ;
erreur de système vérifiable.

Cas généralement non remboursables

❌ Généralement non remboursables

arrestation normale ;
saisie policière ;
braquage valide ;
perte de fusillade ;
accident provoqué par le joueur ;
achat regretté ;
cadeau volontaire ;
mauvaise manipulation ;
variation normale de l’économie ;
perte sans possibilité suffisante de vérification.

Cas étudiés individuellement

⚠️ Selon le contexte

crash individuel ;
desync ;
triche d’un autre joueur ;
infraction RP ayant provoqué une perte ;
problème lors d’un restart ;
anomalie économique complexe.

Bon sens

Avant de demander un remboursement, demandez-vous :

La perte vient-elle réellement d’un problème technique ?
Aurais-je perdu cette ressource si la scène s’était déroulée normalement ?
Puis-je expliquer précisément ce qui s’est produit ?
Est-ce que je possède des preuves ?
Ai-je vérifié que l’objet n’est pas simplement ailleurs ?
Est-ce que j’ai déjà reçu une correction pour ce problème ?

Le remboursement sert à corriger une anomalie, pas à supprimer les risques et conséquences normales du RolePlay. Plus votre demande est précise et vérifiable, plus elle pourra être traitée correctement.