Comment vendre des scripts FiveM : Tebex, escrow Cfx.re, empaquetage et support

Vous avez écrit un script qui fonctionne sur votre serveur, et les autres propriétaires de serveurs le payeraient. Entre « ça marche » et « les gens peuvent l'acheter », il y a un magasin, une méthode de livraison, un empaquetage et un support. Ce guide passe en revue chaque étape dans l'ordre où vous les rencontrerez.

#Choisir où vendre

La plupart des scripts FiveM sont vendus via un magasin Tebex. Tebex gère les paiements, les taxes, les remboursements, les codes de réduction et la livraison. Pour une livraison protégée, vous liez votre magasin Tebex à votre compte Cfx.re, et le script est livré en tant que ressource escrow d'actif : le compte Cfx.re de l'acheteur obtient accès, et les fichiers chiffrés s'exécutent uniquement pour ce compte.

Le magasin doit être présentable. Un thème lui donne des pages de produits, des catégories et un checkout propre ; le modèle Tebex dans le magasin Mic Scripts en est une option :

Tebex TemplateUn thème premium sans code pour votre boutique Tebex, entièrement modifiable depuis le panel Tebex.dès 30,25 €Voir le script →

Suivez la documentation actuelle de Tebex et Cfx.re pour savoir comment lier les comptes, car les menus et les exigences changent.

#Préparer la ressource

Une ressource vendable c'est plus que les fichiers Lua. Vérifiez chaque point avant de télécharger :

• fxmanifest.lua avec fx_version 'cerulean', game 'gta5', une ligne lua54 'yes' si vous l'utilisez, les lignes dependency pour ox_lib, oxmysql ou un framework, et une version.
• Un config.lua avec chaque valeur qu'un acheteur doit modifier : prix, lieux, keybinds, langue, choix du framework.
• Les locales, pour que les serveurs non-anglais puissent l'utiliser. Consultez scripts traduits.
• SQL dans un fichier, comme install.sql, si le script a besoin de tables. Idéalement, le script crée ses propres tables au premier démarrage, de sorte que les acheteurs ne les oublient pas.
• Un README avec les étapes d'installation, les dépendances, les lignes server.cfg à ajouter, et le test de première exécution.
• Les articles et les emplois pour ESX, QBCore et QBox si le script les utilise. Fournissez des extraits pour chacun, comme dans ajout d'articles ox_inventory et ajout d'un emploi sur ESX.

Décidez quels fichiers restent ouverts. Config, locales et ponts de framework sont les usuels ; consultez escrow_ignore.

#Télécharger et tester la version escrow

Téléchargez la ressource sur le portail Cfx.re en tant qu'actif escrow, liez-la au paquet Tebex, puis téléchargez-la à nouveau comme le ferait un acheteur et exécutez-la sur un serveur propre. Cela capture les fichiers ouverts manquants et les problèmes de chiffrement avant qu'un client ne le fasse. escrow lack entitlement est l'erreur que les acheteurs verront si la clé et le compte ne correspondent pas, vous répondrez donc souvent à cette question.

Conseil : achetez votre propre produit une fois avec un compte différent. C'est le seul moyen de tester tout le chemin du checkout à une ressource en cours d'exécution.

#Versioning et journaux des modifications

Utilisez les versions sémantiques : 1.0.0, 1.1.0 pour les fonctionnalités, 1.1.1 pour les corrections. Mettez la version dans le manifeste :

version '1.2.0'

Gardez un CHANGELOG.md dans la ressource et dans la description du magasin :

## 1.2.0
- Added: config option for a cooldown
- Fixed: error when the player has no job
- Changed: locale files use the new key names (see README)

Dites dans le journal des modifications quand un changement nécessite que les acheteurs modifient leur config ou leur base de données. Les surprises à la mise à jour sont la raison la plus courante des mauvais avis.

#Documentation

Une bonne page de docs prévient une centaine de messages de support. Cela n'a pas besoin d'être fantaisiste :

• Installation en étapes numérotées, avec les lignes ensure exactes et l'ordre de démarrage.
• Configuration expliquée, clé par clé.
• Les exports et événements que d'autres scripts peuvent utiliser, avec des exemples.
• Dépannage : les trois erreurs que les gens vont rencontrer et leurs corrections.

Les captures d'écran et une courte vidéo du script en action aident les acheteurs à décider avant de payer.

#Support

Décidez comment vous fournissez le support et dites-le sur la page du produit. Un serveur Discord fonctionne bien : un canal par produit, un rôle pour les acheteurs, et des messages FAQ épinglés. Définissez les attentes sur les délais de réponse, et écrivez quels problèmes vous couvrez (bugs dans votre script) et lesquels vous ne couvrez pas (un conflit avec une ressource non liée fortement modifiée).

Répondez deux fois à la même question, et elle appartient dans les docs.

#Notions de base sur les licences

Énoncez les conditions où les acheteurs peuvent les voir, dans la description du magasin ou un fichier LICENSE :

• Une licence, un serveur est le modèle courant : l'acheteur peut exécuter le script sur son propre serveur.
• Pas de redistribution ou revente des fichiers, les ouverts inclus.
• Ce que les acheteurs peuvent modifier : ils peuvent modifier les fichiers ouverts pour leur propre utilisation.
• Remboursements et mises à jour : dites si les mises à jour sont incluses et pour combien de temps.

Escrow impose l'accès aux fichiers chiffrés, mais les conditions couvrent le reste. Si vos conditions doivent être légalement étanches, demandez à un professionnel ; ce guide n'est pas un avis juridique.

#Liste de contrôle