Wie man FiveM-Scripts verkauft: Tebex, Cfx.re Escrow, Verpackung und Support

Du hast ein Script geschrieben, das auf deinem Server funktioniert, und andere Server-Besitzer würden dafür bezahlen. Zwischen „es funktioniert" und „Leute können es kaufen" gibt es einen Store, eine Liefermethode, Verpackung und Support. Dieser Leitfaden geht durch jeden Schritt in der Reihenfolge, in der du sie treffen wirst.

#Wähle, wo du verkaufst

Die meisten FiveM-Scripts werden durch einen Tebex-Store verkauft. Tebex handhabt Zahlungen, Steuern, Rückerstattungen, Rabattcodes und Lieferung. Für geschützte Lieferung linkst du deinen Tebex-Store mit deinem Cfx.re-Konto, und das Script wird als Escrow-Ressource ausgeliefert: Dem Cfx.re-Konto des Käufers wird Zugriff gewährt, und die verschlüsselten Dateien laufen nur für dieses Konto.

Der Store muss präsentierbar sein. Ein Theme gibt ihm Produktseiten, Kategorien und einen sauberen Checkout; das Tebex-Template im Mic Scripts-Store ist eine Option:

Tebex TemplateEin Premium-Theme ohne Code für deinen Tebex-Shop, komplett im Tebex-Panel anpassbar.ab 30,25 €Script ansehen →

Folge der aktuellen Tebex- und Cfx.re-Dokumentation, wie man die Konten verlinkt, da die Menüs und Anforderungen sich ändern.

#Bereite die Ressource vor

Eine verkäufliche Ressource ist mehr als nur die Lua-Dateien. Überprüfe jeden Punkt, bevor du hochlädst:

• fxmanifest.lua mit fx_version 'cerulean', game 'gta5', einer lua54 'yes' Zeile, wenn du sie verwendest, dependency Zeilen für ox_lib, oxmysql oder ein Framework, und eine version.
• Eine config.lua mit jedem Wert, den ein Käufer ändern muss: Preise, Orte, Tasten, Sprache, Framework-Wahl.
• Locales, damit Non-English-Server sie verwenden können. Siehe übersetzbarer Scripts.
• SQL in einer Datei, wie install.sql, wenn das Script Tabellen braucht. Im Idealfall erstellt das Script seine eigenen Tabellen beim ersten Start, damit Käufer sie nicht vergessen.
• Eine README mit Installationsschritten, Abhängigkeiten, den server.cfg Zeilen zum Hinzufügen, und der First-Run-Test.
• Items und Jobs für ESX, QBCore und QBox, wenn das Script sie verwendet. Stelle Snippets für jeden bereit, wie in Hinzufügen von ox_inventory Items und Hinzufügen eines Jobs in ESX.

Entscheide, welche Dateien offen bleiben. Config, Locales und Framework-Bridges sind die üblichen; siehe escrow_ignore.

#Lade den Escrow-Build hoch und teste ihn

Lade die Ressource in das Cfx.re-Portal als Escrow-Asset hoch, verlinke sie mit dem Tebex-Paket, dann lade sie zurück, wie ein Käufer würde und führe sie auf einem sauberen Server aus. Dies findet fehlende offene Dateien und Verschlüsselungsprobleme, bevor ein Kunde dies tut. escrow lack entitlement ist der Fehler, den Käufer sehen werden, wenn der Schlüssel und das Konto nicht übereinstimmen, daher wirst du diese Frage oft beantworten.

Tipp: Kaufe dein eigenes Produkt einmal mit einem anderen Konto. Es ist der einzige Weg, den ganzen Pfad vom Checkout bis zu einer laufenden Ressource zu testen.

#Versionierung und Changelogs

Verwende semantische Versionen: 1.0.0, 1.1.0 für Features, 1.1.1 für Fixes. Lege die Version ins Manifest:

version '1.2.0'

Behalte ein CHANGELOG.md in der Ressource und in der Store-Beschreibung:

## 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)

Sag im Changelog, wenn eine Änderung Käufer brauchen, um ihre Config oder Datenbank zu bearbeiten. Überraschungen bei Updates sind der häufigste Grund für schlechte Bewertungen.

#Dokumentation

Eine gute Seite mit Docs verhindert hundert Support-Nachrichten. Sie muss nicht ausgefallen sein:

• Installation in nummerierten Schritten, mit den genauen ensure Zeilen und der Start-Reihenfolge.
• Configuration erklärt, Schlüssel für Schlüssel.
• Exports und Events andere Scripts verwenden können, mit Beispielen.
• Troubleshooting: die drei Fehler, die Leute treffen, und ihre Behebungen.

Screenshots und ein kurzes Video des Scripts in Aktion helfen Käufer, sich zu entscheiden, bevor sie bezahlen.

#Support

Entscheide, wie du Support gibst und sage es auf der Produktseite. Ein Discord-Server funktioniert gut: ein Kanal pro Produkt, eine Rolle für Käufer, und angeheftete FAQ-Nachrichten. Setze Erwartungen bei den Antwortzeiten, und schreibe auf, welche Probleme du abdeckst (Fehler in deinem Script) und welche nicht (ein Konflikt mit einer nicht verwandten stark modifizierten Ressource).

Beantworte die gleiche Frage zweimal, und sie gehört in die Docs.

#Lizenzierungs-Grundlagen

Gebe die Bedingungen an, wo Käufer sie sehen können, in der Store-Beschreibung oder einer LICENSE Datei:

• Eine Lizenz, ein Server ist das häufige Modell: Der Käufer darf das Script auf seinen eigenen Server laufen lassen.
• Keine Umverteilung oder Weiterverkauf der Dateien, einschließlich der offenen.
• Was Käufer ändern dürfen: Sie können offene Dateien für ihren eigenen Gebrauch bearbeiten.
• Rückerstattungen und Updates: Sag, ob Updates enthalten sind und wie lange.

Escrow erzwingt Zugriff auf die verschlüsselten Dateien, aber die Bedingungen decken den Rest ab. Wenn deine Bedingungen rechtlich wasserdicht sein müssen, frage einen Fachmann; dieser Leitfaden ist keine Rechtsberatung.

#Checkliste